WordPress Utvikler i Madrid

WordPress-utvikling for Madrid-bedrifter handler sjelden om å sette opp et ferdig tema. Den handler om å bygge et nettsted som tåler spansk og engelsk innhold, som kobler seg mot Redsys eller andre spanske betalingsløsninger der nettbutikk er aktuelt, som respekterer GDPR håndhevet av AEPD, og som gir redaktørene egne Gutenberg-blokker i stedet for å ringe en utvikler for hver kampanje. I hovedstaden kommer det i tillegg ofte krav fra e-handel, messer på IFEMA, finansaktører i Cuatro Torres og nordiske selskaper med filial i regionen. Det er den jobben denne siden beskriver.

Jeg leverer senior WordPress-utvikling for virksomheter i Madrid-området: egne block-temaer, plugins, egne Gutenberg-blokker, integrasjoner mot spanske betalings- og bookingtjenester og refaktorering av eldre temaer som har vokst seg uoversiktlige. Arbeidet følger WordPress Coding Standards, og hver branch går gjennom kodegjennomgang før den når produksjon.

#WordPress-utvikling i Madrid

Madrid er Spanias administrative og økonomiske tyngdepunkt. Cuatro Torres og AZCA samler banker, forsikringsselskaper og fintech-aktører, mens Salamanca og Gran Vía setter takten for detaljhandel og merkevare-e-handel. IFEMA på Feria de Madrid og messer som FITUR kan tredoble trafikken på nettsteder for eventpartnere, hoteller og logistikkaktører. Bedrifter i regionen trenger WordPress-løsninger som tåler disse toppene, som snakker spansk til lokale kunder og engelsk til internasjonale besøkende, og som ikke knekker når AEPD stiller spørsmål om personopplysninger eller når Redsys-integrasjonen må oppdateres etter en WooCommerce-versjon.

Den vanligste situasjonen er en virksomhet som driver et WordPress-nettsted bygget for noen år siden av et lokalt byrå i Chamberí eller av en frilanser som siden har gått videre. Temaet har fått påklistret funksjonalitet bit for bit, flerspråklig oppsettet er skjørt sammen med WPML eller Polylang uten dokumentasjon, og ingen vet hvilken kode som faktisk er i bruk. Den andre vanlige situasjonen er en nordisk bedrift med filial, distributør eller kundestøtte i Madrid som trenger et nettsted som speiler det spanske markedet og kravene Datatilsynet stiller hjemme i Norge.

#Hva oppdraget dekker

• Egne block-temaer bygget på editor-API-ene (theme.json, blokkmønstre, stilvarianter) slik at redaktører i Madrid kan endre forsider, IFEMA-landinger og sesongkampanjer uten å ringe en utvikler
• Egne Gutenberg-blokker med React-komponenter, block.json-metadata, transformasjoner og InspectorControls, slik at innholdsstrukturen er låst mens teksten forblir redigerbar
• Egne plugins for forretningslogikk, egne posttyper og integrasjoner, holdt utenfor temaet så funksjonaliteten overlever et fremtidig temabytte
• Flerspråklig oppsett for spansk (es) og engelsk (en) med riktig hreflang, språkbytte og uavhengige metadata per språk
• Integrasjoner mot Redsys og andre spanske betalingsløsninger der nettbutikk eller booking er aktuelt, med korrekt håndtering av callbacks og ordrestatus
• REST- og WPGraphQL-endepunkter for headless frontender eller mobilapper, med autentisering og fornuftig hastighetsbegrensning
• WP-CLI-skript for masseoperasjoner på innhold, databasemigrasjoner og miljøkonfigurasjon når et nettsted skal flyttes mellom hostingleverandører
• Tilgjengelighet etter WCAG 2.2 AA og EN 301 549, relevant for offentlige nettsteder i Spania og for nordiske kunder som selger til EU

#E-handel i hovedstaden

Madrid er det naturlige utgangspunktet for mange spanske nettbutikker som skal nå hele landet og samtidig betjene internasjonale kunder på engelsk. Det betyr ikke at WordPress alltid er riktig plattform for hele verdikjeden, men for merkevarepresentasjon, innholdsmarkedsføring, produktkataloger og mindre til mellomstore nettbutikker er WooCommerce på WordPress fortsatt det vanligste valget blant SMB-er og vekstselskaper i Comunidad de Madrid.

Typiske e-handelskrav jeg møter i Madrid:

• Redsys i kassen. De fleste spanske forbrukere forventer kortbetaling via Redsys. Integrasjonen må håndtere callbacks, ordrestatus og feilsituasjoner uten at kundedata logges unødig.
• Bizum for mobil. Raske betalinger via Bizum er utbredt blant spanske kunder. For internasjonale besøkende suppleres det ofte med PayPal eller Stripe, avhengig av målgruppen.
• ES/EN produktdata. Produktbeskrivelser, fraktinformasjon og returpolicy må finnes på spansk og engelsk, med riktig hreflang og uavhengige SEO-felt per språk.
• Sesongtopper. Black Friday, januarutsalg og messer på IFEMA kan tredoble trafikken. Caching, CDN og databaseytelse må være på plass før kampanjen, ikke etter at siden har falt sammen.
• ERP og lager. Mange Madrid-butikker kobler WooCommerce mot et ERP eller et lagerstyringssystem. Grensen for hva som hører hjemme i WordPress versus i backend, avklares skriftlig før koden skrives.

En feil i betalingsintegrasjonen treffer omsetningen direkte, spesielt rett før FITUR eller i høysesongen for detaljhandel. Derfor testes kasseflyten i testmiljø mot Redsys sandbox og eventuelle bookingintegrasjoner før hver utrulling, ikke bare ved lansering.

#Markedet og det tekniske miljøet i Madrid

Madrids digitale økosystem er mer enn offentlig sektor og finans, selv om Cuatro Torres og La Moncloa setter krav til sikkerhet og tilgjengelighet. Miljøet rundt La Nave Innovation Hub, coworking i Malasaña og Chamberí, og designstudioer i Salamanca trekker B2B-aktører som selger på tvers av EU. Det praktiske utslaget for WordPress-utvikling er at mange Madrid-baserte virksomheter har et nettsted bygget raskt i en tidlig fase, ofte med et generisk tema og page builder, og som nå trenger egne blokker, bedre ytelse og et flerspråklig oppsett som faktisk fungerer.

Trafikktopper kommer fra flere retninger samtidig. IFEMA-messer kan tredoble trafikken på nettsteder for eventpartnere, hoteller og logistikkaktører. Sesongbasert detaljhandel bringer trafikk på spansk og engelsk til nettbutikker og merkevareaktører. I den perioden er caching, CDN og databaseytelse like viktig som sikkerhetsoppdateringer. I roligere uker er det naturlig å ta strukturelle grep: PHP-oppgradering, opprydding i plugin-inventaret etter kampanjemicrosites, migrering til raskere hosting innenfor EU, og testing av gjenoppretting uten at kundene merker det.

Norske og nordiske bedrifter med filial, distributør eller kundestøtte i Madrid har ofte et annet sett krav enn rent lokale aktører. De vil ha dokumentasjon på datalagring i EU, tydelig behandlingsgrunnlag for skjema og kundedata, og en utviklingspartner som forstår at Datatilsynet i Norge og AEPD i Spania begge kan stille spørsmål ved samme nettsted. Leveransen speiler det: revisjonsspor, skriftlige avveininger og en runbook som tåler etterprøving.

#GDPR, AEPD og personvern i koden

Mye av det som skiller en Madrid-leveranse fra en generisk WordPress-jobb ligger i regelverket, ikke i designet. AEPD har hovedkontor i Madrid, og tilsynet er aktivt mot nettsteder som behandler personopplysninger uten gyldig grunnlag. Et par konkrete eksempler fra arbeidet:

• Personvern og AEPD. GDPR gjelder fullt ut i Spania, og Agencia Española de Protección de Datos (AEPD) håndhever det. I praksis betyr det samtykkebanner som faktisk blokkerer skript før samtykke, en databehandleravtale med hostingleverandøren, og at analyseverktøy ikke lekker personopplysninger ut av EØS uten grunnlag. Jeg setter dette opp i koden, ikke bare i en personvernerklæring ingen leser.
• Varsling ved brudd. AEPD krever varsling innen 72 timer når et personopplysningsbrudd medfører risiko for personers rettigheter. Skjemaer, bookingflyter og kundedata i WordPress må derfor logges og beskyttes slik at et brudd kan dokumenteres og varsles i tide.
• Datalagring i EU. Nordiske kunder som selger til spanske forbrukere vil ofte ha eksplisitt krav om at database, backup og e-postlogger ligger innenfor EØS. Jeg kartlegger hvor data faktisk ligger, om CDN-en speiler innhold utenfor EØS, og om tredjepartsplugins sender data til USA uten gyldig overføringsgrunnlag.
• Cookie-valg og markedsføring. Retargeting og analyse uten samtykke er et vanlig funn i AEPD-saker. Jeg konfigurerer cookie-valg som faktisk styrer skriptlasting, og dokumenterer hvilke tredjeparter som mottar data.

#Flerspråklig oppsett: spansk og engelsk

I Madrid er spansk det naturlige standardspråket, mens engelsk ofte er nødvendig for internasjonale kunder, expats, turister og B2B-aktører som selger utenfor Spania. I motsetning til Catalunya trenger de fleste Madrid-prosjekter ikke katalansk, men et solid es/en-oppsett med riktig hreflang og redaksjonelle arbeidsflyter.

Jeg bygger typisk flerspråklige nettsteder med WPML, Polylang eller tilsvarende, med:

• Uavhengige URL-strukturer per språk, ikke bare query-parametre
• hreflang-tagger som peker riktig mellom es og en
• Språkbytte som bevarer kontekst, slik at en engelskspråklig besøkende på en produktside lander på engelsk versjon av samme produkt
• Redaksjonelle arbeidsflyter som holder oversettelser synkronisert uten at redaktører overskriver feil språkversjon
• Metadata og Open Graph-felt per språk, ikke kopiert fra standardspråket

For e-handelsaktører i Salamanca og for B2B-selskaper som selger til internasjonale markeder er engelsk ofte like viktig som spansk. For offentlige virksomheter og lokale tjenesteleverandører holder spansk alene, men mange velger engelsk som sekundærspråk for expats og turister. WordPress-arkitekturen må ta høyde for begge deler fra dag én, ikke som et tillegg etter lansering.

#Egne Gutenberg-blokker for redaksjonell autonomi

Page builders og generiske temaer gir rask start, men de binder redaksjonen til utvikleren når noe skal endres utenfor malen. Egne Gutenberg-blokker løser det ved å låse strukturen og la teksten være fri.

Typiske blokker jeg bygger for Madrid-prosjekter:

• Hero med sesongvariant, der redaktøren velger bilde, overskrift og CTA uten å røre layouten. Nyttig for IFEMA-landinger, sesongkampanjer og messer.
• Tjenestekort med ikon og lenke, gjenbrukbare på tvers av sider, med konsistent spacing og tilgjengelig markup.
• FAQ-accordeon, med schema.org FAQPage-markup innebygd, slik at rike resultater i Google er en del av blokken, ikke et etterpåklatt.
• Kontaktskjema med GDPR-felt, der samtykke, behandlingsgrunnlag og lenke til personvernerklæring er en del av blokken, ikke et plugin som redaktøren må huske å legge inn.
• Flerspråklig CTA-rad, der knappetekst og lenke endres per språkversjon uten å duplisere hele seksjonen.
• Produktkort for WooCommerce, der pris, lagerstatus og CTA rendres konsistent på tvers av kategorisider og kampanjesider.

Hver blokk registreres med block.json, har InspectorControls for redaksjonelle valg, og følger WordPress Coding Standards. Der det er mulig, rendres innholdet serverside for bedre LCP; React-hydrering brukes bare når interaksjonen faktisk krever det.

#Redsys og betalingsintegrasjoner

Redsys står bak mange kortterminaler og nettbetalingsløsninger i Madrid og resten av Spania. For en WordPress-nettside med WooCommerce eller en egen bookingflyt er Redsys-integrasjonen ofte det lokale markedet forventer, sammen med Bizum for raske mobilbetalinger blant spanske kunder og PayPal eller Stripe for internasjonale besøkende.

Jeg bygger betalingsintegrasjoner som plugins, ikke som temakode, slik at de overlever et temabytte. Det inkluderer:

• Korrekt håndtering av Redsys-callbacks og ordrestatus i WooCommerce
• Testmiljø mot Redsys sandbox før produksjon
• Feilhåndtering som logger nok til feilsøking uten å eksponere kortdata
• Kassemal som fungerer på mobil over 4G fra Barajas, ikke bare på utviklerens WiFi

Redsys har hovedkontor i Madrid-området, og mange Madrid-bedrifter har direkte avtale med banken som leverer Redsys-terminaler. Integrasjonen må speile den avtalen: riktig merchant ID, riktig signaturalgoritme, og korrekt håndtering av 3D Secure der det kreves.

#Slik jobber jeg gjennom et oppdrag

1. Kartlegging og kodegjennomgang. Jeg går gjennom dagens WordPress-installasjon: temastruktur, egne plugins, integrasjoner, hosting hos CDmon, SiteGround EU, OVH eller annen leverandør, og et referansepunkt for ytelse og tilgjengelighet. Resultatet er et skriftlig risikokart, ikke en magefølelse.
2. Arkitektur og omfang. Vi avgjør hva som skal bygges nytt og hva som kan refaktoreres, hvor grensen mellom tema og plugin går, hvilke språk som skal støttes, hvilke integrasjoner som trengs, og hvilke akseptkriterier som gjelder. Avveininger skrives ned.
3. Bygging i feature-branches. Koden følger WordPress Coding Standards, tekst er i18n-klar, markup er tilgjengelig, og hver branch går gjennom kodegjennomgang før den slås sammen.
4. QA og utrulling. Løsningen kjøres i et testmiljø som speiler produksjon. Du tester med ekte innhold på es og en, verifiserer skjemaer, Redsys og booking før lansering der det er relevant. Utrulling skjer via en dokumentert release-prosess med en sti tilbake hvis noe må reverseres.
5. Overlevering. Du får levende dokumentasjon for både redaktører og utviklere, en runbook for de ikke-opplagte valgene, og en overleveringssesjon. Deretter kan prosjektet gå til ditt eget team eller til en fast vedlikeholdsavtale.

#Typiske utfordringer jeg løser for Madrid-bedrifter

• Et tema full av teknisk gjeld fra et lokalt byrå. Mange nettsteder i Chamberí og Malasaña har samlet logikk i functions.php gjennom flere utviklere. Jeg flytter forretningslogikk ut i plugins, rydder mal-hierarkiet og fjerner kode ingen lenger bruker.
• Flerspråklig kaos etter en oppdatering. Spansk innhold vises på engelske URL-er, hreflang peker feil, eller WPML slutter å synkronisere oversettelser. Jeg sjekker språkruting og metadata før indekseringen faller.
• Et nettsted som kollapser under IFEMA- eller kampanjetrafikk. Før store hendelser setter jeg opp full-page caching, rydder i trege databasespørringer, ekskluderer kasse og skjemaer fra cache der det trengs, og belastningstester før sesongen, ikke etter.
• Migrasjon fra page builder til Gutenberg. Innhold ekstraheres, layouter bygges som blokkmønstre, og redaksjonelle team trenes uten å forstyrre trafikk eller SEO-plasseringer.
• Sikkerhet på sider som håndterer persondata og B2B-henvendelser. Content Security Policy-headere, deaktivert XML-RPC der det ikke brukes, tofaktor på admin, en brannmur tilpasset WordPress-spesifikke angrepsmønstre, og parametriserte spørringer som lukker SQL-injeksjon.
• WooCommerce som ikke konverterer på mobil. Kassemal, betalingsflyt og produktgalleri testes på reelle mobile enheter og nettverk, ikke bare i desktop-emulator.

#Hva du kan måle etterpå

Jeg foretrekker resultater som lar seg etterprøve framfor påstander. Det som faktisk kan måles på et Madrid-prosjekt:

• Core Web Vitals i grønt for LCP, INP og CLS, verifisert på mobil mot reelle besøkstall fra nettbutikk og B2B-trafikk, ikke bare i en Lighthouse-kjøring på en rask maskin
• Kortere publiseringstid for redaksjonen fordi forsider og kampanjesider bygges med egne blokker i stedet for utviklerbillett
• Et flerspråklig oppsett der es og en holder seg synkronisert uten at feil språkversjon indekseres i Google
• Et kjøps- eller bookingløp der Redsys og skjemaer fungerer på mobil fra Barajas, slik at avbrutte henvendelser i kassen går ned

#Ytelse i praksis

Core Web Vitals påvirker både rangering i Google og hvor mange som faktisk fullfører et kjøp eller en henvendelse. På et WordPress-prosjekt i Madrid jobber jeg mot disse målene konkret:

• LCP holdes nede med optimalisert kritisk renderingsvei, hero-bilder i WebP/AVIF, edge-caching og statisk levering der det er mulig
• INP holdes lav med minimal JavaScript-hydrering, færre og lettere tredjepartsskript, og tunge beregninger flyttet bort fra hovedtråden
• CLS holdes lav med eksplisitte bildedimensjoner, font-display: swap med matchende reservefont og reservert plass for innhold som lastes etterpå

Målingene følges over tid med Lighthouse i utrullingsløpet og data fra reelle besøkende, slik at en regresjon fanges opp før den rekker å påvirke salget eller leadflyten under IFEMA-messer eller sesongbasert detaljhandel.

#Innholdsmodell for e-handel, B2B og kunnskapsformidling

Et nettsted for en Madrid-virksomhet fungerer dårlig hvis alt ligger som fritekst i Gutenberg uten struktur. Jeg etablerer typisk:

• Egne posttyper for tjenester, produkter, prosjekter, messer eller kompetanseområder, med felter som redaksjonen faktisk fyller ut
• Taksonomier som speiler hvordan markedet snakker (sektor, sesong, leveranseform, språk), ikke interne organisasjonskart
• Blokkmønstre for hero, verdiforslag, produktliste, bildegalleri og CTA, slik at nye sider følger samme rytme
• Skille mellom offentlig markedsføring og begrenset innhold, der siste del håndteres med roller og, om nødvendig, egen autentisering

Denne modellen er spesielt nyttig når flere personer i markedsføring, e-handel eller B2B-salgsteam skal publisere på es og en uten å duplisere hele temastrukturen.

#Spørsmål jeg ofte får fra Madrid-bedrifter

Hva skjer hvis kravene endres underveis? Det er normalt. Den sprintbaserte arbeidsformen gjør at vi kan justere omfanget mellom iterasjoner. Konsekvensen for tid og budsjett legges åpent på bordet, og du godkjenner før vi går videre.

Bygger du nytt tema eller utvider det jeg har? Begge deler forekommer. Et nytt prosjekt starter som regel med et eget block-tema og egne blokker; et arvet prosjekt trenger oftere fokusert refaktorering enn en full omskrivning. Valget tas på grunnlag av kostnad mot teknisk gjeld, og begrunnelsen skrives ned.

Håndterer dere nettsteder på spansk og engelsk? Ja. Jeg bygger språkruting, hreflang, oversatte metadata og redaksjonelle arbeidsflyter som holder es og en i takt uten at oppdateringer ødelegger WPML, Polylang eller tilsvarende.

Kan dere koble WordPress mot Redsys og booking? Ofte ja, via WooCommerce-plugins, egne REST-endepunkter eller dokumenterte API-er. Grensen for hva som hører hjemme i WordPress versus i et ERP, CRM eller bookingverktøy, avklares skriftlig før koden skrives.

Hva skiller dette fra et generisk byrå i Madrid? Du jobber direkte med en senior utvikler, ikke gjennom flere ledd. Avveiningene er skriftlige, akseptkriteriene er målbare, og omfanget bygges rundt WordPress-utvikling framfor en bred redesignpakke.

Jobber dere bare med bedrifter i Madrid? Vi har kunder i hele Spania og i Norden som betjener EU-markeder. Leveransen er uansett ekstern, med rapportering og SLA avtalt skriftlig. Kommunikasjonen kan foregå på norsk selv om nettstedet betjener det spanske markedet.

#Priser og forutsigbarhet

Prisen settes individuelt etter omfanget i den enkelte saken, og du får en detaljert oversikt før arbeidet starter. Endringer i omfang diskuteres åpent med tydelige konsekvenser for tid og budsjett, slik at det ikke kommer overraskelser på fakturaen. Jeg skriver kode andre utviklere kan vedlikeholde: dokumentasjon, kodestandarder og en overleveringssesjon hører med.

#Lokal SEO for synlighet i Madrid-markedet

Et godt bygget nettsted har bare verdi om målgruppen i Madrid og Comunidad de Madrid finner det. Det grunnleggende SEO-arbeidet er en del av leveransen:

• Teknisk fundament: ryddige URL-strukturer per språk, XML-nettkart, kanoniske tagger og riktig overskriftshierarki, med strukturerte data (LocalBusiness, Organization, FAQ, HowTo) der de hører hjemme
• Flerspråklig SEO: hreflang mellom es og en, uavhengige titler og metabeskrivelser per språk, og unngåelse av duplisert innhold på tvers av språkversjoner
• Core Web Vitals som rangeringssignal, behandlet som en del av utviklingen og ikke en etterpåklattet optimalisering
• Innhold som speiler faktiske søkeintensjoner i regionen: e-handel, B2B-kontakt, IFEMA-relaterte tjenester, rekruttering, uten tykke tekstblokker skrevet bare for søkemotorer

#Tilgjengelighet i en spansk og EU-kontekst

Offentlige nettsteder i Spania skal følge EN 301 549, som viser til WCAG. For private virksomheter som selger til EU er European Accessibility Act relevant fra 2025. Jeg bygger tilgjengelighet inn i temakoden fra første branch: kontrast i theme.json, tastaturfokus som ikke skjules av sticky header, skjemaetiketter koblet til felt, og landemerker for header, nav, main og footer.

En oppdatering som introduserer et utilgjengelig skjema er ikke bare en designsvakhet i Madrid-konteksten, den kan utløse klager og tilsyn. Derfor inngår en tilgjengelighetskontroll i QA-fasen, med både automatiske skann og manuell tastaturgjennomgang, ikke som et engangsprosjekt etter lansering.

#Hosting, miljøer og overlevering

Et WordPress-prosjekt for en virksomhet i Chamberí, Salamanca eller Cuatro Torres trenger mer enn produksjonsmiljøet. Jeg setter opp minst utvikling, test og produksjon der det er praktisk, med samme PHP-versjon og samme pluginsett. Mange Madrid-kunder ligger hos spanske hostingleverandører som CDmon, andre hos OVH, SiteGround med EU-datasenter eller internasjonale plattformer med eksplisitt datalagring innenfor EØS.

Deploy skjer via en dokumentert sti, ikke via FTP midt i arbeidsdagen. Sikkerhetskopier og tilbakeføringsplan avtales før første utrulling. Akseptkriteriene er skriftlige: hvilke sider som skal fungere på hvilket språk, hvilke skjemaer som skal sende, hvilke integrasjoner som skal verifiseres, og hvilke ytelsesmål som skal være grønne før lansering.

For nettbutikker er inngangen WooCommerce-utvikler i Madrid. For løpende drift etter lansering, se vedlikehold og support i Madrid.

#Andre spanske byer

Trenger du WordPress-utvikling utenfor Madrid, gjelder mye av det samme rundt AEPD, Redsys og flerspråklig oppsett, men med lokal kontekst. Se også WordPress-utvikler i Barcelona, WordPress-utvikler i Valencia og WordPress-utvikler i Málaga for hvordan arbeidet tilpasses der.

#Start prosjektet ditt i Madrid

Trenger virksomheten din i Madrid, i Comunidad de Madrid eller som nordisk selskap med drift i regionen en utvikler som kjenner WordPress, egne Gutenberg-blokker, flerspråklig oppsett for es og en, og de spanske rammene rundt AEPD og Redsys, ta kontakt for en uforpliktende samtale. Jeg går gjennom situasjonen, ser på dagens installasjon og gir en ærlig vurdering av hva som faktisk trengs, før vi blir enige om omfang og forventninger. Arbeidet tilpasses IFEMA-topper, sesongbasert e-handel, B2B-leveranser og redaksjonell hverdag på to språk.