Checklista för sidmigrering: från T-4 veckor till dag 45
Domänbyte, ny plattform, flytt av värd eller ett nytt URL-schema: länkarna som pekar mot dig bryr sig inte om vilket. Denna lista visar vad du ska fånga innan lansering och vad du ska kontrollera efteråt.
ArchiLinks forskningsgrupp ·
Vår position
De flesta migreringsförluster beror på missade omdirigeringar, inte på omdirigerings typ
Team diskuterar i timmar om 301 jämfört med 302 och skickar sedan ut 3 000 URL:er med externa länkar som returnerar 404. Hitta alla backlinks till en webbplats innan du bestämmer dig för något annat, eftersom listan visar var risken finns.
- Hämta länkade sidor 4 veckor i förväg, inte natten innan.
- Varje URL med en extern länk behöver en omdirigering 301 till en relevant sida.
- Behåll omdirigeringar aktiva i minst ett år, eftersom gamla länkar ofta lever längre än sidorna de en gång pekade på.
Tidslinjen
T-4 veckor: inventering
Crawl:a den gamla webbplatsen, exportera prestandarapporten från Search Console och kör toppages samt refdomains för den gamla värden. Spara de tre filerna tillsammans med datumet.
T-3 veckor: kartläggning
Bygg omdirigeringskartan från länkade sidor först, från trafik andra, från crawlningen sist. Recept för omdirigeringskarta visar rangordningsskriptet.
T-2 veckor: testning på staging
Kör varje gammal URL mot staging och kontrollera ett steg, status 301 och 200 i slutet. Låt byggprocessen misslyckas vid en kedja eller en loop.
T-0: lansering
Skicka ut omdirigeringarna, den nya sitemapen, de uppdaterade canonical-taggar och de interna länkarna i en enda release. Skicka in den nya sitemapen i Search Console. För ett domänbyte, använd verktyget Adressbyte.
T+1 vecka: loggar och täckning
Kontrollera serverloggar för Googlebot-hittar på gamla URL:er, sedan rapporten Sidor för spikar i 404 eller mjuk 404. Fixa kartan; vänta inte.
T+30 till 45 dagar: länkskillnad
Efter den månatliga uppdateringen, hämta refdomains för den nya värden och jämför den med den gamla filen. Skillnader större än några procent förtjänar en granskning.
Vad som ändras med flytttypen
| Flytt | Omdirigeringar | Extra kontroller | Fokus på länkdatal |
|---|---|---|---|
| Ny domän | Omdirigering 301 på hela värden, på sökvägsnivå där sökvägar ändras | Verktyget Adressbyte, gammal domän behållen i minst 12 månader | Länkskapande domäner som flyttar till den nya värden över tid |
| HTTP till HTTPS eller www-ändring | Omdirigering 301 på värdsnivå | Canonical, HSTS, blandat innehåll | Få skillnader; bekräfta att båda värdarna löser till en |
| Ny plattform, samma domän | Karta på sökvägsnivå | Paginering, parametrar, efterföljande snedstreck | Topp länkade sidor som har ändrat sökväg |
| Deldomän till underkatalog (eller tillbaka) | Karta på sökvägsnivå, regler på värdsnivå | Cookies, robots.txt per värd, analys | Om länkar pekar på den gamla värden eller den nya |
| Sammanfogning av två webbplatser | Många-till-en-karta | Duplicerat innehåll, canonical-val | Överlappning av länkande domäner via intersect |
Checklistan för lanseringsdagen
- Gamla URL:er returnerar 301 i ett enda steg, testade av ett skript snarare än för hand.
- Den nya värden returnerar 200 med en självrefererande canonical på varje mall.
- robots.txt på den nya värden har inte staging-regler. En kvarvarande Disallow: / är den klassiska lanseringsdagsolyckan.
- XML-sitemapen listar endast 200, indexerbart, canonical-URL:er.
- Interna länkar, navigering och strukturerad data pekar på nya URL:er, inte på omdirigerade.
- Analytics- och Search Console-egenskaper finns för den nya värden innan bytet.
- Baslinje JSON-filerna är commitade, med datumet i varje filnamn.
Vårt länkgraf byggs om ungefär en gång i månaden. En länk skapad under veckan av din lansering kanske inte visas på dag 30-hämtningen. Använd Search Consoles rapport Länkar för den sista milen, och bedöm skillnaden från den andra uppdateringen. Samma data matar in granskningen intern vs extern equity efter lansering, och hreflang regionala domäner täcker fallet med flera länder.
En 301 som slutar i en 404 behåller ingenting
Vissa team skickar varje gammal URL till den nya hemorten och låter destinationssidor gå ur bruk senare. Omdirigeringen i sig fungerar. Det är därför vanan är riskfylld, eftersom varje steg ser rent ut i en logg medan sidan i slutet svarar med en 404.
Säg att du flyttar en butik till en ny domän och behåller bara de produkter som fortfarande säljs. Kategorisidorna som höll de flesta av de externa länkarna hoppar nu till inget användbart. Räkna URL:erna med externa länkar innan du pensionerar något. Gör det till det första steget. En sida med länkande domäner behöver en aktiv målplats på samma ämne, inte en axelhöjning.
Håll regeln kort: ett steg, sedan en slutlig 200. Allt annat är ett läckage du valt.
Vad en omdirigering 301 till en aktiv sida skyddar
Värdet för en länk sitter på URL:en den pekar på. En omdirigering bär det värdet endast om adressen den landar på svarar och fortfarande matchar ämnet. En produkt som flyttats till samma produkt i den nya katalogen klarar det testet, medan en produkt som skickas till startsidan vanligtvis inte gör det, även när det var sidan alla länkade till.
Kontrollera den slutliga statusen efter varje malländring. En omdirigering som fungerade vid lansering kan sluta i en 404 efter en senare release, när någon tar bort en kategori under en menyuppdatering.
När en 410 är det ärliga svaret
Vissa gamla URL:er hade inga länkar, inga besök och ingen riktig ersättning. För dem är en tydlig 404 eller en 410 mer ärlig än en omdirigering till en sida som inte svarar på frågan den gamla gjorde. En omdirigering till en relaterad sida behandlas ofta som en mjuk 404, så den räddar ingenting.
Skriv ner beslutet för varje grupp av URL:er, med anledningen bredvid den. En mapp med pensionerade handledningar får ett annat svar från en mapp med sidor med åttio länkande domäner, och du kommer vilja förklara den skillnaden för en kollega om sex månader.
Att kontrollera det sista steget, inte bara det första
De flesta omdirigerings tester stannar vid det första svaret, vilket är fel ställe att stanna. Följ kedjan till dess slut, registrera sedan antalet steg och den slutliga statusen bredvid den gamla URL:en. En kedja på två steg är inte trasig, men den lägger till fördröjning och en plats mer där en regel kan misslyckas.
Om ett skript är out of reach, gör ett kalkylblad och några curl-anrop jobbet. Sidan för API-skript har en version du kan schemalägga.
Sitemapar och manuella begäranden efter lansering
Behåll den gamla sitemapen tillgänglig i några veckor efter flytten. Crawlers som besöker den gamla värden kan fortfarande hitta dessa adresser i en lista, vilket påskyndar deras första pass genom omdirigeringarna.
Manuella begäranden är ett annat verktyg. Använd dem för de få sidor som betyder mest, inte för hundratals URL:er som skickas in en efter en. En begärd sida utan interna länkar och ett tunt innehåll tenderar att falla ut igen, så begäran är bara lika bra som sidan bakom den.
Att vänta är en giltig plan. Ge crawlningen tid, bedöm den sedan på data.
Att behålla den gamla sitemapen listad en stund
Lämna den gamla sitemapen i Search Console tills de gamla URL:erna slutar visas i crawlstatistiken. Ta sedan bort den medvetet och notera datumet i migreringsloggen.
Ta inte bort den på lanseringsdagen bara för att göra egenskapen snygg. Tidig borttagning döljer den enda listan som namnger varje gammal URL du fortfarande behöver spåra.
Att begära indexering för sidorna som bär länkar
Välj de tjugo nya URL:erna med flest externa länkar, med hjälp av samma join du byggde för omdirigeringskartan, och begär dem för hand. Ansträngningen följer sedan risken istället för webbplatsens storlek.
Om en begärd sida fortfarande saknas efter några veckor, titta på sidan innan du ber igen. Kontrollera dess interna länkar, dess canonical och dess innehåll. En femte begäran ändrar ingenting.
Hur långt innan flytten kan bedömas
Bedöm flytten från den andra länkhämtningen, inte den första. Vårt index uppdateras ungefär en gång i månaden, så en hämtning på dag tre visar mestadels förra månadens bild. Kör den andra hämtningen efter uppdateringen, och använd den för att hitta alla backlinks till en webbplats på den nya värden.
Rapporten Sidor och länkdatan svarar på olika frågor. Läs dem sida vid sida, inte som tävlande domar om samma flytt.
Fem kontroller innan staging-webbplatsen går live
Håll staging utanför indexet
Sätt ett lösenord eller en tillåten lista framför staging. En robots.txt-regel i sig hindrar inte sökmotorer från att indexera URL:er de redan känner till från länkar.
Kontrollera noindex- och canonical-inställningar
Öppna mallen och CMS-inställningarna, och leta efter en noindex-flagga eller en canonical som namnger en annan URL. I WordPress är inställningen för sökbarhet den som folk glömmer efter att ha kopierat en webbplats från staging.
Ersätt robots-filen för staging
Hämta den live robots.txt när bytet är klart, och jämför den med filen du menade att skicka. Staging-regler som når produktion kan hålla crawlers borta från hela värden.
Kör stegtestet på den live värden
Staging bevisar att kartan fungerar på en kopia. Kör ett-steg-testet igen på den verkliga domänen efter DNS-ändringar, eftersom en CDN-cache eller en värdregel kan bete sig annorlunda där.
Behåll den gamla värden som svarar
Lämna den gamla domänen som serverar omdirigeringar så länge dess URL:er fortfarande får länkar eller besök. Sätt förnyelsedatumet i en kalender innan någon glömmer att domänen finns.
Att bevaka webbplatsen efter lansering, inte bara innan den
En för-lanseringsrevision registrerar vad som var sant på dagen den kördes. De flesta lanseringsskador visas senare, efter en plugin-uppdatering, en CDN-regeländring eller en mall som rör en inställning som ingen granskade.
Behandla efter-lanseringsbevakningen som en uppsättning små skillnader mot en sparad baslinje. Ingen dashboard behövs. Ett schema och en mapp med daterade filer räcker.
Vad en veckovis bevakning bör jämföra
Välj de kontroller som skulle skada mest om de ändrades, och kör dem samma dag varje vecka.
- Statuskod och slut-URL för de 50 främsta länkade gamla URL:erna
- robots.txt och robots meta-taggen på de huvudsakliga mallarna
- Antal live 200 URL:er mot antalet i den nya sitemapen
- Canonical-taggar på startsidan, en kategori och en artikel
Varför en engångsrevision missar långsam drift
Inställningar drifter efter lansering. En testflagga som lämnas på, en plugin som skriver om permalänkar, eller en omdirigering som lagts till för att fixa en sida kan var och en ångra en del av planen. En revision tagen på lanseringsdagen kan inte se någon av dem.
En schemalagd diff kan det. Behåll baslinjefilerna i versionskontroll och jämför varje veckas utdata mot dem, så att en oväntad förändring blir synlig dagen den inträffar.
Deldomäner, borttagningar och hela webbplatsens domänbyten
Vissa team flyttar en sektion till en deldomän och indexerar bara dess populära sidor. Det kan fungera. Kostnaden är att länkar riktade mot de tystare sidorna nu landar på en värd med mindre historik, så räkna dem innan du klipper något.
Borttagningbegäranden är smalare än de låter. Search Console applicerar en borttagning på egenskapen där du lämnar in den, så en begäran gjord på en deldomän verkar inte på huvuddomänen. Kontrollera egenskapen först. Skicka sedan in, och behåll båda verifierade.
Att indexera bara de populära sidorna på en deldomän
Börja med länkarna per URL i den sektionen. Sidor som bär externa länkar men lite trafik är de första en regel för bara populära sidor skulle dölja. Håll dem crawlbara, eller omdirigera var och en till dess närmaste populära sida och skriv anledningen bredvid regeln.
Var huvudwebbplatsen länkar till deldomänen avgör hur lätt dess sidor hittas. Lista dessa länkar innan du väljer vilka sidor som ska döljas, eftersom en sida som huvudwebbplatsen aldrig länkar till är svår att nå på alla sätt.
En hel webbplatsens domänbyte, sida för sida
En regel på värdsnivå hanterar roten, men ett domänbyte behöver också en karta på sökvägsnivå. När den första delen av URL:en ändras och slaget förblir detsamma, täcker en värdswap de flesta sidorna, och undantagen behöver sina egna rader.
Bygg listan från de länkade sidorna först, matcha sedan varje gammal sökväg till dess nya. Recept för omdirigeringskarta visar hur man rangordnar den listan efter länkar.
