Hoe migreer je van Webflow naar Astro en Sanity, en laat je het draaien met Claude

De meeste handleidingen over het verlaten van Webflow beantwoorden de verkeerde vraag. Ze vergelijken paginasnelheid, hostingkosten en limieten voor CMS-items, alsof de beslissing een vergelijking van functies is. Dat is het niet. De echte vraag is wie er wekelijks aan je website werkt, en waarmee.

Dat andere perspectief verandert het hele project. Migreren van Webflow naar Astro en Sanity betekent dat je een visuele editor die je marketingteam al kent, inruilt voor een codebase die door een AI-agent kan worden beheerd. Die ruil loont alleen als je daarna ook daadwerkelijk de workflow met die agent adopteert. Teams die migreren en vervolgens elke tekstwijziging weer via een developer laten lopen, zijn uiteindelijk trager en duurder uit dan ze bij Webflow waren, met alleen een betere Lighthouse-score als resultaat.

Dit artikel is bedoeld voor oprichters, CTO's en marketingverantwoordelijken bij bedrijven met een serieuze contentstrategie, niet voor een brochurewebsite van vijf pagina's. Als een developer slechts eens per kwartaal naar je site kijkt en je kosten redelijk zijn, kun je nu stoppen met lezen en blijven waar je bent.

Als je verder bent dan dat punt, is dit wat je krijgt: hoe je een eerlijke beslissing neemt, wat Webflow je wel en niet meegeeft bij vertrek, hoe je je content in Sanity modelleert in plaats van je collecties simpelweg te kopiëren, de 7 migratiestappen op volgorde, hoe je je posities in zoekmachines beschermt tijdens de overstap, en hoe de bewerkingservaring daarna daadwerkelijk werkt met Sanity, Stacki en Claude.

‍

Belangrijkste punten

• Migreren van Webflow naar Astro en Sanity is een herbouw, geen export. De Webflow-code-export is een visuele referentie, geen fundament.

• Beslis op basis van wie de site wekelijks bewerkt. Engineering-teams winnen aan snelheid. Marketing-teams verliezen die meestal.

• Haal CMS-content via de Webflow Data API of CSV-export, nooit via de HTML-export; die verwijdert CMS-data en de opzet van componenten.

• Modelleer content in Sanity op basis van wat het is, niet op hoe Webflow het weergaf. Het één-op-één kopiëren van collectiestructuren sleept oude fouten mee naar een nieuw systeem.

• Het missen van 301-redirects, niet de platformwissel zelf, is wat je posities in zoekmachines schaadt. Bouw de redirect-map voordat je ook maar één pagina bouwt.

• Assets moeten van het Webflow CDN worden verplaatst vóór de overstap, anders breekt je productie-content zodra het site-abonnement verloopt.

• De bewerkingsomgeving is het echte struikelblok, en daar is een antwoord op: Sanity Presentation voor content, Stacki voor lay-out, Claude voor de rest.

• Reken op 4 tot 8 weken voor een typische marketingwebsite van 50 tot 100 pagina's, minder als je contentmodel al strak is.

‍

Wat betekent migreren van Webflow naar Astro en Sanity eigenlijk?

Migreren van Webflow naar Astro en Sanity betekent dat je één gebundeld product vervangt door drie gespecialiseerde producten. Webflow verkoopt een visuele designer, een CMS, een hostingplatform en een editor-interface als één abonnement. Astro, Sanity en een statische host ontbundelen dat, waardoor elk onderdeel iets wordt dat je zelf bezit en versiebeheert.

Het helpt om precies te zijn over wat wat vervangt, omdat de meeste migratieplannen stilletjes een van deze vier taken verliezen en dat pas na de lancering merken.

Webflows visuele designer wordt Astro-componenten, geschreven als code en opgeslagen in Git. Webflows CMS wordt Sanity, een headless contentplatform met een gestructureerd schema en een eigen Studio. Webflows hosting wordt een statische host zoals Netlify, Vercel of Cloudflare Pages. Webflows Editor, de plek waar je marketingteam inlogt, wordt Sanity Studio plus, optioneel, een visuele lay-outtool zoals Stacki.

Bij de vierde taak gaat het vaak mis bij migraties. Teams plannen de eerste drie zorgvuldig en behandelen de bewerkingservaring als een bijzaak, om er vervolgens in week 6 achter te komen dat hun contentteam geen koptekst kan aanpassen zonder een ticket in te dienen.

Astro is de moeite waard om op eigen merites te beoordelen. Het verstuurt standaard geen JavaScript naar de browser en rendert naar statische HTML, waarbij interactiviteit alleen wordt toegevoegd waar je er expliciet om vraagt via het islands-model. Daarom scoren Astro-sites meestal goed op Core Web Vitals zonder veel optimalisatie. Het is echter een rendering-framework en niets meer dan dat. Het heeft geen CMS, geen editor en geen mening over waar je content moet staan.

Sanity vult dat gat op. Content wordt opgeslagen als gestructureerde documenten, opgevraagd met GROQ en bewerkt in een Studio die je in code configureert en samen met je site implementeert. Rich text wordt opgeslagen als Portable Text, een gestructureerde array in plaats van een HTML-blob, wat de content overdraagbaar maakt naar elk platform waarmee je het later wilt renderen.

‍

‍

Moet je überhaupt migreren van Webflow naar Astro?

Migreer wanneer je beperkingen structureel zijn en je team technisch is ingesteld. Blijf bij Webflow als je marketingteam wekelijks visueel lay-outs aanpast en je kosten redelijk zijn. Dat is de eerlijke versie, en het is de moeite waard om dat duidelijk te zeggen, want Codelevate is een Webflow Certified Professional Partner en bouwt wekelijks met Webflow. We beweren niet dat Webflow slecht is. We beweren dat het een specifiek hulpmiddel is met een specifieke vorm.

Wanneer migreren de juiste keuze is

De signalen die een migratie rechtvaardigen zijn concreet, niet esthetisch:

• Je loopt tegen harde platformlimieten aan. Webflow hanteert limieten voor CMS-collecties en items per site, en de Designer wordt merkbaar trager bij zeer grote collecties. Als je content-roadmap die limieten overschrijdt, loop je tegen een muur aan, ongeacht je budget.

• Je kosten schalen tegen je in. Webflow rekent per site, per gebruiker en per bandbreedte-tier. Een content-operatie die in alle drie de richtingen tegelijk groeit, levert een rekening op die sneller stijgt dan de waarde die het creëert.

• Je hebt een echte deployment-pipeline nodig. Branch-previews, pull request-reviews, geautomatiseerde tests, gefaseerde uitrol en CI-checks zijn standaard in softwareontwikkeling, maar niet beschikbaar in Webflow.

• Je site is een productoppervlak, geen brochure. Zodra je marketingsite behoefte heeft aan afgeschermde gebieden, dynamische prijslogica, diepe app-integratie of programmatische paginageneratie op schaal, vecht je tegen de beperkingen van de tool.

• Je team werkt al met code. Als de mensen die de site het meest aanpassen engineers zijn, is elke visuele abstractie tussen hen en het eindresultaat eerder een belemmering dan een hulp.

Wanneer je bij Webflow moet blijven

Het sterkste argument om te blijven is organisatorisch, niet technisch. De Editor van Webflow is oprecht goed, en een marketingteam dat zelfstandig landingspagina's kan publiceren is een echt concurrentievoordeel. Dat vervangen door een ticketwachtrij is een achteruitgang die geen enkele Lighthouse-score kan compenseren.

Blijf als je contentteam wekelijks lay-outs aanpast, niet alleen teksten. Blijf als je geen interne engineering-capaciteit hebt en ook niet van plan bent die aan te trekken, want een Astro- en Sanity-site heeft een eigenaar nodig. Blijf als je site minder dan 20 pagina's heeft en je totale Webflow-uitgaven verwaarloosbaar zijn. En blijf als je midden in een rebranding of een financieringsronde zit, want een platformmigratie is iets wat je niet tegelijkertijd met andere belangrijke zaken moet uitvoeren.

Nog één eerlijke kanttekening. Het argument voor AI-coding agents, dat Claude nu snel een site kan herbouwen, is reëel maar wordt vaak overdreven. Agents versnellen de herbouw aanzienlijk. Ze nemen niet de noodzaak weg voor iemand die kan zien wanneer de output niet klopt, en het laatste stukje van elke migratie is mensenwerk: spatiëring die net niet klopt, een animatie die niet lekker voelt, een redirect die stilletjes een 302 geeft in plaats van een 301.

‍

Wat Webflow je daadwerkelijk geeft bij vertrek

Webflow biedt drie exportpaden, en de verkeerde keuze kost je weken. De HTML-export levert een statische momentopname van je gepubliceerde pagina's met Webflow's eigen CSS. Het lijkt een vliegende start, maar dat is het niet.

De HTML-export verwijdert je CMS-inhoud volledig, aangezien collectiepagina's als één enkel sjabloon worden geëxporteerd, niet als data. Het verliest componentdefinities, varianten en alle ontwerpintenties die erachter schuilgaan. Het bevat Webflow's gegenereerde klassenamen, die visuele beslissingen coderen in plaats van semantische structuur. Behandel het als een visuele referentie voor de herbouw, net zoals je een screenshot zou gebruiken, en niets meer.

De paden die er echt toe doen, zijn de CMS-paden. Elke collectie kan direct vanuit de Webflow Designer als CSV worden geëxporteerd; dit is vaak voldoende en heeft als voordeel dat het makkelijk visueel te controleren is. Voor grotere of meer relationele sites biedt de Webflow Data API dezelfde inhoud programmatisch, waardoor de export herhaalbaar is wanneer je deze opnieuw moet uitvoeren na een content-freeze.

Er zijn twee valkuilen waar je voor moet oppassen voordat je begint. Webflow-referentie- en multireferentievelden worden geëxporteerd als ondoorzichtige item-ID's, dus je kunt collecties niet zomaar koppelen op namen of slugs. En rich text-velden komen eruit als HTML-strings, soms met Webflow-specifieke opmaak, wat betekent dat de conversie van rich text een serieuze taak is in plaats van simpelweg kopiëren en plakken.

Er is een vierde ding dat Webflow je helemaal niet geeft: je componentenoverzicht. Welke componenten er bestaan, welke varianten ze hebben en welke pagina's ze gebruiken, is alleen zichtbaar in de Designer. Noteer dat overzicht handmatig voordat je iets opzegt, want het is niet te herstellen vanuit een export en het is de input die je nodig hebt bij het ontwerpen van je Sanity page builder.

Een migratie-overgang kent dezelfde faalfactoren als elke andere site-lancering, alleen staan er meer URL's op het spel. Onze gratis 70-punten Webflow-lanceringschecklist is het pre-lanceringsproces dat we doorlopen voordat een klantensite live gaat, en het meeste daarvan is direct van toepassing op de onderstaande stappen.

‍

‍

Stap 1: Inventariseer alles voordat je ergens aan begint

Begin met een volledige inventarisatie, gekoppeld aan verkeersgegevens, niet alleen aan je sitemap. Je probeert twee vragen te beantwoorden: wat bestaat er, en wat verdient het om te overleven?

Haal elke geïndexeerde URL uit Google Search Console en elke route uit je sitemap, en koppel deze aan je analytics. Op de meeste sites blijkt een aanzienlijk deel van de pagina's kandidaat voor consolidatie of overbodig: oude landingspagina's van campagnes, dubbele servicepagina's, verweesde CMS-items die niemand in twee jaar heeft geopend. Beslissen wat je nu met pensioen stuurt is veel goedkoper dan het herbouwen en later beslissen.

Je inventarisatie moet meer omvatten dan alleen pagina's. Catalogueer elke CMS-collectie met het aantal items en de veldenlijst, elk formulier en waar de inzendingen naartoe gaan, elke embed en script van derden, elke Webflow Interaction die echt betekenis heeft in plaats van decoratie, en elk afgeschermd of met een wachtwoord beveiligd gebied. Noteer je top 50 pagina's op basis van organisch verkeer apart, want dat zijn de pagina's waar een fout in de redirects duur is.

‍

Stap 2: Modelleer de inhoud in Sanity, kopieer niet zomaar je collecties

Dit is de stap die een migratie onderscheidt van een transplantatie, en het is de stap die de meeste handleidingen in één zin overslaan. Modelleer wat je inhoud is, niet hoe Webflow het weergaf.

Webflow-collecties worden meestal Sanity-documenttypes, en die mapping is vaak helder. Maar een Webflow-collectie bevat vaak compromissen: een veld dat bestaat omdat de Designer het nodig had, een taxonomie opgeslagen als vrije tekst omdat Webflow-referentievelden onhandig waren, of drie bijna identieke collecties die eigenlijk één collectie met een type-veld hadden moeten zijn. Deze meenemen betekent dat je dubbel betaalt voor oude beslissingen.

Het belangrijkste onderscheid in Sanity is dat tussen documenten en objecten. Gebruik documenten voor zaken die herbruikbaar zijn of onafhankelijk worden beheerd, zoals een auteur, een case study of een dienst. Gebruik objecten voor inhoud die bij precies één ouder-document hoort, zoals een hero-sectie of een testimonial die nergens anders voorkomt. Dit in beide richtingen fout doen is de meest gemaakte modelleringsfout: alles als documenten maakt een onbeheersbare Studio, alles als objecten maakt hergebruik onmogelijk.

Ook voor je statische Webflow-pagina's moet je een beslissing nemen. Een homepage of prijspagina zonder verwante pagina's moet een singleton-document worden met een vast ID, in plaats van een item in een collectie van één. Pagina's die zijn opgebouwd uit herhalende, verplaatsbare secties moeten documenten worden met een page builder-array, waarbij elke sectie een objecttype is.

Gebruik voor het ontwerpen van die sectietypes de componentenlijst uit stap 1 in combinatie met de geëxporteerde HTML. Groepeer visueel vergelijkbare structuren, noteer waar varianten echt verschillen in betekenis in plaats van in styling, en geef de resultaten een semantische naam. Een sectie is een featureGrid, geen section-wrapper-dark-2. Webflow-klasnamen beschrijven het uiterlijk, en het uiterlijk is de taak van de frontend.

Voeg alleen variantvelden toe wanneer de variatie een redactionele keuze is die stabiel blijft, zoals toon, nadruk of layoutIntent. Maak niet voor elke visuele variatie die momenteel bestaat een apart variantveld aan.

‍

Stap 3: Exporteren vanuit Webflow en de content transformeren

Eerst een snapshot, dan transformeren. Haal de ruwe CSV- of API-output naar je schijf en commit deze voordat je ook maar één regel transformatiecode schrijft. Migraties worden vaak opnieuw uitgevoerd, meestal meer dan eens, en je wilt de mogelijkheid hebben om de transformatie opnieuw uit te voeren zonder Webflow opnieuw te hoeven benaderen.

Geef elk document een deterministisch ID dat is afgeleid van het Webflow-item-ID of de slug, in plaats van een willekeurig ID. Deze ene beslissing maakt de hele migratie idempotent. In combinatie met createOrReplace of createIfNotExists zorgt dit ervoor dat het tweemaal uitvoeren van de import tot hetzelfde resultaat leidt in plaats van dat je hele contentbibliotheek wordt gedupliceerd.

De importvolgorde volgt de afhankelijkheden. Begin met de collecties op het laagste niveau, waar niets anders naar verwijst maar waar alles naar verwijst: categorieën, tags, auteurs, locaties. Bouw vervolgens een opzoekkaart van Webflow-item-ID's naar Sanity-document-ID's en importeer de afhankelijke collecties met behulp daarvan. Omdat je ID's deterministisch zijn, kun je verwijzingen maken naar documenten die nog niet bestaan en deze laten oplossen naarmate de import vordert.

Rich text is een vak apart. Webflow levert HTML, terwijl Sanity Portable Text verwacht: een gestructureerde array van blokken in plaats van een string. Omzeil dit niet door de ruwe HTML in een tekstveld op te slaan. Het werkt misschien de eerste dag, maar blokkeert elke toekomstige wijziging: je kunt het niet opnieuw stylen, niet renderen in een andere frontend en er niet in zoeken. Converteer expliciet en behandel inline afbeeldingen, links, embeds en lijsten als bewuste gevallen in plaats van te hopen dat de converter het bij het rechte eind heeft.

Normaliseer tijdens het proces. Echte CSV-exports bevatten lege kolommen, boolean-achtige strings, inconsistente spellingen in taxonomieën en af en toe een dubbele slug. Los deze op in de transformatie, niet door de live Webflow CMS te bewerken, want dat maakt de bron alleen maar moeilijker opnieuw te exporteren.

‍

Stap 4: Verplaats de assets van het Webflow CDN

Migreer elke asset naar Sanity voordat je de documenten importeert die ernaar verwijzen, en vervang daarna de Webflow CDN-URL's. Productiecontent laten verwijzen naar het CDN van Webflow is de stille faalfactor van halfslachtige migraties: alles ziet er bij de lancering goed uit, maar maanden later verloopt het Webflow-abonnement en verdwijnen de afbeeldingen van de hele site.

Assets zitten op meer plekken dan alleen de voor de hand liggende afbeeldingsvelden. Verzamel URL's uit CSV-afbeeldingskolommen, uit rich text HTML, uit statische pagina-HTML, uit je CSS-achtergronden en uit Open Graph- en Twitter-kaartmetadata. Die laatste categorie wordt snel vergeten en zorgt voor kapotte previews wanneer je content wordt gedeeld.

Zodra assets in Sanity staan, krijg je de image pipeline erbij als bonus: on-the-fly transformaties, formaatonderhandeling, en hotspot- en crop-metadata die redacteuren per afbeelding kunnen instellen en die elk template respecteert.

‍

Stap 5: De frontend opnieuw opbouwen in Astro

Bouw opnieuw op in componenten, niet in geconverteerde HTML. De verleiding is groot om geëxporteerde markup in Astro-bestanden te plakken en door te gaan, maar dat levert een codebase op die technisch gezien in Astro is, maar in de praktijk nog steeds Webflow, compleet met bijbehorende klasnamen en structurele eigenaardigheden.

Sanity's officiële Astro-integratie regelt de verbinding. Het @sanity/astro-pakket koppelt een geconfigureerde client, stelt deze beschikbaar aan je componenten en ondersteunt het hosten van Sanity Studio als een route binnen hetzelfde project. Het ondersteunt ook de Presentation-tool en visuele bewerkingsoverlays voor een server-rendered Astro-frontend, wat van groot belang is voor stap 7.

Drie onderdelen van de herbouw duren steevast langer dan teams inschatten.

Interacties komen eerst. Webflow-interacties worden niet in een bruikbare vorm geëxporteerd, dus alles wat verder gaat dan een CSS-hover-state moet opnieuw worden opgebouwd, meestal in GSAP of met native browser-API's. Voer hier tijdens de inventarisatie een eerlijke audit op uit, want de meeste sites hebben er een paar die ertoe doen en een lange staart aan interacties die niemand zou missen als ze zouden verdwijnen.

Formulieren komen als tweede. Webflow regelt inzending, opslag, spamfiltering en notificaties als één ingebouwde functie. In Astro stel je dit samen uit een formulierafhandelaar, wat je host ook biedt of een specifieke service, plus je CRM-integratie en een spamstrategie.

Zoekfunctionaliteit is de derde, als je die hebt. De site-zoekfunctie van Webflow verdwijnt, en de gebruikelijke vervanging op een statische site is een index die tijdens het build-proces wordt aangemaakt, waarbij Pagefind de meest gekozen optie is.

‍

Stap 6: Bescherm de SEO vóór de lancering, niet erna

Maak het redirect-overzicht voordat je de pagina's bouwt. Ontbrekende of onjuiste 301-redirects, en niet de platformwissel zelf, zijn de grootste oorzaak van verkeersverlies bij migraties, en dit is volledig te voorkomen.

Crawl elke oude URL, inclusief CMS-itempagina's, categoriepagina's en gepagineerde routes, en koppel ze elk aan hun nieuwe bestemming. Waar slugs hetzelfde blijven, houd ze dan ook hetzelfde; URL-pariteit is gratis en elke wijziging die je vermijdt, is een risico dat je uitsluit. Waar pagina's worden samengevoegd of verwijderd, verwijs ze dan naar het meest relevante alternatief in plaats van alles standaard naar de homepage te sturen, wat zoekmachines als een 'soft 404' beschouwen.

Naast redirects moeten vier zaken intact blijven. Metadata, oftewel titels, beschrijvingen en canonical-tags, pagina voor pagina in plaats van via templates die alles hetzelfde maken. Gestructureerde data, opnieuw opgebouwd om overeen te komen met wat je had, aangezien Webflow-sites vaak schema's bevatten die via aangepaste code zijn toegevoegd en die je makkelijk vergeet. Open Graph-afbeeldingen, die stilletjes kapotgaan en pas opvallen wanneer iemand een link deelt. En je sitemap, gegenereerd door de sitemap-integratie van Astro en op de dag van lancering opnieuw ingediend in Search Console.

Houd het daarna in de gaten. Bewaar de lijst met oude URL's en crawl deze tegen de productieomgeving na de overstap om redirect-ketens en onbedoelde 302-fouten op te sporen. Verwacht enige schommelingen in de ranking in de eerste twee weken en monitor de resultaten minstens 30 dagen voordat je conclusies trekt.

‍

Stap 7: Ga live zonder downtime

Bouw alles op een preview-URL en bewaar de DNS-wijziging voor het laatst. Je Webflow-site blijft de hele tijd normaal verkeer bedienen, wat de tijdsdruk wegneemt en betekent dat een overstap met een dag kan worden uitgesteld zonder dat iemand het merkt.

De volgorde die werkt is eenvoudig. Deploy de Astro-site naar een staging-domein en valideer deze aan de hand van de inventarisatie uit stap 1, pagina voor pagina voor de belangrijkste pagina's en via steekproeven voor de rest. Kondig een content-stop aan in Webflow, kort, meestal 24 tot 48 uur. Voer de export en import opnieuw uit om alles wat tijdens de bouw is gepubliceerd mee te nemen; dit is pijnloos juist omdat je ID's deterministisch zijn. Wijs de DNS naar de nieuwe host. Dien de nieuwe sitemap in. Crawl de oude URL-lijst tegen de productieomgeving en los alles op wat niet correct doorverwijst.

Houd het Webflow-siteplan nog één facturatiecyclus actief na de overstap. Het is een goedkope verzekering, het geeft je een referentie voor alles wat je mogelijk over het hoofd hebt gezien, en het betekent dat een rollback een DNS-wijziging is in plaats van een noodsituatie.

‍

Wie beheert de site nadat je Webflow hebt verlaten?

Dit is de vraag die bepaalt of de migratie de moeite waard was, en er zijn drie antwoorden die samenwerken.

Sanity Studio beheert de content. Elk gestructureerd veld dat je redacteuren aanpassen – blogposts, casestudy's, servicepagina's, teamleden – bevindt zich in een Studio die je configureert en met de site deployt. Met de geconfigureerde Presentation-tool krijgen redacteuren een zij-aan-zij preview van de echte pagina met klik-om-te-bewerken overlays, wat qua contentwijzigingen dicht in de buurt komt van de Webflow Editor-ervaring. De conceptmodus zorgt ervoor dat ze ongepubliceerd werk in context zien voordat er iets live gaat.

Stacki beheert de lay-out. Het is een gratis, open-source, MIT-gelicentieerde visuele builder die lokaal draait op een Astro-project dat je al hebt, en het schrijft echte bestanden in plaats van een aparte export te genereren. Je koppelt het aan je projectmap en kunt vervolgens visueel pagina's indelen, variabelen van het design-systeem aanpassen, contentcollecties beheren en component-props configureren. Voor teams die vooral bang zijn om de visuele controle te verliezen, is dit de oplossing. Het is een jonge tool, dus het is de moeite waard om deze te evalueren aan de hand van je eigen project voordat je besluit het als primaire bewerkingsmethode te gebruiken.

Claude beheert al het overige, en dit is waar het operationele model echt verandert in plaats van alleen maar verschuift. Een nieuwe landingspagina, een schema-veld, een componentvariant, een redirect-regel, een tekstwijziging op 40 pagina's: dit worden verzoeken in natuurlijke taal aan een repository, die vervolgens worden uitgevoerd, beoordeeld in een pull request en geïmplementeerd.

‍

‍

Hoe Claude het operationele model verandert, niet alleen de herbouw

De meeste berichtgeving over AI bij migraties stopt bij de herbouw, alsof de waarde een eenmalige snelheidsboost is. De duurzame verandering is wat er in de zevende maand gebeurt.

Bij Webflow wordt de grens voor site-wijzigingen bepaald door de Designer en wie daar toegang toe heeft. Bij een Astro- en Sanity-codebase wordt de grens bepaald door hoe duidelijk iemand kan omschrijven wat hij wil. Claude kan de volledige repository lezen, je componentenbibliotheek en Sanity-schema begrijpen en consistente wijzigingen doorvoeren in beide. Het werk komt binnen als een pull request met een preview-implementatie, wat betekent dat het wordt beoordeeld als code in plaats van gepubliceerd als een gok.

We speculeren hier niet over. Codelevate draait Claude al via de MCP-connector tegen Webflow aan, en we hebben beschreven hoe we Webflow-sites beheren met AI. De vergelijking is direct: de connector is oprecht goed voor contentoperaties en bulk-CMS-werk, maar beperkt voor structurele wijzigingen, omdat de mogelijkheden van een API binnen een visuele builder nu eenmaal eindig zijn. Bij een codebase verdwijnt die grens grotendeels. Dat verschil is, meer dan hostingkosten of Lighthouse-scores, het sterkste argument voor de migratie op dit moment.

Twee eerlijke kanttekeningen. Een agent die in een codebase werkt, heeft de vangrails nodig die elke codebase veilig maken: pull request-beoordeling, preview-implementaties, type-checking en iemand met verstand van zaken die de diff controleert. En het laatste deel van elke door een agent ondersteunde herbouw is handmatig verfijnwerk: het visuele oordeelsvermogen dat agents nog steeds subtiel fout doen.

‍

Wat een migratie van Webflow naar Astro en Sanity kost en hoe lang het duurt

Houd rekening met 4 tot 8 weken en een projectprijs van vijf cijfers voor een typische marketingsite van 50 tot 100 pagina's met een paar CMS-collecties. Kleine sites onder de 20 pagina's met schone content kunnen in ongeveer 2 weken klaar zijn. Sites met grote, relationele contentmodellen en complexe interacties duren langer dan 8 weken, en een site met meer dan een paar duizend CMS-items verspreid over veel collecties moet op basis van eigen specificaties worden ingeschat.

De kostenfactoren zijn niet wat mensen verwachten. Het aantal pagina's is veel minder belangrijk dan de complexiteit van het contentmodel, want 200 pagina's op basis van één schoon sjabloon is minder werk dan 30 pagina's met maatwerk-lay-outs. De echt dure onderdelen zijn het aantal verschillende paginasectiepatronen, het aantal Webflow-interacties met echte functionele waarde, contentmodellen met veel verwijzingen en alles wat afgeschermd of beveiligd is.

De operationele kosten daarna dalen voor de meeste teams aanzienlijk, hoewel niet tot nul. Statische hosting voor een marketingsite is meestal gratis of bijna gratis. Sanity heeft een gratis laag voor kleine teams en hanteert prijzen per gebruiker daarboven. Daar staat tegenover dat je nu zelf verantwoordelijk bent voor het onderhoud, en een eerlijke berekening omvat ook de tijd van degene die afhankelijkheden up-to-date houdt en zorgt dat de site blijft draaien.

Waar teams de berekening vaak fout doen, is door het Webflow-abonnement alleen met hosting te vergelijken. De juiste vergelijking omvat ook de engineering-tijd die je setup vereist, en voor een marketinggericht team zonder eigen engineers is dat getal hoog genoeg om bij Webflow blijven de goedkopere optie te maken.

‍

Hoe Codelevate deze migratie aanpakt

Wij beschouwen het contentmodel als het eindproduct en de frontend als het gevolg. In de praktijk betekent dit dat we de eerste fase besteden aan inventarisatie en het ontwerp van het Sanity-schema. De componenteninventaris wordt door een mens beoordeeld voordat het schema definitief wordt, omdat een page builder die uitsluitend op basis van geëxporteerde HTML is ontworpen, de visuele keuzes van Webflow permanent verankert.

We bouwen extractie- en importscripts met deterministische ID's in plaats van eenmalige operaties, zodat de volledige migratie na een content-freeze zonder zorgen opnieuw kan worden uitgevoerd. Vóór de overstap valideren we alles aan de hand van een vaste checklist: het aantal rijen moet overeenkomen met de Webflow-collecties, elk referentieveld moet correct verwijzen, rich text wordt steekproefsgewijs gecontroleerd op links, afbeeldingen en embeds, elke Webflow CDN-URL wordt vervangen en elke oude URL wordt gecontroleerd op de nieuwe site.

We zijn vooraf eerlijk tegen klanten over het bewerkingsmodel voordat er iets wordt getekend, omdat daar vaak de spijt na de lancering vandaan komt. Als een marketingteam meer verliest dan wint, zeggen we dat direct. Om die reden hebben we al veel klanten met plezier op Webflow gehouden. Je kunt de opzet van onze trajecten bekijken op onze websiteontwikkeling pagina.

‍

Conclusie

Migreren van Webflow naar Astro en Sanity is de moeite waard wanneer je tegen structurele beperkingen aanloopt en je team in staat is om met een codebase te werken. Het technische werk is duidelijk: exporteer via de Data API in plaats van de HTML-export, modelleer content semantisch in Sanity in plaats van collecties simpelweg te kopiëren, verplaats assets van het Webflow CDN, bouw de redirect-map voordat je de pagina's bouwt en schakel over via DNS terwijl de oude site nog live staat.

Wat je in feite koopt, is een ander operationeel model. Een website die in een repository leeft, kan worden aangepast door iedereen die de wijziging helder kan omschrijven, kan worden beoordeeld als software en kan veilig worden uitgerold. Dat is de transformatie en tegelijkertijd de test: als je team niet op die manier wil werken, zal de migratie zichzelf niet terugverdienen, hoe netjes de bouw ook is.

Voer vóór elke overstap de basisstappen voor een lancering correct uit. Onze gratis 70-punten Webflow-lanceringchecklist dekt de SEO-, prestatie- en redirect-controles die bepalen of een nieuw platform zijn rankings behoudt, ongeacht de stack waar je op uitkomt.

Als je deze beslissing overweegt en een eerlijk antwoord wilt of het zinvol is voor jouw site, plan dan een gratis gesprek met ons team. Wij bouwen op beide stacks en vertellen je eerlijk op welke jij zou moeten zitten.

‍

‍