SEO-checklista för webbplatsmigrering

En webbplatsmigrering är en kontrollerad förändring av en webbplats plattform, domän, protokoll, informationsarkitektur, webbadressstruktur eller renderingssystem. Den är komplett först när användare, sökrobotar och analysverktyg kan nå det avsedda innehållet via stabila rutter och teamet kan bevisa att värdefull synlighet överlevt.

Checklista: SEO för webbplatsmigrering. Tidsram: påbörja 6–12 veckor före lansering för en medelstor webbplats; avsätt de sista 5 arbetsdagarna för ändringsfrysning, lanseringsdagen för bemannad validering och minst 4 veckor för aktiv övervakning. Ägare: en migreringsledare ansvarig för hela releasen, med stöd av namngivna ägare inom teknik, SEO, analys, innehåll och infrastruktur.

Varför denna checklista finns, och varför den körs här

Detta releasekontrollager i SEO-processen förbrukar genomsöknings- och indexbevis från den tekniska baslinjegranskningen , behåll/slå samman/ta bort-beslut från inventering och granskning av innehåll och destinationshierarkin från den topiska kartan och informationsarkitekturen . Dessa resultat måste finnas innan omdirigeringar eller stagingmiljö kan bedömas.

Kör den efter att destinationsstrukturen är godkänd men innan produktionsrutter är låsta. Om den körs tidigare kartlägger teamet omdirigeringar till destinationer som fortfarande kan ändras. Om den körs senare kan routning, mallar, analysverktyg eller lanseringskommunikation redan vara för dyra att korrigera på ett säkert sätt.

Omdirigeringskartan är den enskilt högriskartefakten eftersom den sammanbinder gamla rutter med nya. Varje värdefull gammal webbadress bör gå en-till-en till den närmaste destinationen som bevarar dess syfte. Använd aldrig startsidan som en uppsamlingsplats: det frustrerar besökare och döljer saknade destinationer.

Indata och utdata

Utdata är kontraktet med lanseringsoperationerna. Ett kalkylblad utan ägare, bevis eller acceptansvillkor är ingen överlämning.

Checklistan

Varje punkt anger vad, varför, hur, verktyg och ett observerbart när-är-det-klart-villkor. Byt ut en tröskel endast mot en strängare regel eller en dokumenterad baslinjebaserad sådan.

Fas 1: förmigreringsinventering

1. Bygg den sammanslagna URL-inventeringen. Vad: kombinera varje upptäckbar gammal webbadress från genomsökningar, XML-sajtstrukturer, analysdata, Search Console, bakåtlänksexport, CMS-poster, betalkampanjer och serverloggar. Varför: ingen enskild källa innehåller varje värdefull eller efterfrågad webbadress; en sida som saknas i navigeringen kan fortfarande ha länkar, trafik eller avtalsmässig betydelse. Hur: normalisera protokoll, värd, versaler/gemener, avslutande snedstreck, parametrar och kodade tecken samtidigt som det råa källvärdet behålls. Deduplicera först efter att du registrerat var varje webbadress hittades. Verktyg: genomsökningsverktyg, CMS-export, analysdata, Search Console, bakåtlänksdata och loggar. Klart när: varje källa är daterad, varje rad har en normaliserad webbadress och upptäcktskälla, dubbletter är lösta och källsummor stämmer överens med den slutliga inventeringen.

2. Klassificera dispositionen för varje webbadress. Vad: märk varje webbadress med behåll, flytta, slå samman, ta bort eller undersök. Varför: omdirigeringar kan inte kartläggas korrekt förrän innehållsbeslutet är explicit. Hur: kombinera trafik, konverteringar, bakåtlänkar, indexstatus, innehållskvalitet, affärsbehov och avsikt; dokumentera bevis och godkännande ägare. Verktyg: inventeringsarbetsbok och innehållsgranskning. Klart när: 100 % av omfattade webbadresser har en disposition, en ägare, en destination eller borttagningsorsak och ingen olöst “undersök”-rad återstår vid frysning.

3. Fånga den signerade baslinjen. Vad: bevara före-lansering organiska sessioner, klick, visningar, konverteringar, intäkter, indexerade webbadresser, genomsökningsfel, svarskoder, drifttid och prestanda för prioriterade mallar och kataloger. Varför: utan en daterad jämförelsepunkt ser normal variation och migreringsskada likadana ut. Hur: exportera minst 28 jämförbara dagar, annotera kampanjer och säsongsvariation och identifiera prioriterade webbadresser som kräver daglig granskning. Verktyg: analysdata, Search Console, genomsökningsverktyg, rankningsdata och övervakning. Klart när: baslinjen är skrivskyddad, reproducerbar, segmenterad, tidsstämplad och godkänd av SEO- och analysansvariga.

Fas 2: omdirigeringskartläggning

4. Kartlägg källor en-till-en där det är möjligt. Vad: tilldela varje flyttad eller sammanslagen gammal webbadress till den närmaste nya webbadressen med samma primära avsikt. Varför: en precis destination bevarar kontinuitet för besökaren och ger sökrobotar en sammanhängande ersättningssignal. Hur: jämför ämne, produkt, geografi, språk och uppgift; kartlägg sammanslagningar till den överlevande sidan och dokumentera avsiktliga borttagningar. Kartlägg aldrig omatchade webbadresser till startsidan. Verktyg: omdirigeringskartans arbetsbok, inventering och destinationsgenomsökning. Klart när: varje ändrad källa har exakt ett godkänt utfall, varje destination är relevant och inom omfattning och startsidans uppsamlingskartläggningar är noll.

5. Validera omdirigeringsmekanik före lansering. Vad: testa statuskoder, destinationer, frågebeteende, variant av versaler/gemener, protokoll, underdomäner, avslutande snedstreck, filer och kampanjwebbadresser. Varför: ett korrekt utseende kalkylblad kan fortfarande producera loopar, kedjor, jokertecken som sväljer giltiga sidor eller destinationer som returnerar fel. Hur: generera staging- eller proxyrreglerna, begär varje källa, följ hopp och jämför den slutliga webbadressen med den godkända kartan. Verktyg: automatiserat HTTP-test, genomsökningsverktyg och serverkonfigurationsgranskning. Klart när: 100 % av kartlagda källor når den godkända 200-destinationen i ett permanent omdirigeringshopp; loopar, kedjor, tillfälliga omdirigeringar och feldestinationer är noll.

6. Stäm av kanoniska webbadresser, länkar och sajtstrukturer med omdirigeringar. Vad: se till att den kanoniska webbadressen , interna länkar, hreflang-referenser, strukturerad data, flöden och XML-sajtstrukturer pekar direkt till slutliga webbadresser. Varför: att omdirigera gamla webbadresser medan man fortsätter publicera dem skapar motstridiga migreringssignaler och slösar på robotförfrågningar. Hur: genomsök varje referenskälla och jämför normaliserade mål med omdirigeringskartan. Verktyg: genomsökningsverktyg, renderad HTML, sajtstrukturparser och konfigurationsdiff. Klart när: slutliga sidor självkanoniserar om inte ett godkänt undantag säger annat, interna referenser till omdirigerade webbadresser är noll och nya sajtstrukturer innehåller endast kanoniska 200-webbadresser.

Fas 3: validering av stagingmiljö

7. Testa stagingmiljön utan att göra den offentligt indexerbar. Vad: genomsök hela staging-releasen samtidigt som sökmotorer hindras från att indexera miljön. Varför: teamet behöver bevis på genomsökningsnivå utan att tillåta en dubblettwebbplats i sökresultaten. Hur: använd åtkomstkontroll för externa sökrobotar, kör sedan en autentiserad intern genomsökning med JavaScript-rendering där produktionswebbplatsen är beroende av det. Behandla ett staging-block som tillfällig release-konfiguration, inte något att kopiera blint till produktion. Verktyg: autentiserat genomsökningsverktyg, webbläsare och svarshuvudinspektion. Klart när: den förväntade staging-inventeringen är genomsökbar av testteamet, obehörig offentlig indexering är blockerad och produktionslanseringschecklistan explicit tar bort staging-endast-kontroller.

8. Verifiera mallar och prioriterade användarflöden. Vad: testa representativa sidor från varje mall plus navigering, sökning, formulär, registrering, utcheckning, lokalisering, paginering, filter och felsidor. Varför: en godkänd startsida avslöjar inte en kanonisk bugg på produktsidor eller ett trasigt samtyckestillstånd som undertrycker analysdata. Hur: skapa en enhets-och-mall-matris, testa rena och återkommande sessioner och dokumentera skärmdumpar eller svarsbevis för varje resultat. Verktyg: webbläsare, tillgänglighetskontroll, strukturerad data-validerare, analysfelsökare och transaktionstester. Klart när: varje omfattad mall och primärt användarflöde godkänns på de överenskomna webbläsarna och enheterna, med noll kritiska defekter öppna.

9. Jämför stagingmiljön med de godkända kontrakten. Vad: diffa titlar, beskrivningar, rubriker, kanoniska webbadresser, robots-direktiv, strukturerad data, interna länkar, svarskoder, innehåll och analystaggar mot den gamla webbplatsen och destinationsspecifikationen. Varför: plattformsmigreringar tappar ofta metadata eller ändrar rendering även när den synliga kopian verkar intakt. Hur: genomsök gammal produktion och staging med matchade inställningar, segmentera skillnader per mall och godkänn endast avsedda ändringar. Verktyg: genomsökningsdiff-rapport och källinspektion. Klart när: varje väsentlig skillnad är antingen korrigerad eller listad som en godkänd ändring med ägare och orsak; oavsiktliga noindex, kanoniska, innehålls- och spårningsändringar är noll.

10. Frys releasekandidaten. Vad: frys webbadressinventeringen, omdirigeringskartan, ruttdefinitioner, kanoniska och robots-regler, generering av sajtstruktur, analys- och samtyckeskonfiguration, DNS/CDN-plan och orelaterade produktionsdistributioner. Varför: ett testresultat gäller endast för den testade versionen. Hur: tagga releaseartefakterna, begränsa ändringar till incidentvägen och kräva omtestning av allt som påverkas av en akutredigering. Verktyg: distributionssystem, ändringslogg och godkännandeprotokoll. Klart när: en oföränderlig kandidat är namngiven, åtkomst är begränsad, alla undantag har en ägare och varje efterfrysningsändring har ett testresultat.

Fas 4: lanseringsdagen

11. Kör en ägd runbook. Vad: distribuera routing, applikation, DNS/CDN, analys, sajtstrukturer och övervakning i den godkända ordningen. Varför: parallella osekvenserade ändringar gör fel svåra att isolera och återrullning osäker. Hur: en migreringsledare ropar varje steg, den tilldelade operatören registrerar slutförande och validerare testar bevisen före nästa beroende steg. Verktyg: runbook, distributionsloggar, DNS-kontroller och delad incidentkanal. Klart när: varje rad har en faktisk tid, operatör, resultat och bevislänk, och inget beroende markeras slutfört enbart på muntlig försäkran.

12. Kör lanseringsröktestet. Vad: testa startsidan, robots-filen, sajtstrukturer, minst en webbadress per mall, varje prioriterat användarflöde, analysmottagning och ett stratifierat urval av omdirigeringskällor. Varför: det snabbaste säkra svaret kommer från att upptäcka ett brett fel innan cacheminnen och sökrobotar sprider det. Hur: testa från utanför produktionsnätverket, använd stationär och mobil, verifiera både serverlevererad HTML och renderad utdata och jämför med de frusna förväntningarna. Verktyg: genomsökningsverktyg, webbläsare, HTTP-klient, analys realtidsvy och transaktionsövervakning. Klart när: kritiska sidor returnerar avsedd status och innehåll, prioriterade omdirigeringar når sina exakta destinationer, analyshändelser anländer med korrekta webbadresser och alla lanseringsblockerande kontroller passerar.

13. Skicka in och verifiera upptäcktssignaler. Vad: publicera de slutliga sajtstrukturerna, bekräfta robots- och kanoniskt beteende och begär inspektion för en liten uppsättning prioriterade webbadresser. Varför: rena upptäcktssignaler hjälper sökrobotar att möta destinationsuppsättningen utan att behandla inlämning som en garanti för indexering. Hur: skicka in varje produktionsajtstruktur en gång, inspektera representativa nya webbadresser och registrera Googles rapporterade kanoniska- och indexstatus. Verktyg: Sajtstrukturer och indexering och URL-inspektion . Klart när: sajtstrukturer är nåbara och innehåller den frusna kanoniska inventeringen, representativa inspektioner visar inget produktionsblock eller felaktig kanonisk, och varje varning har en ägare.

Fas 5: övervakning efter lansering

14. Övervaka de första 72 timmarna som ett incidentfönster. Vad: övervaka drifttid, 5xx, 4xx, omdirigeringsfel, latens, genomsökningsvolym, analysmottagning, konverteringar, sajtstrukturbehandling och prioriterade användarflöden kontinuerligt eller med kortast praktiska intervall. Varför: infrastruktur- och routningsdefekter upptäcks snabbt, medan sökprestanda tar längre tid och bör inte vara det enda lanseringslarmet. Hur: jämför med den signerade baslinjen, segmentera per mall och katalog och dirigera larm till en jourhavande ägare. Verktyg: loggar, analysdata, genomsökningsverktyg, Uptime-övervakning och incidentdashboard. Klart när: dashboarden har inget oförklarligt lanseringskritiskt larm, varje incident har en ägare och tidsstämpel och 24-, 48- och 72-timmarsgranskningar är signerade.

15. Fortsätt sök- och indexövervakning efter stabilitet. Vad: spara sidnivåklick, visningar, indexstatus, valda kanoniska, genomsökningsfel, katalogprestanda och konverteringsutfall i minst fyra veckor. Varför: genomsökning, kanoniskt val och indexersättning ligger efter infrastrukturvalidering. Hur: jämför liknande tidsfönster, separera flyttade webbadresser från oförändrade kontroller och undersök kluster istället för att reagera på en dags totalsiffra. Verktyg: Google Search-sidor , Katalogvy , URL-inspektion, analysdata och loggar. Klart när: prioriterade destinationer är upptäckbara och indexerbara, gamla webbadresser leder konsekvent till godkända destinationer, oförklarade förluster har ärenden och ägarskap flyttas till den ordinarie rapporteringsrytmen.

Verktyg i AmICited

AmICited tillhandahåller lanseringsbevis och övervakningsytor; den godkända omdirigeringskartan och distributionsloggarna förblir den operativa källan till sanning.

Beslutsregler

Dessa är release-skyddsräcken, inte universella sökmotortrösklar. Kom överens om dem före lansering och skärp dem där risken kräver det.

Återrullning återställer ett känt fungerande tjänsttillstånd; det återställer inte vanliga sökfluktuationer. Lanseringsmyndigheten tillämpar de överenskomna reglerna och dokumenterar bevisen.

Leverans

Överlämna ett versionshanterat migreringskontrollpaket tillgängligt för teknik och SEO. Använd en arbetsbok eller databas för radnivåposter, en runbook för lanseringsåtgärder och en dashboard för levande mätvärden.

Det måste innehålla den frusna inventeringen och källavstämningen; godkänd omdirigeringskarta med ägare och tester; matchade gamla, staging- och nya genomsökningar; metadata-, kanonisk-, robots-, sajtstruktur-, hreflang-, strukturerad data-, länk- och analysdifferenser; signerad baslinje och prioriterade kohorter; lanseringsrunbook och återställningsprocedur; numeriska återrullningsregler och beslutsägare; samt 24-, 48- och 72-timmarsbevisen med fyra veckors övervakningsägarskap.

Migreringsledaren måste kunna identifiera den exakta releasen, bevisa varje kritiskt test, rekonstruera varje routningsbeslut och tilldela varje undantag. Annars är paketet ofullständigt.

Vad går fel

Omdirigeringskartan använder endast den aktuella sajtstrukturen. Föräldralösa sidor, kampanjwebbadresser, bakåtlänkar och tidigare indexerade rutter försvinner, så varje kalkylbladsrad godkänns medan verkliga förfrågningar misslyckas.

Startsidan blir standarddestinationen. Användare hamnar någonstans irrelevant, robotsignaler blir tvetydiga och saknat innehåll maskeras som implementeringsframsteg.

Omdirigeringar fungerar, men referenser förblir gamla. Navigering, hreflang, kanoniska, strukturerad data och sajtstrukturer fortsätter att skicka sökrobotar genom onödiga hopp och motstridiga destinationer.

Stagingskydd når produktion. En kopierad noindex, autentiseringsregel, robots-blockering eller CDN-policy förstör indexerbarheten . Kräv ett explicit borttagningssteg och externt test.

Teamet validerar endast startsidan. En delad mall kan feltolka tusentals sidor medan startsidan godkänns. Ta stickprov på varje mall och genomsök regler i skala.

Orelaterade releaser skickas tillsammans. När plattform, analys, samtycke, navigering, utcheckning och CDN-ändringar delar ett fönster blir fel svåra att isolera eller återställa.

Sökresultat bedöms för tidigt eller brett. Webbplatssummor döljer trasiga kataloger och en enda volatil dag leder till onödiga korrigeringar. Jämför flyttade kohorter, oförändrade kontroller, kataloger och matchade tidsfönster.

Återrullning debatteras under driftavbrottet. En bra plan anger trösklar, beslutsfattare, återställningstid, kommandon, datakonsekvenser och valideringssekvens före lansering.

Nästa fas

När de första 72 timmarna är stabila är nästa steg kontinuerlig uppdatering och iteration . Det behöver den signerade baslinjen, slutlig URL-kartläggning, lanseringsannoteringar, katalogkohorter, kända undantag, incidenthistorik och namngivna ägare från denna checklista. Utan dessa indata kan en senare trafikförlust inte tillförlitligt separeras i migreringsskada, ordinarie efterfrågeförändring, innehållsförfall eller mätningsfel.

Behåll omdirigeringskartan och migreringsannoteringen permanent. Flytta icke-kritiska resultat till den ordinarie rapporteringsrytmen med allvarlighetsgrad, hypotes, ägare, förfallodatum och verifieringsmetod.

Vanliga frågor

När bör SEO-teamet delta i en webbplatsmigrering?

Innan rutter, mallar och plattformsbegränsningar är fastställda. SEO behöver tillräckligt med tid för att inventera befintliga webbadresser, bevara värdefulla destinationer, påverka den nya informationsarkitekturen, definiera omdirigeringsbeteende och komma överens om mätbara lanserings- och återrullningsregler.

Bör gamla webbadresser omdirigeras till startsidan när det inte finns någon direkt ersättning?

Nej. Omdirigera en gammal webbadress till närmaste sida som tillgodoser samma användaravsikt. Om ingen relevant destination finns och innehållet inte bör bevaras, returnera en ärlig 404 eller 410 istället för att skicka användare och sökrobotar till en orelaterad startsida.

Hur länge bör migreringsomdirigeringar finnas kvar?

Behåll permanenta omdirigeringar så länge gamla webbadresser fortfarande kan få besök, länkar, bokmärken eller robotförfrågningar. Behandla dem som varaktig routningsinfrastruktur, inte lanseringsställning som ska tas bort efter några veckor.

Vad bör frysas före migreringslansering?

Frys den godkända webbadressinventeringen, omdirigeringskartan, kanoniska och robots-regler, generering av sajtstruktur, analys- och samtyckeskonfiguration, DNS- och CDN-ändringar samt orelaterade produktionsreleaser. Nödåtgärder följer den namngivna ändringskontrollvägen.

När bör en migrering rullas tillbaka?

Använd kriterier som fastställts före lansering. Rulla tillbaka vid fel såsom långvarig otillgänglighet, omfattande 5xx-svar, trasiga primära användarflöden, saknad analysdata eller routningsdefekter som påverkar en väsentlig andel prioriterade webbadresser och inte kan korrigeras säkert inom den överenskomna återställningstiden.