WordPress omzetten naar Lovable · de complete migratiegids

De redenen die wij in intakes horen zijn opvallend consistent. Ten eerste snelheid: een gemiddelde WordPress-site met een pagebuilder en 15 tot 30 plugins laadt drie tot vijf seconden op mobiel, terwijl Core Web Vitals en gebruikers onder de twee seconden verwachten. Ten tweede onderhoud: plugin-updates, PHP-versies en beveiligingslekken vragen structureel aandacht die niemand in de organisatie heeft belegd. Ten derde kosten die stilletjes oplopen — premium thema's, formulierplugins, SEO-plugin-pro, caching, backup, security en een hostingpakket dat zwaar genoeg is om dat allemaal te dragen. Ten vierde, en dat is nieuw sinds de opkomst van AI-zoekmachines: de HTML die pagebuilders produceren is voor mensen prima leesbaar maar voor extractie ronduit slecht. Diepe div-nesting, content verstopt in shortcodes, koppen die geen echte hiërarchie hebben en structured data die per plugin verschilt. Wie geciteerd wil worden in ChatGPT, Perplexity of Google AI Overviews heeft schone, semantische HTML en consistente schema nodig — en dat is precies wat een herbouw oplevert.

Belangrijk om de verwachting scherp te zetten: je converteert geen WordPress-installatie. Er bestaat geen importer die PHP-templates, thema-opties en plugin-logica omzet naar React. Wat je doet is de site opnieuw bouwen op een moderne stack — in ons geval TanStack Start met React, server-side rendering en Tailwind — en daar de bestaande inhoud, structuur en autoriteit in overzetten. Wat meeverhuist: teksten, afbeeldingen, URL-structuur, metadata, interne links, structured data en formulieren. Wat je opnieuw inricht: templates, navigatie, contentbeheer en integraties. En wat je vaak kunt weglaten: de helft van de plugins, omdat caching, formulieren, sitemaps en SEO-metadata in een moderne stack gewoon onderdeel van de code zijn. Het praktische verschil met een klassiek herbouwtraject is de doorlooptijd: met AI-development staat een werkende versie doorgaans binnen twee weken op een testomgeving, waarna de tijd vooral naar content, redirects en detaillering gaat.

Begin nooit met bouwen voordat je weet wat er staat. Draai een volledige crawl met Screaming Frog of Sitebulb en exporteer alle URL's met statuscode, titel, meta description, H1, woordaantal en aantal inkomende interne links. Trek daarnaast uit Google Search Console de lijst met pagina's die de afgelopen 12 maanden vertoningen of kliks kregen — die lijst bevat vrijwel altijd URL's die niet in je menu staan: oude blogposts, categorie- en tagarchieven, auteurspagina's, attachment-pagina's en landingspagina's uit oude campagnes. Voeg daar je backlink-export aan toe (Semrush, Ahrefs of Search Console-links), want URL's met externe links zijn je waardevolste bezit. Het resultaat is één spreadsheet: elke bestaande URL, met verkeer, links en woordaantal. Die spreadsheet is de rest van het traject je waarheid.

Er zijn twee betrouwbare exportroutes. De WXR-export (Gereedschap → Exporteren) geeft je één XML-bestand met alle posts, pagina's, categorieën en metavelden — prima voor eenmalige migraties. De WordPress REST API (/wp-json/wp/v2/posts?per_page=100) geeft schone JSON en is handiger als je content programmatisch wilt omzetten naar componenten of markdown. In beide gevallen loont het om de HTML te normaliseren: shortcodes uitschrijven, inline styles verwijderen, koppen terugbrengen naar één H1 en logische H2/H3, en tabellen en lijsten in echte semantische elementen zetten. Doe dit ook meteen als contentaudit: welke pagina's krijgen al twee jaar geen enkel bezoek, welke concurreren met elkaar op hetzelfde zoekwoord, en welke verdienen een samenvoeging? Consolideren mag — maar dan bewust, met een redirect, en niet als bijvangst van de migratie.

Dit is de stap waar migraties slagen of sneuvelen. Vuistregel: behoud URL's als het kan. Verandert de structuur toch (bijvoorbeeld van /2019/03/artikel-titel/ naar /blog/artikel-titel), maak dan per oude URL een 301-redirect naar de meest gelijkwaardige nieuwe pagina. Niet naar de homepage — een massale redirect naar de homepage wordt door Google als soft-404 behandeld en gooit de opgebouwde waarde weg. Vergeet de randgevallen niet: trailing slashes, hoofdletters, paginering (/page/2/), feeds (/feed/), attachment-URL's, en de oude sitemap-paden van Yoast of RankMath. Test de mapping vóór livegang door de complete lijst met oude URL's door een redirect-checker te halen op de staging-omgeving. Streef naar honderd procent: elke oude URL moet één redirect maken (geen ketens) en eindigen op statuscode 200.

In WordPress zit je SEO in plugins; in de nieuwe site zit hij in de code, en dat betekent dat je hem bewust moet meenemen. De checklist: server-side rendering voor elke publieke pagina, één unieke title en meta description per route, canonical tags, een gegenereerde XML-sitemap die alle routes bevat, een robots.txt die crawlers correct stuurt, hreflang bij meertaligheid, en structured data per contenttype. Neem ook de interne linkstructuur letterlijk mee: pagina's die in WordPress veel interne links kregen, moeten die in de nieuwe site opnieuw krijgen, anders verschuift de autoriteitsverdeling en zakken juist je belangrijkste pagina's. Meet vóór en na met een crawl-diff: dezelfde crawler over de oude en de nieuwe site, en vergelijk woordaantallen, titels, koppen en het aantal interne links per pagina. Elk gat dat je daar ziet, is een gat dat Google óók ziet.

Een migratie is het goedkoopste moment om je site geschikt te maken voor AI-zoekmachines, omdat je toch elke pagina aanraakt. Vier concrete toevoegingen. Eén: consistente schema.org-markup — Organization en WebSite sitebreed, Article of BlogPosting op artikelen, FAQPage bij vraag-antwoordblokken, LocalBusiness bij vestigingen, en Service op dienstpagina's, allemaal met dezelfde @id-verwijzingen zodat je merk als één entiteit herkend wordt. Twee: citeerbare contentblokken — een definitie in de eerste alinea, feiten met bron en jaartal, korte kernpunten bovenaan en echte FAQ's onderaan. Drie: llms.txt en llms-full.txt, die AI-crawlers naar je belangrijkste bronnen wijzen. Vier: crawler-toegang bewust regelen in robots.txt (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) — je kunt niet geciteerd worden door een model dat je niet mag lezen.

De vraag die redactieteams als eerste stellen: kan ik straks nog zelf publiceren? Drie werkbare modellen. Content in code is het snelst en goedkoopst en past bij sites die enkele keren per kwartaal wijzigen; publiceren loopt dan via je bouwpartner of via een simpel pull request. Een headless CMS (Sanity, Storyblok, Contentful, Directus) geeft redacteuren een vertrouwde editor met previews en workflows, en de site haalt de content op tijdens build of runtime — dit is voor de meeste marketingteams de juiste keuze. Een eigen database met een admin-scherm is de derde weg: maximale controle over velden, rollen en publicatiestromen, en het meest logisch als content nauw verweven is met applicatiefunctionaliteit zoals klantportalen of productdata. Beslisregel: publiceer je meer dan twee keer per maand, kies dan optie twee of drie.

Ga live op een rustig moment, niet vlak voor een campagne. Volgorde op de dag zelf: DNS omzetten, SSL controleren, redirect-lijst opnieuw draaien tegen de live-omgeving, sitemap indienen in Search Console, en een handmatig indexatieverzoek voor je twintig belangrijkste pagina's. Daarna zes weken actief meten: crawlstatistieken en 404's in Search Console, statuscodes in je serverlogs, Core Web Vitals in CrUX, posities in je rank tracker en — vaak vergeten — je AI-zichtbaarheid, door je kernvragen wekelijks aan ChatGPT, Perplexity en Gemini te stellen en te noteren of je genoemd wordt. Verwacht in week één tot drie fluctuatie: Google hercrawlt en herwaardeert. Zakt er iets structureel, dan is de eerste verdachte bijna altijd een ontbrekende redirect of een pagina die dunner is geworden dan zijn voorganger.

Eerlijk advies hoort erbij. Blijf bij WordPress als je webshop op WooCommerce draait met tientallen koppelingen naar voorraad, boekhouding en verzending — dat opnieuw bouwen kost meer dan het oplevert. Blijf ook als je redactie leunt op complexe rollen, workflows en planning binnen WordPress, of als een membership- of LMS-plugin jaren maatwerk bevat. En blijf als je probleem eigenlijk 'traag en rommelig' is: dan levert plugins saneren, hosting upgraden, caching goed instellen, afbeeldingen naar WebP zetten en de pagebuilder vervangen door blokken vaak 80 procent van de winst voor 20 procent van de kosten. Wij doen zo'n opschoning ook — en zeggen het voordat een offerte voor een herbouw op tafel komt.

Voor een zakelijke site van 10 tot 25 pagina's ligt een complete migratie doorgaans tussen € 6.000 en € 12.000, inclusief inventarisatie, redirect-plan, herbouw, SEO- en GEO-fundament en livegang. Contentrijke sites met een blog, topic clusters en een CMS-koppeling zitten vaker tussen € 12.000 en € 30.000. Aan de andere kant van de rekensom staan de terugkerende kosten die verdwijnen: premium plugins en pagebuilder-licenties (€ 300–1.200 per jaar), zwaardere hosting (€ 300–1.500 per jaar), en onderhoudsuren voor updates en beveiliging. De winst die klanten daadwerkelijk noemen zit echter zelden in die besparing: het is de laadtijd die van vier seconden naar onder de seconde gaat, de conversie die daarmee meebeweegt, en het feit dat de site voor het eerst in AI-antwoorden opduikt omdat de content eindelijk extraheerbaar is.