Links analyseren bij websitewijzigingen rondom een migratie

Bouw de redirect-map vóór de start

De redirect-map is het onderdeel van een verhuizing dat mensen onderschatten. Bestemmingen zijn het belangrijkst. Voordat je linkswebsitegegevens na een verhuizing analyseert, moeten de oude URL's een duidelijke bestemming hebben, omdat dat de adressen zijn waar je links momenteel naar wijzen.

Eén-op-één is beter dan een homepage-dump

Honderden ongerelateerde oude URL's naar de homepage sturen vertelt zoekmachines en bezoekers weinig. Relevantie is de test. Koppel elke hoogwaardige oude URL aan de meest vergelijkbare nieuwe pagina en stuur de rest naar een sectie die nog steeds bij het onderwerp past.

Exporteer eerst de oude URL's met hun statuscodes. Bewaar dat bestand veilig. Dat bestand is de controlelijst en toont welke pagina's de links hebben verdiend.

Waar een pagina geen goede match heeft, vermeld dit dan in de map en stuur het naar de dichtstbijzijnde sectie, met een noot. Lege cellen verbergen keuzes. Een lege cel in de tabel is een beslissing die niemand heeft genomen.

Vlak ketens af vóór de start

Een redirect die door twee eerdere regels gaat voordat hij de nieuwe pagina bereikt, voegt vertraging en risico toe. Ketens zijn eenvoudig te creëren wanneer een tweede migratie op de eerste zit, dus controleer de map voor elke switch in plaats van aan te nemen dat deze nog steeds schoon is. Elke extra stap kost. Vraag elke oude URL één keer op na de switch en bevestig dat deze met één stap antwoordt.

Los het vroeg op. Los ketens op in de map zelf, niet één voor één na de start, zodat de lijst kort blijft.

Behoud de paden die nog steeds werken

De URL-structuur wijzigen tijdens een redesign is het meest voorkomende vermijdbare verlies. Elke wijziging aan een pad is ook een wijziging aan elke link die er naar wijst, en die links liggen buiten jouw controle. Behoud wat werkt. Als een pad nog steeds werkt, behoud het dan en verander alleen wat de verhuizing je dwingt te veranderen.

Minder redirects, minder fouten. Elk pad dat je behoudt is een link die helemaal geen redirect nodig had.

Een behouden pad betekent dat de oude anchor-rijen nog steeds naar een nuttige locatie wijzen, wat één ding minder is om in het spreadsheet te herbouwen. Minder herbouwen later.

Wat je daarna kunt verwachten

Zij doen het zware werk, en een 301 van oude naar nieuwe URL laat de oude links doorwerken. Het behouden van één redirect per oude URL, zonder keten ertussen, is de eenvoudigste manier om de waarde van elke link intact te houden. Redirects. Ketens van drie of vier stappen vertragen crawlers en zijn het beste vlak te trekken.

Anchor text verandert niet wanneer een URL verhuist, omdat de tekst op de linkende pagina staat. Wat verandert, is het aantal bestemmingen: je toppages-tabel zal tonen hoe de oude host vervaagt en de nieuwe opkomt over een paar maandelijkse verversingen. Bestemmingen verschuiven langzaam.

Een veelvoorkomende verrassing is het te vroeg verwijderen van het oude platform. Doe dat niet. Squarespace, Wix en vergelijkbare hosts houden vaak de redirectregels vast, dus het opzeggen van het abonnement kan deze verwijderen, en de links wijzen dan naar een dode eindbaan totdat je de regels elders herbouwt.

Hreflang en canonicals verdienen ook aandacht. Mismatchen zijn veelvoorkomend. Na een migratie van CRA naar Next.js hebben sites bijvoorbeeld vaak canonical-tags die niet overeenkomen met hun hreflang-sets, en worden links verdeeld over twee versies van een pagina.

Als de cijfers na de verhuizing niet overeenkomen, controleer dan de troubleshooting-tabel voordat je aannemt dat links verloren zijn gegaan. Een maandelijkse verversing alleen al verklaart veel leemtes. Leemtes zijn vaak tijdsgerelateerd.

Verwacht de eerste schone vergelijking ongeveer twee maandelijkse verversingen na de start, en noteer de datum van elke verversing in je spreadsheet zodat een vlakke maand niet wordt verward met een vastgelopen maand. Geef het tijd. Ahrefs of Semrush kunnen de leemte vullen met frissere crawls als je een tussentijdse read nodig hebt.

Houd in de gaten wat verhuist zonder een startkennisgeving

Een startdag heeft een controlelijst, maar verschillende problemen komen later en stil binnen. Ze verschijnen in de rijen en in de index, lang nadat het team zich naar ander werk heeft verplaatst. Ze zijn makkelijk over het hoofd te zien.

Noindex dat meereist met een staging-build

Een staging-kopie die buiten de zoekmachine is gehouden, kan zijn instellingen naar de live site meenemen. Controleer de robots-meta-tags en elke noindex-header bij de eerste crawl, en steekproefsgewijs pagina's uit elke sectie in plaats van alleen de homepage. Steekproef uit elke sectie.

Sjablonen breken eerst. Als een hele sectie na de start uit de index verdwijnt, kijk dan naar het sjabloon voordat je naar de inhoud kijkt.

Screenshots helpen ook. Bewaar een kopie van de robots-instellingen van de staging-build. Als er iets uit de index verdwijnt, duurt het vergelijken van de twee sets instellingen minuten in plaats van een middag.

Fragment-links die worden geïndexeerd

Springlinks zoals een inhoudsopgave-anker kunnen verschijnen als aparte URL's in zoekresultaten. Zoekmachines vouwen deze meestal samen met de hoofdpagina, maar als dat niet gebeurt, kan dezelfde inhoud onder meerdere adressen verschijnen. Ze splitsen signalen van de hoofdpagina, en ze kunnen eruitzien als dubbele pagina's in een coverage-rapport. Hash-URL's vermenigvuldigen zich stil.

Eén versie, één adres. Een canonical-tag die naar één adres wijst terwijl de sitemap een ander adres vermeldt, stuurt gemengde signalen, en het rapport toont de mismatch. Stel één canonical-versie van elke pagina in en bevestig dat de sitemap dezelfde versie vermeldt.

Controleer het coverage-rapport na de start op URL's met een hash erin, want dat zijn degenen die zich stil vermenigvuldigen. Hashes zijn de boosdoener.

Een subdomein dat het hoofddomein wordt

Een site verplaatsen van een staging-subdomein naar het hoofddomein brengt eigen duplicaten mee, omdat beide versies een tijdje bereikbaar kunnen blijven. Beslis welk host canonical is vóór de start. Kies de host vroeg.

Eén host, overal. Wanneer een host op één plek verandert en op een andere niet, kan de oudere versie maandenlang links blijven verzamelen zonder dat iemand het merkt. Houd dan de sitemap, de canonical-tags en eventuele hreflang-sets die naar die ene host verwijzen.

Do-follow links die lijken te verdwijnen

Na een redesign kunnen de do-follow-rijen in een tool sterk dalen, en de eerste gok is dat de links weg zijn. Vergelijk de oude toppages met de nieuwe voordat je die gok accepteert, controleer dan of elk oud adres nu correct doorverwijst. Controleer voordat je in paniek raakt.

Los dat eerst op. Een link die nog steeds op de linkende pagina bestaat maar naar een dood adres wijst, is het geval dat je eerst moet oplossen.

Stel de datum vroeg in. Geef het team een vaste datum voor de vergelijking, zodat niemand elke dag opnieuw trekt en ruis als nieuws leest.

Werken met een ontwikkelaar tijdens de verhuizing

Het meeste redirect-werk valt op een ontwikkelaar, en de monitoring valt op degene die het spreadsheet leest. Het opsplitsen in een korte tabel, met één naam in elke cel, is vaak genoeg om te voorkomen dat twee mensen aannemen dat ze dezelfde taak hebben. Splits die rollen op papier vóór de start, zodat niemand aanneemt dat de ander aan het kijken is. Rollen hebben namen nodig.

Geef de ontwikkelaar een map, geen takenlijst

Een takenlijst vertelt een ontwikkelaar wat hij moet doen, terwijl een map laat zien welk oud adres waarheen gaat. Stuur de één-op-één-tabel met de statuscodes en de reden voor elke rij, zodat randgevallen een beslissing krijgen in plaats van een gok. Beslissingen zijn beter dan gokken.

Testplannen komen eerst. Vraag om een kort testplan dat begint met de oude adressen uit het toppages-bestand.

Spreek af wie het maandelijkse bestand leest

De eerste schone vergelijking komt ongeveer twee verversingen na de start, en het bestand heeft een lezer nodig. De eerste read na de start is meestal ruisig, en een lezer die dat weet, zal niet reageren op een enkele ongebruikelijke maand. Benoem die persoon, de dag waarop hij het opent, en het spreadsheet waar het resultaat naartoe gaat. Iemand moet er verantwoordelijk voor zijn.

Data leggen de vraag vast. Het noteren van de verversingsdatum naast elk bestand verandert een zorg over een vastgelopen index in een feitelijke mededeling over de kalender. Een vlakke maand is makkelijk verkeerd te interpreteren als een vastgelopen maand, tenzij iemand de verversingsdatums noteert.

Vraag die persoon om één regel per verversing te schrijven, zelfs als er niets is veranderd, zodat het bestand een doorlopende registratie houdt. Eén regel elke keer.

Plan de rollback vóór de start

Als de nieuwe host een kritiek pad breekt, heeft het team een manier terug nodig die van tevoren is getest. Schrijf de stappen op, inclusief wie de schakelaar kan omzetten en hoe de redirects zich gedragen terwijl het wordt ongedaan gemaakt. Oefen het vóór de start.

Schrijf de rollback op. Een rollback die alleen in het hoofd van één persoon bestaat, is geen plan.