Analysera länkar vid webbplatsförändringar i samband med en migration
Bytte plattform, sammanslagning av en undermapp eller byte av domän ändrar vilka URL:er som samlar länkar. Fånga ankarlänkar innan flytten, och jämför sedan efter att indexet har hängit med.
Anchor Social forskarlag ·
Ordning betyder något
Ta ögonblicksbilden innan lanseringsdagen. När gamla URL:er börjar omdirigera blir det svårare att rekonstruera vilken länk som pekade var. Vårt index uppdateras ungefär en gång i månaden, så räkna med att bilden efter flytten syns ett till två cykler senare. Sjastegs-runboken ger metoden för att hämta och dela upp i bucketar, och du behöver båda ändarna av flytten i filen.
Före flytten
Hämta anchors och toppages för den gamla domänen och spara båda filerna med datum
Lista de 50 sidorna som drar till sig flest länkar; dessa behöver omdirigeringar sida-till-sida
Markera ankarbucketarna en gång, med samma regler som du kommer att använda efteråt
Exportera Search Consoles länkrapport för samma dag som en andra åsikt
Bestäm den kanoniska värzvärden och behåll den konsekvent i sitemap och hreflang
Notera varje URL-mönster du tar bort, till exempel en /us-undermapp
Spara Googles uppdateringskalender för månaden, till exempel kärnuppdateringen och spam-uppdateringen i mars 2024, så att en senare rangordningsförändring inte bara läggs på flytten
Bygg omdirigeringskartan innan lansering
Omdirigeringskartan är den del av en flytt som folk underskattar. Destinationerna är viktigast. Innan du analyserar länkar och webbplatsdata efter en flytt behöver de gamla URL:erna en tydlig destination, eftersom det är de adresser dina länkar redan pekar på.
Sida-till-sida slår en dump till startsidan
Att skicka hundratals orelaterade gamla URL:er till startsidan säger väldigt lite för sökmotorer och besökare. Relevans är testet. mappa varje högkvalitativ gammal URL till dess närmaste nya sida, och skicka resten till en sektion som fortfarande matchar deras ämne.
Exportera de gamla URL:erna med deras statuskoder först. Spara den filen. Den filen är checklistan, och den visar vilka sidor som tjänade länkar.
Där en sida inte har en nära matchning, ange det i kartan och skicka den till närmaste sektion, med en anteckning. Tomma celler döljer val. En tom cell i tabellen är ett beslut som ingen fattade.
Platta ut kedjor innan lansering
En omdirigering som passerar genom två tidigare regler innan den når den nya sidan lägger till fördröjning och risk. Kedjor är lätta att skapa när en andra migration ligger ovanpå den första, så granska kartan innan varje byte snarare än att anta att den fortfarande är ren. Varje extra hopp kostar. Begär varje gammal URL en gång efter bytet och bekräfta att den svarar med ett enda hopp.
Fixa det tidigt. Fixa kedjor i kartan själv, inte en och en efter lansering, så att listan förblir kort.
Behåll sökvägarna som fortfarande fungerar
Att ändra URL-strukturen i en omdesign är den mest undvikbara förlusten. Varje ändring av en sökväg är också en ändring av varje länk som pekar på den, och de länkarna ligger utanför din kontroll. Behåll det som fungerar. Om en sökväg fortfarande fungerar, behåll den, och ändra bara det som flytten tvingar dig att ändra.
Färre omdirigeringar, färre fel. Varje sökväg du behåller är en länk som aldrig behövde en omdirigering alls.
En behållen sökväg betyder att de gamla ankar-raderna fortsätter att peka någonstans användbart, vilket är en sak mindre att bygga om i kalkylarket. Mindre ombyggnad senare.
Vad du kan förvänta dig efteråt
De gör tunga lyftet, och en 301 från gammal till ny URL låter de gamla länkarna fortsätta att fungera. Att behålla en omdirigering per gammal URL, utan en kedja emellan, är det enklaste sättet att behålla värdet av varje länk intakt. Omdirigeringar. Kedjor med tre eller fyra hopp långsammare crawlers och är bäst om de plattas ut.
Ankertexten ändras inte när en URL flyttas, eftersom texten finns på den länkande sidan. Vad som ändras är destinationsantalet: din topp-sidor-tabell kommer att visa den gamla värzvärden som bleknar och den nya som stiger över några månatliga uppdateringar. Destinationerna flyttas långsamt.
En vanlig överraskning är att ta bort den gamla plattformen för tidigt. Gör inte det. Squarespace, Wix och liknande värzvärden håller ofta omdirigeringsreglerna, så att avsluta planen kan ta bort dem, och länkarna pekar då på en blindgång tills du bygger om reglerna någon annanstans.
Hreflang och kanoniska länkar förtjänar också en titt. Felmatchningar är vanliga. Efter en CRA till Next.js-migration slutar sidor till exempel ofta med kanoniska taggar som inte stämmer överens med deras hreflang-set, och länkar delas över två versioner av en sida.
Om siffrorna inte stämmer efter flytten, kontrollera felsökningstabellen innan du antar att länkar har gått förlorade. En månatlig uppdatering i sig förklarar många luckor. Luckor är ofta tidsfrågor.
Räkna med den första rena jämförelsen ungefär två månatliga uppdateringar efter lansering, och skriv ner datumet för varje uppdatering i ditt kalkylark så att en platt månad inte misstas för en fastnat en. Ge det tid. Ahrefs eller Semrush kan fylla luckan med fräschare crawls om du behöver en interimsläsning.
Flytttyper och vad du ska vara uppmärksam på
Flytt
Huvudrisk
Kontrollera med
Bytte plattform, samma domän
Ändrade URL-mönster, förlorade omdirigeringar
toppages före och efter, Search Console-coverage
Ny domän
Länkar stannar på den gamla värzvärden i månader
anchors på båda domänerna, månatligen
Sammanslagning av en blog i huvudsidan
Två profiler kollapsar till en
Ankarandelar före och efter, per länkande domän
Att ta bort en /us-undermapp
Länkar till borttagna sökvägar 404
toppages-lista över undermappens URL:er
Ta ögonblicksbild av toppsidorna innan bytet
Använd toppages för att se vilka URL:er som samlar länkar. Två krediter.
Var uppmärksam på vad som flyttas utan ett lanseringsmeddelande
En lanseringsdag har en checklista, men flera problem kommer senare och tyst. De dyker upp i raderna och i indexet, långt efter att teamet har flyttat vidare till annat arbete. De är lätta att missa.
Noindex som följer med en staging-build
En staging-kopia som hölls borta från sökningen kan bära sina inställningar till den live-sidan. Kontrollera robots meta-taggar och eventuella noindex-header på den första crawlen, och provsidor från varje sektion snarare än bara startsidan. Provsidorna varje sektion.
Mallar går sönder först. Om en hel sektion försvinner från indexet efter lansering, titta på dess mall innan du tittar på dess innehåll.
Skärmdumpar hjälper också. Spara en kopia av robots-inställningarna från staging-builden också. När något försvinner ur indexet tar det minuter att jämföra de två uppsättningarna av inställningar snarare än en eftermiddag.
Fragment-länkar som indexeras
Hopp-länkar som en innehållsförteckningsankare kan visas som separata URL:er i sökresultat. Sökmotorer vecklar vanligtvis ut dessa till huvudsidan, men när de inte gör det kan samma innehåll visas under flera adresser. De delar bort signaler från huvudsidan, och de kan se ut som dubbletter i en coverage-rapport. Hash-URL:er multipliceras tyst.
En version, en adress. En kanonisk tagg som pekar på en adress medan sitemap listar en annan skickar blandade signaler, och rapporten kommer att visa felmatchningen. Sätt en kanonisk version av varje sida och bekräfta att sitemap listar samma version.
Kontrollera coverage-rapporten efter lansering för URL:er med en hash i dem, eftersom det är de som multipliceras tyst. Hashes är skyldiga.
En subdomän som blir huvuddomänen
Att flytta en webbplats från en staging-subdomän till huvuddomänen medför egna dubbletter, eftersom båda versionerna kan förbli tillgängliga en stund. Bestäm vilken värzvärden som är kanonisk innan lansering. Välj värzvärden tidigt.
En värzvärden, överallt. När en värzvärden ändras på en plats och inte på en annan kan den äldre versionen fortsätta att samla länkar i månader utan att någon märker det. Behåll då sitemap, de kanoniska taggarna och eventuella hreflang-set som pekar mot den värzvärden.
Do-follow-länkar som verkar försvinna
Efter en omdesign kan do-follow-raderna i ett verktyg falla kraftigt, och den första gissningen är att länkarna är borta. Jämför de gamla toppsidorna med de nya innan du accepterar den gissningen, kontrollera sedan om varje gammal adress nu omdirigerar korrekt. Kontrollera innan du panikar.
Fixa den först. En länk som fortfarande finns på den länkande sidan men pekar mot en död adress är fallet att fixa först.
Sätt datumet tidigt. Ge teamet ett fast datum för jämförelsen, så att ingen kör om hämtningen varje dag och läser brus som nyheter.
Bekräfta en förlorad länk i fyra flyttar
Kör dessa i ordning, och behåll filen från det första steget för det sista.
1
Spara de gamla toppsidorna
Hämta topppages för den gamla domänen innan lansering och behåll filen med dess datum.
2
Testa de gamla adresserna
Begär varje högkvalitativ gammal URL och bekräfta att den svarar med en omdirigering till sin nya sida.
3
Jämför efter en uppdatering
Hämta anchors och toppsidor för den nya domänen efter nästa månatliga uppdatering, och jämför per länkande domän.
4
Fråga bara de största länkarna
För länkar som fortfarande pekar mot en gammal adress, kontakta de största länkande webbplatserna och be dem uppdatera URL:en.
Att arbeta med en utvecklare genom flytten
Det mesta av omdirigeringsarbetet landar på en utvecklare, och övervakningen landar på den som läser kalkylarket. Att skriva ner spliten som en kort tabell, med ett namn i varje cell, är ofta tillräckligt för att stoppa två personer från att anta samma uppgift. Dela upp de rollerna på papperet innan lansering, så att ingen antar att den andra håller koll. Roller behöver namn.
Ge utvecklaren en karta, inte en uppgiftslista
En uppgiftslista säger en utvecklare vad som ska göras, medan en karta visar vilken gammal adress som går var. Skicka tabellen sida-till-sida med statuskoderna och anledningen till varje rad, så att kantfall får ett beslut snarare än en gissning. Beslut slår gissningar.
Testplaner kommer först. Be om en kort testplan som börjar med de gamla adresserna från toppsidorna-filen.
Kom överens om vem som läser den månatliga filen
Den första rena jämförelsen kommer ungefär två uppdateringar efter lansering, och filen kommer att behöva en läsare. Den första läsningen efter lansering är vanligtvis brusig, och en läsare som vet det undviker att reagera på en enskild onormal månad. Namnge den personen, dagen de öppnar den, och kalkylarket där resultatet går. Någon måste äga det.
Datum avgör frågan. Att skriva ner uppdateringsdatumet bredvid varje fil förvandlar en oro över ett fastnat index till en vanlig fakta om kalendern. En platt månad är lätt att läsa fel som en fastnat om någon inte skriver ner uppdateringsdatumen.
Be den personen att skriva en rad per uppdatering, även när inget förändrades, så att filen behåller en kontinuerlig rekord. En rad varje gång.
Planera rullbacken innan lansering
Om den nya värzvärden bryter en kritisk sökväg behöver teamet ett sätt tillbaka som har testats i förväg. Skriv ner stegen, inklusive vem som kan vända strömbrytaren och hur omdirigeringarna beter sig medan det ångas. Öva in det innan lansering.
Skriv ner rullbacken. En rullback som bara finns i en persons huvud är inte en plan.
