Websitemigratie: stapsgewijze handleiding met een praktijkvoorbeeld

Een website migreren kan heel eenvoudig zijn.

Het kan natuurlijk ook heel complex zijn. Dat hangt af van wat er in elk afzonderlijk geval nodig is.

In dit artikel leg ik je echter uit hoe je een website migreert in een vrij standaardscenario:

De website migreren wanneer je een rebranding en renaming van een merk uitvoert, maar veel wilt hergebruiken van wat al op de website staat en werkt.

Zoals ik al zei, komt dit vrij vaak voor en kan het verschillende scenario’s met zich meebrengen:

• Het project dat ik leidde bij TiendAnimal en dat vier maanden werk omvatte.
• Dat van Lowi, dat kleiner was en in een paar maanden klaar was, ondanks dat het zowel de website als de twee apps betrof.
• Of het project dat ik hier als voorbeeld ga gebruiken: het advocatenkantoor García Méndez, dat ik in één maand volledig uitvoerde door er elke week een paar uur aan te besteden. Dat zou ongeveer 3 volledige werkdagen zijn geweest als ik het achter elkaar had gedaan.

Waarin verschilden ze van elkaar?

In de omvang van de migratie en de complexiteit van de website.

Bij TiendAnimal zijn alle CSS en waar nodig delen van de HTML-structuur aangepast, om van een voor pc gemaakte website over te stappen naar een responsive website, met behoud van content en domein.

Bij Lowi ging het ook om een stilistische wijziging, alleen bleef de HTML-structuur onaangeroerd en was de website veel eenvoudiger.

En bij García Méndez maakten het migreren van het domein, het toevoegen van content en de visuele aanpassingen het werk alsnog veel eenvoudiger doordat er onder de motorkap een CMS als WordPress draaide met vrijwel geen maatwerkontwikkeling.

Voordat ik uitleg wat er allemaal moet gebeuren, moet je bepaalde concepten helder hebben, zodat je op elk moment weet waar we het over hebben.

Maar als je ze al kent en meteen naar de stap-voor-stap tutorial wilt, hoef je alleen hier te klikken.

Concepten en aandachtspunten vóór de migratie

Een websitemigratie kan verschillende aspecten omvatten, die ik hieronder bespreek.

Omdat ik alle mogelijkheden probeer te behandelen, waarschuw ik je alvast dat sommige delen wat technisch zijn.

Ik heb wel geprobeerd ze zo toegankelijk mogelijk te maken, zodat iedereen met enige technische kennis van hoe hosting werkt ze kan begrijpen.

Hier geef ik je alvast een schema zodat je de verschillende scenario’s die ik ga uitleggen duidelijk voor ogen hebt:

• Het domein wel of niet migreren
• De content van de website migreren. CMS’en
• #1. Noch het CMS, noch de installatie migreren
• #2. Het CMS behouden, maar de installatie migreren
• WordPress migreren naar een andere WordPress-installatie
• #3. Naar een ander CMS migreren
• WordPress migreren naar een ander CMS
• Hosting wel of niet migreren. WordPress binnen dezelfde hosting migreren

• WordPress naar een andere hostingprovider migreren

Het domein migreren

Het domein is je naam op internet. Dat is wat je bij de provider afneemt. Voor deze website is het domein yagogonzalez.com.

Ja, inclusief de .com. Want yagogonzalez.net is een ander domein.

Wanneer we dus spreken over het migreren van een domein, veranderen we onze naam op internet. In het voorbeeld dat we gebruiken, veranderden we garciamendezabogados.com in abogadosdegalvezygarciamendez.com.

Ondanks mijn weerstand tegen zo’n ongelooflijk lang domein was dat de keuze van de klant. Daar valt weinig meer aan toe te voegen.

Het punt is dat een domein wijzigen niet simpelweg betekent dat je de naam verandert en klaar.

Ten eerste moet je, als je delen van de website gaat hergebruiken, alle interne links aanpassen. Als je niets gaat hergebruiken, is dat niet nodig.

Ten tweede moet je het goed aanpakken als je aan SEO werkt, zodat je de posities van belangrijke pagina’s niet verliest, met het daaruit voortvloeiende verlies aan conversies.

In dit geval:

• We gaan (bijna) de hele website hergebruiken.
• We werken aan SEO en staan voor verschillende van de belangrijkste zoekwoorden in de top 3.

Dat betekent dat er bij de migratie meer werk te doen is.

De content van de website migreren

Als we over content spreken, bedoelen we vooral de teksten en afbeeldingen in de hoofdinhoud van de pagina. Niet zozeer die in de header of footer.

Je moet dus weten dat er twee manieren zijn om deze content te migreren:

• De tekst en afbeeldingen overnemen zoals ze zijn, alsof het een Word-document is.
• De HTML-code van dit deel van de website overnemen en hergebruiken.

Bij deze twee methoden komt nog de vraag of de content exact wordt gekopieerd of een wijziging ondergaat.

In ons voorbeeld:

• We hergebruiken de HTML-code die in de database is opgeslagen, omdat we hetzelfde CMS blijven gebruiken.
• De content wordt echter aangepast, omdat de oorspronkelijke website in de eerste persoon enkelvoud was geschreven (Fernando García Méndez sprak). De nieuwe website is daarentegen van twee advocaten, waardoor de teksten niet langer vanuit ‘ik’, maar vanuit ‘wij’ kunnen worden geschreven. Met alles wat dat voor de tekstredactie betekent. Zowel in het Spaans als in het Engels.

Ik kan je nu al vertellen dat dit een van de onderdelen was die tijdens de migratie de meeste uren kostte. En er is niets technisch of marketingachtigs aan: het is puur tekst nakijken.

En als we over content praten, moeten we het ook over CMS’en hebben en over de vraag of een migratie nodig is.

CMS’en

CMS staat voor Content Management System en dient precies daarvoor: de content van een website beheren.

Tegenwoordig is het uiterst moeilijk om websites tegen te komen die met pure HTML zijn gebouwd, omdat die beslist lastiger te beheren zijn, vooral als de content dynamisch is en in de loop van de tijd verandert.

Van alle CMS’en is het populairste ter wereld WordPress, dat voor bijna elk type website geschikt is, al kan het voor zeer grote projecten tekortschieten.

Bij het migreren van een website kunnen we dus van CMS veranderen of hetzelfde CMS behouden.

En we kunnen hetzelfde CMS behouden (bijvoorbeeld WordPress) op dezelfde installatie en daarop de wijzigingen uitvoeren, of een nieuwe WordPress-installatie elders installeren, de code en database van de oude site klonen en op de nieuwe installatie werken.

Met andere woorden: er spelen twee variabelen — het CMS en de bijbehorende installatie — die drie mogelijke scenario’s opleveren:

1. Noch het CMS, noch de installatie wijzigen: met andere woorden, wijzigingen aanbrengen op de huidige website.
2. Het CMS behouden, maar een nieuwe installatie gebruiken: we houden WordPress, PrestaShop of welk CMS dan ook, maar maken een nieuwe installatie en werken daarop.
3. Zowel het CMS als de installatie wijzigen: bijvoorbeeld overstappen van WordPress naar PrestaShop. Ook als dit binnen hetzelfde hostingaccount kan, zijn het verschillende installaties met volledig verschillende databases.
4. Van CMS veranderen maar de installatie behouden: dat kan niet. Daarom zei ik eerder dat er drie scenario’s waren en geen vier.

Laten we elk van deze opties nu uitgebreider bekijken.

#1. Noch het CMS, noch de installatie migreren

We beginnen met de eenvoudigste optie. Want je moet weten dat migreren naar een ander CMS ALTIJD complexer is dan het niet doen. Maar dat betekent niet dat bij hetzelfde CMS blijven altijd het beste is. Dat hangt van elk geval af.

Bij de website van de advocaat hebben we overwogen dezelfde WordPress-installatie te behouden en ons te beperken tot de wijzigingen daarop.

Het belangrijkste voordeel van deze aanpak is de tijdsbesparing: je hoeft niets op serverniveau te doen, alleen de rebrandingwijzigingen in WordPress door te voeren en klaar.

Het nadeel is dat gebruikers, doordat je aan de livewebsite werkt, de wijzigingen zien terwijl je ze uitvoert, wat een vreemde ervaring oplevert.

Zowel bij TiendAnimal als bij Lowi kozen we voor deze aanpak bij de rebranding. Om dit nadeel te omzeilen, werkten we met een lokale versie en een stagingversie (twee verschillende installaties), die konden worden aangepast zonder de productiewebsite te beïnvloeden.

Voor de website van García Méndez vond ik het niet nodig om deze stack op te zetten.

#2. Het CMS behouden, maar de installatie migreren

Bij deze tweede optie blijven we bij WordPress, PrestaShop of welk CMS dan ook, maar in plaats van op de huidige installatie te werken, gebruiken we een nieuwe.

WordPress migreren naar een andere WordPress-installatie

Met andere woorden: de huidige WordPress-installatie vervangen door een andere, op dezelfde server of op een andere.

Dit is wat we uiteindelijk voor de advocaten deden: twee verschillende gepubliceerde versies, waarbij de oude naar de nieuwe doorstuurde zodra die klaar was.

Een voordeel is dat de oude site actief en ongewijzigd blijft terwijl er aan de nieuwe wordt gewerkt, zodat klanten niets ongewoons merken.

Daarnaast is het belangrijkste voordeel van het gebruik van een andere installatie dat je die als back-up hebt, zodat je haar later kunt herstellen als de dingen niet verlopen zoals verwacht.

Als je technisch bent, zul je me vertellen dat een nieuwe branch in een Git-repository dat oplost. Maar voor een website als deze vind ik het niet de moeite waard om dat op te zetten.

#3. Naar een ander CMS migreren

We gaan door naar de derde en laatste optie: van CMS veranderen.

WordPress migreren naar een ander CMS

Bij webshops is het gebruikelijk om van WordPress (met de plugin WooCommerce) over te stappen op PrestaShop of Shopify wanneer de schaal toeneemt.

In al deze gevallen kunnen scripts wel helpen, maar bij grote websites zijn deze migraties niet eenvoudig en zeker niet gemakkelijk. Na afloop zijn veel controles nodig.

Om dezelfde reden veranderen informatieve of bedrijfswebsites minder vaak van CMS, omdat de voordelen of verschillen tussen het ene en het andere CMS voor dit soort sites meestal niet groot genoeg zijn en de migratiekosten het doorgaans niet de moeite waard maken.

Hosting wel of niet migreren

Dit is bijna altijd optioneel.

Tenzij je overstapt van een op een server installeerbaar CMS (WordPress) naar een SaaS-platform (Shopify), waarbij je de hosting niet zelf beheert omdat zij dat voor je doen, kun je kiezen of je de server wel of niet migreert.

Het spreekt voor zich dat van hosting veranderen meer werk kost dan bij dezelfde provider blijven, zelfs als we een nieuwe CMS-installatie gebruiken terwijl we op dezelfde hosting blijven.

WordPress binnen dezelfde hosting migreren

Met andere woorden: we maken een nieuwe installatie binnen hetzelfde hostingaccount en migreren de gegevens en content.

Bij elke normale webhostingdienst is dit relatief eenvoudig, omdat de hostingtools zelf (in cPanel of welk controlepaneel er ook wordt gebruikt) een optie bevatten die ‘WordPress klonen’ heet — of iets vergelijkbaars — waarbij we alleen de directory of het subdomein hoeven op te geven waarnaar het moet worden gekloond, waarna het systeem praktisch al het werk voor ons doet.

En we kunnen dit doen met het oorspronkelijke domein of elk ander domein dat aan het hostingaccount is gekoppeld.

Eerlijk gezegd is het fantastisch voor migraties, het maken van back-ups of het forken van een webproject.

Dat gezegd hebbende, moet je vóór je begint controleren of je hostingpakket toestaat een nieuwe database te maken of meer domeinen te koppelen dan er nu gekoppeld zijn.

Dit is wat ik met de website van het advocatenkantoor heb gedaan. Verderop leg ik het zeer eenvoudige proces uit.

WordPress naar een andere hostingprovider migreren

Om van hosting te veranderen, is het het gemakkelijkst om een WordPress-plugin.

te gebruiken. Er zijn er veel die dit doen (All In One WP Migration, XCloner, Duplicator…), hoewel je bij verschillende daarvan de betaalde versie nodig hebt om alles eenvoudig klaar te zetten.

In een toekomstig artikel leg ik uit hoe je dit gratis doet, voor het geval je het nodig hebt en geld wilt besparen in ruil voor wat extra tijd.

Ons praktijkvoorbeeld

Goed, na alle mogelijke combinaties bij het migreren van een website te hebben uitgelegd, is de combinatie die ik hier heb gebruikt — en als voorbeeld in de tutorial zal gebruiken — de volgende:

• Domeinmigratie:
• Ja, van garciamendezabogados.com naar abogadosdegalvezygarciamendez.com.
• Migratie van websitecontent: wijzigingen aan de content en structuur van de website, waarbij veel van het bestaande werk wordt hergebruikt. Een nieuw ontwerp dat aansluit bij de nieuwe huisstijl.

• Cambio de diseño web, adecuándose a la nueva identidad corporativa.

• Wijziging van CMS: nee, we blijven bij WordPress.

Migratie van hosting en installatie: nieuwe WordPress-installatie.

• Binnen hetzelfde hostingaccount.

Een veelvoorkomend scenario, niet het eenvoudigste en ook niet het complexste. Het dient als gids die je kunt herhalen wanneer je die nodig hebt.

Stappen om de website te migreren

Nu de voorlopige concepten duidelijk zijn en de context is geschetst, gaan we verder met de stap-voor-stap tutorial.

Eerst een samenvatting in videovorm:

En daarna de uitgebreide stap-voor-stap handleiding in tekst.

BELANGRIJK: in dit geval vullen de video en de tekst elkaar aan, dus als dit je eerste migratie is en je alle informatie wilt, raad ik je aan eerst de video te bekijken en daarna de geschreven stap-voor-stap handleiding te volgen.

#1. Het domein aan het hostingaccount toevoegen

Dit is alleen nodig als we het domein migreren. Als we hetzelfde domein behouden, hoeft het niet.

Als we het domein van de website wijzigen, is het koppelen van het domein aan het hostingaccount dus de eerste stap.

Er zijn twee mogelijkheden:

• Als je het domein waarnaar je wilt migreren via hetzelfde hostingaccount hebt gekocht, is dit al geregeld.
• Als je het domein bij een andere domeinprovider hebt gekocht, moet je het nieuwe domein aan het hostingaccount toevoegen en ook de DNS-instellingen bij de domeinprovider aanpassen, zodat ze naar onze hosting verwijzen.

In dit geval is het nieuwe domein gekocht via hetzelfde account waarop de hosting stond, zodat we het niet hoefden te koppelen.

Overigens zijn alle screenshots van de hosting afkomstig uit het klantgedeelte en controlepaneel van Webempresa, maar ze zijn doorgaans vergelijkbaar bij alle betrouwbare WordPress-hostingproviders.

#2. De website klonen

Hier geen plugins.

Omdat we dezelfde hosting gebruiken, gaan we, zoals ik eerder uitlegde, een tool van het hostingbedrijf gebruiken (geen WordPress-plugin) waarmee we de website kunnen klonen door het domein en de directory te kiezen van waaruit deze toegankelijk wordt:

Eerlijk gezegd is deze optie fantastisch voor mensen zoals wij die geen ontwikkelaar zijn.

Onthoud wel dat dit niet werkt als je de website om welke reden dan ook op een andere server wilt opzetten; dan zullen we plugins moeten gebruiken.

#3. HTTPS toevoegen

In de vorige stap konden we misschien niet kiezen welk protocol voor de installatie van de nieuwe website werd gebruikt.

Geen probleem: binnen hetzelfde hostingaccount kunnen we vragen dit voor ons te wijzigen:

Omdat we dit echter niet vanaf het begin hebben gedaan, kunnen er in de WordPress-database interne links staan die naar HTTP-URL’s verwijzen.

Om dit te controleren, kunnen we Screaming Frog:

Daarna corrigeren we handmatig alle overgebleven links in het betreffende deel van WordPress (er kunnen er nog in widgets of in de footer staan).

#4. Voorkomen dat Google de site crawlt

Omdat we op de gekloonde website gaan werken, willen we niet dat Google deze website indexeert, want dat zou dubbele content zijn.

Hiervoor schakelen we in de WordPress-opties (onder de leesinstellingen) deze optie op de nieuwe website in:

#5. De huisstijlkleuren wijzigen

Dit hangt af van hoe omvangrijk de benodigde wijzigingen zijn, maar je zult zeker verschillende onderdelen moeten aanpassen.

Kleurwijzigingen in het thema

In ons thema (Genesis Framework) gebeurt dit via Weergave / Customizer / Kleuren:

Kleurwijzigingen in CSS

Misschien heb je ze aangepast via Weergave / Customizer / Extra CSS:

Kleurwijzigingen in plugins

Het hangt af van welke je hebt geïnstalleerd. In ons geval waren het de volgende.

WhatsApp:

Belknop:

Contactformulieren:

#6. Het logo en de favicon wijzigen

Voor de header doe je dit via Weergave / Customizer / Site-identiteit:

En het is veel eenvoudiger als je het nieuwe logo kunt aanpassen aan dezelfde afbeeldingsafmetingen als het vorige. Zo voorkom je dat je al het responsive gedrag opnieuw moet controleren.

Als je een plugin zoals Yoast SEO hebt, wil je het hier waarschijnlijk ook wijzigen:

Zodat deze afbeelding in de Schema – en Open Graph -gegevens verschijnt.

#7. Teksten en afbeeldingen wijzigen

Als hier wijzigingen nodig zijn, wordt dit de langste stap, zonder twijfel.

Je moet elke URL openen die je wilt wijzigen (pagina’s en blogartikelen, waar van toepassing) en bijwerken wat nodig is:

In ons voorbeeld moest ik de invalshoek veranderen — van spreken als ‘ik’ naar spreken als ‘wij’ — en dat kostte behoorlijk wat tijd.

Daarnaast moest ik dit doen in het Engels en Spaans. En natuurlijk moest ik ook denken aan de juridische teksten.

On-page SEO-optimalisatie

Als je aan SEO werkt, moet je op dit punt het volgende aanpassen:

• Titel
• Beschrijving
• Alt-tekst van afbeeldingen

Voor elke URL:

In dit geval niet zozeer voor de SEO zelf (die was al geoptimaliseerd), maar voor de branding, om de nieuwe merknaam waar nodig in te voegen:

#8. Nieuwe secties maken

De overgang van één hoofdadvocaat naar twee betekende dat we secties voor de tweede advocaat moesten maken, plus een sectie ‘Over ons’ die eerder niet nodig was:

Niet altijd, maar het is niet ongebruikelijk dat een rebranding of grote merkverandering leidt tot het maken van nieuwe secties, het bijwerken van de Over-ons-sectie of het toevoegen van een blogartikel waarin de redenen voor de verandering worden uitgelegd.

#9. De website herstructureren

Soms wordt een migratie aangegrepen om de structuur van de website te wijzigen.

Dat kan de zaken eenvoudiger of moeilijker maken, want als de wijziging ingrijpend is, is het misschien niet nodig om 301-redirects te overwegen omdat ze vanuit SEO-oogpunt geen zin hebben, terwijl kleine wijzigingen ze toch nodig kunnen maken.

In ons voorbeeld was de enige wijziging de al genoemde toevoeging van de Over-ons-sectie, waaronder de bestaande profielpagina van Fernando en de nieuwe van Pablo kwamen te staan.

#10. De menu’s wijzigen

Natuurlijk moeten de menu’s worden bijgewerkt, hoe klein de structurele wijziging ook is.

In dit geval heb ik via Weergave / Menu’s twee items toegevoegd om toegang tot de nieuwe secties te bieden:

#11. Nieuwe zakelijke e-mailaccounts maken

We veranderen kort van onderwerp en maken de nieuwe e-mailaccounts in het hostingaccount, één voor elke advocaat en één algemeen contactadres:

We hebben ze nodig voor stap 13.

#12. Ze aan Gmail-accounts koppelen

Omdat webmaildiensten van hostingproviders meestal niet de handigste manier zijn om zakelijke e-mail te beheren en bijna iedereen Gmail kan gebruiken, gaan we nu de in de vorige stap aangemaakte accounts aan nieuwe Gmail-accounts koppelen.

Via de vorige link vind je een volledige stap-voor-stap tutorial.

#13. Het adres in de contactformulieren en op de website wijzigen

Natuurlijk moeten de formulieren op de nieuwe website berichten naar de nieuwe zakelijke e-mailadressen sturen, dus wijzigen we ze in elk formulier:

#14. De contactgegevens wijzigen

Aansluitend op het vorige punt wijzigen we niet alleen waar de websiteformulieren berichten naartoe sturen, maar werken we ook de contactgegevens.

bij. Minstens de e-mailadressen. En in ons geval ook de telefoonnummers.

Bij de sociale netwerken was dat niet nodig, omdat de oude voorlopig blijven bestaan en ik de links dus niet hoefde te wijzigen. Bedenk of je deze links in jouw geval moet bijwerken.

Je moet dit overal doen waar ze voorkomen. De meest voorkomende plaatsen zijn de contactpagina, widgets, footer, header…

#15. De naam in de WordPress-core en in plugins wijzigen

Als je Yoast SEO of een vergelijkbare plugin voor semantische markup gebruikt, vergeet dan niet de nieuwe merknaam in te vullen:

Vergeet ook niet deze te wijzigen in de WordPress-core, via Instellingen / Algemeen:

Als je dit niet doet, verschijnt de oude merknaam in Google-snippets of wanneer een URL wordt gedeeld op sociale media, WhatsApp of Telegram.

Dat is belangrijk.

Zodra je dat hebt gedaan, zijn we bijna klaar met de migratie zelf.

#16. 301-redirect

De laatste stap van de migratie.

En de enige die op de oude website wordt uitgevoerd, niet op de nieuwe.

Het doel is het al uitgevoerde SEO-werk te behouden door Google te vertellen welke nieuwe URL’s overeenkomen met de URL’s van de oude website.

Zo begrijpt Google de migratie en blijven de oude posities voor de nieuwe website meestal behouden.

Bovendien worden gebruikers die op een van de in de cache opgeslagen oude URL’s klikken naar de nieuwe website doorgestuurd terwijl Google de resultaten in de SERP’s bijwerkt.

Allemaal heel soepel.

In dit geval gebruiken we de plugin Redirection om het volledige domein te migreren.

Omdat we de hele website exact hebben gekloond zoals die was, zijn de oude URL’s identiek aan de nieuwe, afgezien van de domeinwijziging natuurlijk.

Zo doe je dat:

Stappen na de migratie van de website

Ja, de migratie is voltooid.

Maar nee, we zijn nog niet klaar. Er moeten nog een paar dingen op de website gebeuren.

Bovendien is een website meestal meer dan alleen de website zelf. Vaak zijn er bepaalde gekoppelde diensten. Diensten die moeten worden bijgewerkt zodra de nieuwe website volledig operationeel is.

#1. Bots toestaan de nieuwe website te crawlen

Ga in het WordPress-beheer terug naar waar we eerder waren (Instellingen / Lezen) en vink deze optie uit:

Optioneel: het crawlen door bots op de oude website beperken

Het lijkt misschien logisch om op de oude website het tegenovergestelde te doen: naar dezelfde plek gaan en het vakje aanvinken, omdat we niet langer willen dat de site wordt geïndexeerd, maar juist gedeïndexeerd. Toch doe ik dit om verschillende redenen niet:

1. De 301 zou moeten worden uitgevoerd voordat de content wordt geladen, dus het maakt niet uit wat je hier instelt.
2. Als de content wel zou laden en de 301 daarna zou plaatsvinden, weet ik niet hoe Google dat signaal zou interpreteren: deze pagina niet indexeren? De pagina waarnaar wordt doorgestuurd niet indexeren?

Daarom vink ik het niet aan.

#2. Alle links controleren

Nogmaals crawlen we de hele website, bijvoorbeeld met Screaming Frog.

Het idee is te zoeken naar overgebleven links naar de oude website of naar links die op het nieuwe domein HTTP gebruiken in plaats van HTTPS.

Dit kan gebeuren als er handmatig een absolute URL is ingevoerd.

Daarmee is het werk aan de website zelf afgerond. Nu moeten we de gekoppelde diensten bijwerken.

#3. Wijzigingen in Google Ads

Als je campagnes draait, kun je ze het best zo kort mogelijk pauzeren.

Zodra de nieuwe website operationeel is, heb je dus twee opties:

• Een nieuw account maken voor het nieuwe merk en de volledige configuratie uitvoeren.
• Het bestaande account hergebruiken en aanpassen wat nodig is.

De eerste optie betekent meer werk, maar in ruil daarvoor kun je mogelijk opnieuw aanspraak maken op het advertentietegoed van € 400 dat Google aan nieuwe accounts aanbiedt.

Bij de tweede optie hoef je niet alles opnieuw op te bouwen, maar zijn er nog steeds behoorlijk wat dingen die moeten worden gewijzigd:

• Het nieuwe merk instellen, met naam en logo.
• De teksten wijzigen. Ze passen mogelijk niet binnen de vereiste lengte (dat gebeurde bij mij toen ik van ‘ik’ naar ‘wij’ ging, met langere vervoegingen).
• De URL’s van de landingspagina’s wijzigen zodat ze naar het nieuwe domein verwijzen.
• De relevante advertentie-extensies wijzigen.
• De contactgegevens wijzigen, waar van toepassing.

Volgens mij ben ik niets vergeten.

Zoals je ziet, is het behoorlijk wat werk. Het is geen volledig nieuwe configuratie, maar je bouwt wel ongeveer 60–70% opnieuw op.

Een ander voordeel van hetzelfde account gebruiken is dat je de historische gegevens op één plek houdt, waardoor vergelijken eenvoudiger wordt.

#4. Het domein migreren in Google Search Console

In dit geval moet je Google informeren over de domeinwijziging.

Dit doe je met de tool Adreswijziging en uiteraard heb je toegang nodig tot het GSC-account van het project.

De officiële documentatie legt uit wanneer je een migratie moet aanvragen en wanneer niet, bijvoorbeeld niet bij de overstap van HTTP naar HTTPS of van een domein met www naar hetzelfde domein zonder www.

Eén essentieel punt: vergeet niet de nieuwe sitemap toe te voegen:

#5. De Google Maps-vermelding wijzigen (voorheen Google My Business)

Het lijkt misschien hetzelfde als Google Ads, met dezelfde mogelijkheden om een nieuw account te maken of het oude te hergebruiken.

En ja, dat zou kunnen.

Het probleem is dat je goede reviews met een nieuw account zou verliezen. Bovendien zou het wat vreemd zijn om twee verschillende bedrijven in dezelfde sector op hetzelfde fysieke adres op de kaart te hebben. Als je aan je vermelding hebt gewerkt, raad ik daarom aan de relevante velden bij te werken, waaronder:

• Bedrijfsnaam.
• Beschrijving.
• URL.
• Contactgegevens.

#6. Gegevens in andere bedrijvengidsen bijwerken

Bing Maps, Apple Maps, Foursquare, TripAdvisor, El Tenedor, El Abogado…

Als je aan je online kanaal en SEO hebt gewerkt, heb je je waarschijnlijk naast Google bij bepaalde bedrijvengidsen geregistreerd. Dan moet je de handen uit de mouwen steken en de gegevens bijwerken op alle plaatsen waar de oude website stond vermeld.

Houd bij:

• Waar wijzigingen zijn aangevraagd.
• Waar wijzigingen zijn voltooid.
• Welke nog openstaan.

Zo kun je het werk gemakkelijk voortzetten als je het over meerdere dagen verspreidt.

#7. Andere websites doorsturen

Dit geldt niet voor elke migratie, maar in dit geval wel.

De nieuwe partner van het advocatenkantoor bleek namelijk een eigen website te hebben. Die leverde niet veel leads op, maar stond wel op verschillende plaatsen vermeld, inclusief links.

Wat we dus doen, is het volledige domein doorsturen naar de profiel-URL van de partner op de nieuwe website, waardoor het proces voor elke klant die de site bezoekt vrij soepel verloopt.

Hiermee hebben we het volledige migratieproces afgerond.

Natuurlijk moeten we monitoren en volgen hoe alles zich ontwikkelt:

• Niveaus van leadgeneratie (of het percentage hetzelfde is als voorheen en zo niet, waarom).
• Dalingen in SEO-prestaties.
• Prestaties en problemen in Google Ads.
• Hoe de informatie in de bedrijvengidsen wordt bijgewerkt.

En op basis van wat we zien de relevante wijzigingen doorvoeren.

Maar dat hoort meer bij het normale onderhoud van de website dan bij de migratie zelf.

Wat gebeurt er nu als de dingen niet verlopen zoals verwacht?

De migratie ongedaan maken

Als dat zou gebeuren, zou het in ons project relatief eenvoudig zijn dankzij de back-up van de oude website die we op de server hebben laten staan toen we de site kloonden (stap 2).

We zouden alleen stap 16 van de migratie in omgekeerde richting hoeven uit te voeren.

Daarbij zouden we terugkeren naar de website zoals die nu is. Met andere woorden: contentwijzigingen die vanaf dit moment op de nieuwe website worden aangebracht, zouden niet op de oude verschijnen. Updates evenmin.

Als dit allemaal te veel zou zijn, kan het de moeite waard zijn het proces opnieuw uit te voeren, maar dan terug te schakelen naar het oude domein…

Natuurlijk zouden ook alle stappen uit het onderdeel na de migratie opnieuw moeten worden uitgevoerd.

Dus ook al is het eenvoudig, idealiter werkt de nieuwe website minstens even goed als de oude.

Conclusies

Zoals je ziet, is een standaardmigratie als deze niet bijzonder complex, maar je moet wel weten wat je doet, aandacht hebben voor details en er behoorlijk wat uren werk in steken.

Ik zou zeggen dat iedereen die redelijk vertrouwd is met WordPress dit zonder problemen kan uitvoeren, vooral als diegene er al eens een heeft gedaan.

En als het je eerste keer is, hoef je alleen deze stap-voor-stap handleiding te volgen — daarom heb ik hem gepubliceerd.

Maar als je je om welke reden dan ook niet op je gemak voelt, neem dan contact met me op en we bekijken of het zinvol is dat ik het voor je doe.

Als je het artikel goed vond, kun je over 7 dagen een nieuw artikel in je inbox ontvangen door je hier te abonneren.

Je kunt ook mijn YouTube-kanaal bezoeken, waar ik content en tutorials upload over digitaal ondernemen in al zijn vormen, al is het schema daar niet langer wekelijks en varieert het wat.

Waar dan ook, tot ziens.