Checklist voor site-migratie: van T-4 weken tot dag 45
Domeinwijziging, herplatforming, verhuizing van de host of een nieuw URL-schema: de links die naar jou wijzen, maakt dat niets uit. Deze lijst vertelt je wat je vast moet leggen voor de lancering en wat je daarna opnieuw moet controleren.
ArchiLinks onderzoeksteam ·
Onze positie
De meeste migratieverliezen komen door ontbrekende redirects, niet door het redirect-type
Teams discussiëren urenlang over 301 versus 302 en lanceren vervolgens met 3.000 externe URL's die een 404 retourneren. Vind alle backlinks naar een website voordat je iets anders beslist, omdat de lijst aangeeft waar het risico ligt.
- Verzamel gelinkte pagina's 4 weken van tevoren, niet de nacht ervoor.
- Elke URL met een externe link moet een one-hop 301 hebben naar een relevante pagina.
- Houd redirects minimaal een jaar actief, omdat oude links vaak langer bestaan dan de pagina's waar ze ooit naar wezen.
De tijdlijn
T-4 weken: inventarisatie
Crawl de oude site, exporteer het prestaterapport van Search Console en voer toppages plus refdomains uit voor de oude host. Sla de drie bestanden samen met de datum op.
T-3 weken: mappen
Bouw de redirect-map eerst op basis van gelinkte pagina's, daarna op basis van verkeer, en tot slot op basis van de crawl. Het redirect map recept toont het rangschrijfscript.
T-2 weken: testen op staging
Voer elke oude URL tegen staging en controleer één hop, status 301 en een 200 aan het einde. Laat de build falen bij een ketting of een lus.
T-0: lancering
Lanceer de redirects, de nieuwe sitemap, de bijgewerkte canonical-tags en de interne links in één release. Dien de nieuwe sitemap in bij Search Console. Voor een domeinwijziging gebruik je de tool 'Adreswijziging'.
T+1 week: logs en dekking
Controleer serverlogs op Googlebot-hits op oude URL's, controleer vervolgens het rapport 'Pagina's' op pieken in 404 of soft 404. Herstel de map; wacht niet.
T+30 tot 45 dagen: linkdiff
Na de maandelijkse refresh, verzamel refdomains voor de nieuwe host en vergelijk deze met het oude bestand. Verschillen groter dan een paar procent verdienen een kijkje.
Wat verandert met het type verplaatsing
| Verplaatsing | Redirects | Extra controles | Focus op linkdata |
|---|---|---|---|
| Nieuw domein | Host-wide 301, path-level waar paden veranderen | Tool 'Adreswijziging', oud domein minimaal 12 maanden behouden | Verwijzende domeinen die geleidelijk naar de nieuwe host verhuizen |
| HTTP naar HTTPS of www-wijziging | Host-level 301 | Canonical, HSTS, gemengde inhoud | Weinig verschillen; bevestig dat beide hosts naar één verwijzen |
| Herplatforming, hetzelfde domein | Path-level map | Paginering, parameters, trailing slashes | Top gelinkte pagina's die van pad zijn veranderd |
| Subdomein naar submap (of omgekeerd) | Path-level map, host-level regels | Cookies, robots.txt per host, analytics | Of links naar de oude host of de nieuwe verwijzen |
| Samenvoegen van twee sites | Veel-naar-één map | Dubbele inhoud, canonical-keuzes | Overlap van verwijzende domeinen via intersect |
De checklist voor lanceringdag
- Oude URL's retourneren 301 in één hop, getest door een script in plaats van met de hand.
- De nieuwe host retourneert 200 met een self-referencing canonical op elke template.
- robots.txt op de nieuwe host bevat geen staging-regels. Een achtergebleven Disallow: / is de klassieke fout bij lancering.
- De XML sitemap bevat alleen 200, indexeerbare, canonical URL's.
- Interne links, navigatie en gestructureerde data verwijzen naar nieuwe URL's, niet naar doorgestuurde.
- Analytics- en Search Console-eigenschappen bestaan voor de nieuwe host vóór de switch.
- De baseline JSON-bestanden zijn gecommit, met de datum in elke bestandsnaam.
Onze linkgraph wordt ongeveer één keer per maand herbouwd. Een link die in de week van je lancering is gemaakt, wordt mogelijk niet getoond bij de pull op dag 30. Gebruik het rapport 'Links' van Search Console voor de laatste mijl, en beoordeel de diff vanaf de tweede refresh. Dezelfde data voedt het interne vs externe equity overzicht na lancering, en hreflang regionale domeinen behandelt het multi-country-geval.
Een 301 die eindigt in een 404 houdt niets vast
Sommige teams sturen elke oude URL naar de nieuwe thuisbasis en laten de bestemmingspagina's later verlopen. De redirect zelf werkt. Dat is waarom deze gewoonte risicovol is, omdat elke hop er schoon uitziet in een log terwijl de pagina aan het einde een 404 retourneert.
Stel je verhuist een winkel naar een nieuw domein en behoud alleen de producten die nog verkopen. De categoriepagina's die de meeste externe links bevatten, sturen nu naar niets nuttigs. Tel de extern gelinkte URL's voordat je iets afvoert. Maak het de eerste stap. Een pagina met verwijzende domeinen heeft een live doel op hetzelfde onderwerp nodig, geen gebaar van onverschilligheid.
Houd de regel kort: één hop, dan een definitieve 200. Alles anders is een lek dat je hebt gekozen.
Wat een one-hop 301 naar een live pagina beschermt
De waarde van een link zit op de URL waar hij naar wijst. Een redirect draagt die waarde alleen als het adres waar hij landt antwoordt en nog steeds overeenkomt met het onderwerp. Een product dat naar hetzelfde product in de nieuwe catalogus is verplaatst, slaagt voor deze test, terwijl een product dat naar de homepage wordt gestuurd dat meestal niet doet, zelfs niet als het de pagina was waarnaar iedereen linkte.
Controleer de eindstatus na elke templatewijziging. Een redirect die werkte bij lancering kan eindigen in een 404 na een latere release, wanneer iemand een categorie verwijdert tijdens een menu-opruiming.
Wanneer een 410 het eerlijke antwoord is
Sommige oude URL's hadden geen links, geen bezoeken en geen echte vervanging. Voor die is een duidelijke 404 of een 410 eerlijker dan een redirect naar een pagina die niet antwoordt op de vraag die de oude deed. Een redirect naar een ongerelateerde pagina wordt vaak behandeld als een soft 404, dus hij redt niets.
Schrijf de beslissing voor elke groep URL's op, met de reden ernaast. Een map met afgedankte tutorials krijgt een ander antwoord dan een map met pagina's met tachtig verwijzende domeinen, en je wilt dat verschil over zes maanden aan een collega kunnen uitleggen.
De laatste hop controleren, niet alleen de eerste
De meeste redirecttests stoppen bij de eerste respons, wat de verkeerde plek is om te stoppen. Volg de ketting tot het einde, registreer vervolgens het aantal hops en de eindstatus naast de oude URL. Een ketting van twee hops is niet kapot, maar het voegt vertraging toe en nog een plek waar een regel kan falen.
Als een script buiten bereik is, volstaat een spreadsheet en een paar curl-oproepen. De API-scripts pagina heeft een versie die je kunt plannen.
Sitemaps en handmatige verzoeken na lancering
Houd de oude sitemap een paar weken na de verplaatsing bereikbaar. Crawlers die de oude host opnieuw bezoeken, kunnen die adressen nog steeds in één lijst vinden, wat hun eerste pass door de redirects versnelt.
Handmatige verzoeken zijn een ander hulpmiddel. Gebruik ze voor de paar pagina's die het meest belangrijk zijn, niet voor honderden URL's die één voor één worden ingediend. Een aangevraagde pagina zonder interne links en een dunne body valt vaak weer buiten de index, dus het verzoek is slechts zo goed als de pagina erachter.
Wachten is een geldig plan. Geef de crawl tijd, beoordeel het dan op basis van data.
De oude sitemap een tijdje vermelden
Laat de oude sitemap in Search Console staan totdat de oude URL's niet meer verschijnen in de crawlstats. Verwijder hem dan opzettelijk en noteer de datum in het migratielogboek.
Verwijder hem niet op lanceringdag alleen maar om de eigenschap er netjes uit te laten zien. Vroegtijdige verwijdering verbergt de enige lijst die elke oude URL noemt die je nog moet volgen.
Indexering aanvragen voor de pagina's die links dragen
Kies de twintig nieuwe URL's met de meeste externe links, gebruikmakend van dezelfde join die je hebt gebouwd voor de redirect-map, en vraag die handmatig aan. De inspanning volgt dan het risico in plaats van de grootte van de site.
Als een aangevraagde pagina na een paar weken nog steeds ontbreekt, kijk dan naar de pagina voordat je opnieuw vraagt. Controleer de interne links, de canonical en de inhoud. Een vijfde verandering verandert niets.
Hoelang het wachten duurt voordat de verplaatsing kan worden beoordeeld
Beoordeel de verplaatsing vanaf de tweede linkpull, niet de eerste. Onze index wordt ongeveer één keer per maand ververst, dus een pull op dag drie toont vooral het beeld van vorige maand. Voer de tweede pull uit na de refresh en gebruik die om alle backlinks naar een website op de nieuwe host te vinden.
Het rapport 'Pagina's' en de linkdata beantwoorden verschillende vragen. Lees ze naast elkaar, niet als concurrerende oordelen over dezelfde verplaatsing.
Vijf controles voordat de staging-site live gaat
Houd staging buiten de index
Zet een wachtwoord of een allow-list voor staging. Een robots.txt-regel alleen stopt zoekmachines er niet van om URL's te indexeren die ze al kennen van links.
Controleer noindex- en canonical-instellingen
Open de template en de CMS-instellingen en zoek naar een noindex-vlag of een canonical die naar een andere URL verwijst. In WordPress is de zoekzichtbaarheid-instelling die mensen vergeten na het kopiëren van een site van staging.
Vervang het staging robots-bestand
Haal de live robots.txt op zodra de switch is gedaan en vergelijk deze met het bestand dat je had willen lanceren. Staging-regels die productie bereiken, kunnen crawlers van de hele host uitsluiten.
Voer de hop-test uit op de live host
Staging bewijst dat de map werkt op een kopie. Voer de one-hop-test opnieuw uit op het echte domein na DNS-wijzigingen, omdat een CDN-cache of een host-regel daar anders kan gedragen.
Houd de oude host antwoordend
Laat het oude domein redirects serveren zolang zijn URL's nog links of bezoeken krijgen. Zet de vernieuwingsdatum in een agenda voordat iemand vergeet dat het domein bestaat.
De site na lancering bewaken, niet alleen ervoor
Een audit voor lancering registreert wat waar was op de dag dat deze werd uitgevoerd. De meeste schade bij lancering toont zich later, na een plugin-update, een CDN-regelwijziging of een template die een instelling aanraakt die niemand heeft gecontroleerd.
Behandel de post-lancering watch als een reeks kleine diffs tegen een opgeslagen baseline. Geen dashboard nodig. Een schema en een map met datum-bestanden volstaan.
Wat een wekelijkse watch moet vergelijken
Kies de controles die het meest pijn zouden doen als ze veranderen, en voer ze elke week op dezelfde dag uit.
- Statuscode en eind-URL voor de top 50 gelinkte oude URL's
- robots.txt en de robots meta-tag op de hoofdtemplates
- Aantal live 200 URL's tegenover het aantal in de nieuwe sitemap
- Canonical-tags op de homepage, één categorie en één artikel
Waarom een eenmalige audit langzame drift mist
Instellingen wijken af na lancering. Een testvlag die aan staat, een plugin die permalinks herschrijft, of een redirect die is toegevoegd om één pagina op te lossen, kan elk een deel van het plan ongedaan maken. Een audit genomen op lanceringdag ziet er geen van.
Een geplande diff wel. Houd de baseline-bestanden in versiebeheer en vergelijk de output van elke week ermee, zodat een onverwachte verandering zichtbaar is op de dag dat deze plaatsvindt.
Subdomeinen, verwijderingen en hele-site domeinwijzigingen
Sommige teams verplaatsen een sectie naar een subdomein en indexeren alleen de populaire pagina's. Dat kan werken. De kosten zijn dat links die naar de rustigere pagina's gingen, nu landen op een host met minder geschiedenis, dus tel ze voordat je iets knipt.
Verwijderingsverzoeken zijn smaller dan ze klinken. Search Console past een verwijdering toe op de eigenschap waar je het indient, dus een verzoek dat op een subdomein wordt gedaan, werkt niet op het hoofddomein. Controleer de eigenschap eerst. Dien het dan in en houd beide geverifieerd.
Alleen de populaire pagina's op een subdomein indexeren
Begin met de links per URL in die sectie. Pagina's die externe links dragen maar weinig verkeer zijn de eerste die een regel 'alleen populaire pagina's' zou verbergen. Houd ze crawlbaar, of redirect elke pagina naar de dichtstbijzijnde populaire pagina en schrijf de reden naast de regel.
Waar de hoofdsite linkt naar het subdomein bepaalt hoe makkelijk de pagina's worden gevonden. Lijst die links op voordat je kiest welke pagina's verborgen blijven, omdat een pagina die de hoofdsite nooit linkt, op beide manieren moeilijk bereikbaar is.
Een hele-site domeinwijziging, pagina per pagina
Een host-level regel behandelt de root, maar een domeinwijziging vereist ook een path-level map. Wanneer het eerste deel van de URL verandert en de slug hetzelfde blijft, dekt een host-swap de meeste pagina's, en de uitzonderingen hebben hun eigen regels nodig.
Bouw de lijst eerst op basis van de gelinkte pagina's, en koppel vervolgens elk oud pad aan het nieuwe. Het redirect map recept toont hoe je die lijst rangschikt op basis van links.
