Site Migration SEO-tjekliste

En site migration er en kontrolleret ændring af et websteds platform, domæne, protokol, informationsarkitektur, URL-struktur eller gengivelsessystem. Den er først fuldført, når brugere, crawlers og analyseværktøjer kan nå det tilsigtede indhold via stabile ruter, og teamet kan bevise, at værdifuld synlighed har overlevet.

Tjekliste: site migration SEO. Tidsramme: start 6–12 uger før lancering for et mellemstort site; reserver de sidste 5 arbejdsdage til en ændringsfrys, lanceringsdagen til bemandet validering og mindst 4 uger til aktiv overvågning. Ejer: én migrationsleder, der er ansvarlig for hele udgivelsen, støttet af navngivne ejere inden for engineering, SEO, analyse, indhold og infrastruktur.

Hvorfor denne tjekliste findes, og hvorfor den kører her

Dette udgivelseskontrollag i SEO-processen bruger crawl- og indeksevidens fra den tekniske baseline-audit , behold/sammenlæg/fjern-beslutninger fra indholdsinventar og -audit og destinationshierarkiet fra det topiske kort og informationsarkitektur . Disse output skal eksistere, før omdirigeringer eller staging kan vurderes.

Kør den, efter destinationsstrukturen er godkendt, men før produktionsruter er låst. Hvis den kører for tidligt, kortlægger teamet omdirigeringer til destinationer, der stadig kan ændre sig. Hvis den kører for sent, kan routing, skabeloner, analyseværktøjer eller lanceringskommunikation allerede være for dyr at rette sikkert.

Omdirigeringskortet er det artefakt med højest risiko, fordi det forbinder gamle ruter med nye. Hver værdifuld gammel URL bør gå én-til-én til den nærmeste destination, der bevarer dens formål. Brug aldrig forsiden som en opsamlingsløsning: det frustrerer besøgende og skjuler manglende destinationer.

Inputs og outputs

Outputs er kontrakten med lanceringsoperationerne. Et regneark uden ejere, evidens eller acceptkriterier er ikke en overdragelse.

Tjeklisten

Hvert punkt angiver hvad, hvorfor, hvordan, værktøj og en observerbar færdig-når-tilstand. Erstat kun en tærskel med en strengere regel eller en dokumenteret baseline-baseret regel.

Fase 1: præ-migrationsinventar

1. Opbyg det samlede URL-inventar. Hvad: kombiner alle opdagelige gamle URL’er fra crawls, XML-sitemaps, analyseværktøjer, Search Console, backlink-eksporter, CMS-journaler, betalte kampagner og serverlogge. Hvorfor: ingen enkelt kilde indeholder alle værdifulde eller anmodede URL’er; en side, der er fraværende i navigationen, kan stadig have links, trafik eller kontraktlig betydning. Hvordan: normaliser protokol, vært, casing, efterstillet skråstreg, parametre og kodede tegn, mens den rå kildeværdi bevares. Dedupliker først efter at have registreret, hvor hver URL blev fundet. Værktøj: crawler, CMS-eksport, analyseværktøj, Search Console, backlink-data og logs. Færdig når: hver kilde er dateret, hver række har en normaliseret URL og opdagelseskilde, dubletter er løst, og kildetotaler stemmer overens med det endelige inventar.

2. Klassificér dispositionen for hver URL. Hvad: mærk hver URL som behold, flyt, sammenlæg, fjern eller undersøg. Hvorfor: omdirigeringer kan ikke kortlægges korrekt, før indholdsbeslutningen er eksplicit. Hvordan: kombiner trafik, konverteringer, backlinks, indekstilstand, indholdskvalitet, forretningsbehov og hensigt; registrer evidensen og den godkendende ejer. Værktøj: inventar-arbejdsbog og indholdsaudit. Færdig når: 100 % af URL’er inden for scope har én disposition, en ejer, en destination eller fjernelsesårsag, og ingen uafklarede “undersøg”-rækker er tilbage ved frysning.

3. Indfang den underskrevne baseline. Hvad: bevar præ-lancerings organiske sessioner, klik, visninger, konverteringer, indtægt, indekserede URL’er, crawl-fejl, svarkoder, oppetid og performance for prioritetsskabeloner og -mapper. Hvorfor: uden et dateret sammenligningspunkt ligner normal variation og migrationsskade hinanden. Hvordan: eksportér mindst 28 sammenlignelige dage, annotér kampagner og sæsonudsving, og identificér prioritets-URL’er, der kræver daglig gennemgang. Værktøj: analyseværktøj, Search Console, crawler, rangeringsdata og overvågning. Færdig når: baselinen er skrivebeskyttet, reproducerbar, segmenteret, tidsstemplet og godkendt af SEO- og analyze-ejere.

Fase 2: omdirigeringskortlægning

4. Kortlæg kilder én-til-én, hvor det er muligt. Hvad: tildel hver flyttet eller sammenlagt gammel URL til den nærmeste nye URL med samme primære hensigt. Hvorfor: en præcis destination bevarer kontinuiteten for den besøgende og giver crawlers et sammenhængende erstatningssignal. Hvordan: sammenlign emne, produkt, geografi, sprog og opgave; kortlæg sammenlægninger til den overlevende side og dokumentér bevidste fjernelser. Kortlæg aldrig umatchede URL’er til forsiden. Værktøj: omdirigeringskort-arbejdsbog, inventar og destinationscrawl. Færdig når: hver ændret kilde har præcis ét godkendt resultat, hver destination er relevant og inden for scope, og antallet af forside-opsamlingskortlægninger er nul.

5. Valider omdirigeringsmekanik før lancering. Hvad: test statuskoder, destinationer, forespørgselsadfærd, casing-varianter, protokol, underdomæner, efterstillede skråstreger, filer og kampagne-URL’er. Hvorfor: et korrekt udseende regneark kan stadig producere løkker, kæder, wildcards, der sluger gyldige sider, eller destinationer, der returnerer fejl. Hvordan: generér staging- eller proxy-reglerne, anmod om hver kilde, følg hop og sammenlign den endelige URL med det godkendte kort. Værktøj: automatiseret HTTP-test, crawler og serverkonfigurationsgennemgang. Færdig når: 100 % af kortlagte kilder når den godkendte 200-destination i ét permanent omdirigeringshop; løkker, kæder, midlertidige omdirigeringer og fejldestinationer er nul.

6. Afstem kanoniske URL’er, links og sitemaps med omdirigeringer. Hvad: få den kanoniske URL , interne links, hreflang-referencer, strukturerede data, feeds og XML-sitemaps til at pege direkte på endelige URL’er. Hvorfor: at omdirigere gamle URL’er mens man fortsætter med at publicere dem skaber modstridende migrationssignaler og spilder crawler-forespørgsler. Hvordan: crawl hver referencekilde og sammenlign normaliserede mål med omdirigeringskortet. Værktøj: crawler, gengivet HTML, sitemap-parser og konfigurationsdiff. Færdig når: endelige sider selv-kanoniserer, medmindre en godkendt undtagelse siger andet, interne referencer til omdirigerede URL’er er nul, og nye sitemaps indeholder kun kanoniske 200-URL’er.

Fase 3: staging-validering

7. Test staging uden at gøre det offentligt indekserbart. Hvad: crawl den komplette staging-udgivelse, mens søgemaskiner forhindres i at indeksere miljøet. Hvorfor: teamet har brug for crawler-niveau-evidens uden at tillade et dubletsite i søgeresultaterne. Hvordan: brug adgangskontrol for eksterne crawlers, kør derefter et autentificeret internt crawl med JavaScript-gengivelse, hvor produktionssitet afhænger af det. Behandl en staging-blokering som midlertidig udgivelseskonfiguration, ikke noget der skal kopieres blindt til produktion. Værktøj: autentificeret crawler, browser og svarhoved-inspektion. Færdig når: det forventede staging-inventar kan crawles af testteamet, uautoriseret offentlig indeksering er blokeret, og produktionslancerings-tjeklisten eksplicit fjerner staging-only-kontroller.

8. Verificér skabeloner og prioritets-brugerrejser. Hvad: test repræsentative sider fra hver skabelon samt navigation, søgning, formularer, tilmelding, checkout, lokalisering, paginering, filtre og fejlsider. Hvorfor: en forside, der består testen, afslører ikke en kanonisk fejl på produktsider eller en ødelagt samtykketilstand, der undertrykker analyse. Hvordan: opret en enhed-og-skabelon-matrix, test rene og returnerende sessioner, og registrér skærmbilleder eller svarevidens for hvert resultat. Værktøj: browser, tilgængelighedskontrol, struktureret-data-validering, analysefejlsøger og transaktionstests. Færdig når: hver skabelon og primær brugerrejse inden for scope består på de aftalte browsere og enheder med nul kritiske fejl åbne.

9. Sammenlign staging med de godkendte kontrakter. Hvad: diff titler, beskrivelser, overskrifter, kanoniske URL’er, robots-direktiver, strukturerede data, interne links, svarkoder, indhold og analyse-tags mod det gamle site og destinationsspecifikationen. Hvorfor: platformsmigrationer mister ofte metadata eller ændrer gengivelse, selv når den synlige tekst ser intakt ud. Hvordan: crawl gammel produktion og staging med matchede indstillinger, segmentér forskelle efter skabelon, og godkend kun tilsigtede ændringer. Værktøj: crawl-diff-rapport og kildeinspektion. Færdig når: enhver væsentlig forskel er enten rettet eller opført som en godkendt ændring med ejer og årsag; utilsigtede noindex, kanoniske, indholds- og sporingsændringer er nul.

10. Frys udgivelseskandidaten. Hvad: frys URL-inventaret, omdirigeringskortet, rutedefinitionerne, kanoniske- og robots-reglerne, sitemap-genereringen, analyse- og samtykkeopsætningen, DNS/CDN-planen og ikke-relaterede produktionsimplementeringer. Hvorfor: et testresultat gælder kun for den testede version. Hvordan: tag udgivelsesartefakterne, begræns ændringer til hændelsesstien, og kræv gen-test af alt, der påvirkes af en nødredigering. Værktøj: implementeringssystem, ændringslog og godkendelsesjournal. Færdig når: én uforanderlig kandidat er navngivet, adgang er begrænset, alle undtagelser har en ejer, og hver ændring efter frysning har et testresultat.

Fase 4: lanceringsdag

11. Udfør én ejet runbook. Hvad: implementér routing, applikation, DNS/CDN, analyseværktøjer, sitemaps og overvågning i den godkendte rækkefølge. Hvorfor: parallelle, ikke-sekventielle ændringer gør fejl svære at isolere og rollback usikker. Hvordan: én migrationsleder kalder hvert trin, den tildelte operatør registrerer fuldførelse, og validatorer tester evidensen før det næste afhængige trin. Værktøj: runbook, implementeringslogs, DNS-tjek og delt hændelseskanal. Færdig når: hver linje har et faktisk tidspunkt, operatør, resultat og evidenslink, og ingen afhængighed er markeret som fuldført alene på mundtlig forsikring.

12. Kør lancerings-røgtesten. Hvad: test forsiden, robots-filen, sitemaps, mindst én URL pr. skabelon, hver prioritets-brugerrejse, analyse-modtagelse og et stratificeret udvalg af omdirigeringskilder. Hvorfor: det hurtigste sikre svar kommer fra at opdage en bred fejl, før caches og crawlers spreder den. Hvordan: test udefra produktionsnetværket, brug desktop og mobil, verificér både server-leveret HTML og gengivet output, og sammenlign med de frosne forventninger. Værktøj: crawler, browser, HTTP-klient, analyse-realtidsvisning og transaktionsmonitor. Færdig når: kritiske sider returnerer den tilsigtede status og det tilsigtede indhold, prioritetsomdirigeringer når deres nøjagtige destinationer, analysehændelser ankommer med korrekte URL’er, og alle lanceringsblokerende tjek består.

13. Indsend og verificér opdagelsessignaler. Hvad: publicér de endelige sitemaps, bekræft robots- og kanonisk-adfærd, og anmod om inspektion for et lille sæt prioritets-URL’er. Hvorfor: rene opdagelsessignaler hjælper crawlers med at finde destinationssættet uden at behandle indsendelse som en garanti for indeksering. Hvordan: indsend hvert produktions-sitemap én gang, inspicér repræsentative nye URL’er, og registrér Googles rapporterede kanoniske URL og indekstilstand. Værktøj: Sitemaps og indeksering og URL-inspektion . Færdig når: sitemaps er tilgængelige og indeholder det frosne kanoniske inventar, repræsentative inspektioner viser ingen produktionsblokering eller forkert kanonisk URL, og hver advarsel har en ejer.

Fase 5: monitorering efter lancering

14. Overvåg de første 72 timer som et hændelsesvindue. Hvad: monitorér oppetid, 5xx, 4xx, omdirigeringsfejl, latenstid, crawl-volumen, analyse-modtagelse, konverteringer, sitemap-behandling og prioritets-brugerrejser kontinuerligt eller med kortest muligt interval. Hvorfor: infrastruktur- og routingfejl viser sig hurtigt, mens søgeperformance tager længere tid og bør ikke være den eneste lanceringsalarm. Hvordan: sammenlign med den underskrevne baseline, segmentér efter skabelon og mappe, og dirigér alarmer til en vagthavende ejer. Værktøj: logs, analyseværktøj, crawler, Oppetidsovervågning og hændelsesdashboard. Færdig når: dashboardet har ingen uforklarlige lanceringskritiske alarmer, hver hændelse har en ejer og et tidsstempel, og 24-, 48- og 72-timers-gennemgange er underskrevet.

15. Fortsæt søge- og indeksmonitorering efter stabilitet. Hvad: følg side-niveau klik, visninger, indekstilstand, valgte kanoniske URL’er, crawl-fejl, mappe-performance og konverteringsresultater i mindst fire uger. Hvorfor: crawling, kanonisk udvælgelse og indekserstatning halter efter infrastrukturvalidering. Hvordan: sammenlign ensartede tidsvinduer, adskil flyttede URL’er fra uændrede kontroller, og undersøg klynger i stedet for at reagere på én dags total. Værktøj: Google Search-sider , Mapperingsvisning , URL-inspektion, analyseværktøj og logs. Færdig når: prioritetsdestinationer er opdagelige og indekserbare, gamle URL’er løbende opløses til godkendte destinationer, uforklarlige tab har billetter, og ejerskabet overgår til den normale rapporteringsrytme.

Værktøjer i AmICited

AmICited leverer lanceringsevidens og overvågningsflader; det godkendte omdirigeringskort og implementeringslogs forbliver den operationelle kilde til sandhed.

Beslutningsregler

Disse er udgivelsesbeskyttelsesforanstaltninger, ikke universelle søgemaskinetærskler. Aftal dem før lancering og stram dem, hvor risikoen kræver det.

Rollback genopretter en kendt god servicetilstand; det vender ikke almindelig søgefluktuation. Lance ringsmyndigheden anvender de aftalte regler og registrerer evidensen.

Leverance

Overgiv én versionsstyret migrationskontrolpakke, der er tilgængelig for engineering og SEO. Brug en arbejdsbog eller database til række-niveau-poster, en runbook til lanceringshandlinger og et dashboard til levende målinger.

Den skal indeholde det frosne inventar og kildeafstemning; godkendt omdirigeringskort med ejere og tests; matchede gamle, staging og nye crawls; metadata-, kanonisk-, robots-, sitemap-, hreflang-, struktureret-data-, link- og analyse-diffs; underskrevet baseline og prioritetskohorter; lanceringsrunbook og genopretningsprocedure; numeriske rollback-regler og beslutningsejer; og 24-, 48- og 72-timers-evidens med fire-ugers overvågningsejerskab.

Migrationslederen skal kunne identificere den nøjagtige udgivelse, bevise hver kritisk test, rekonstruere hver routingbeslutning og tildele hver undtagelse. Ellers er pakken ufuldstændig.

Hvad går galt

Omdirigeringskortet bruger kun det aktuelle sitemap. Forældreløse URL’er, kampagne-URL’er, backlinks og tidligere indekserede ruter forsvinder, så hver regnearksrække består, mens rigtige forespørgsler fejler.

Forsiden bliver standarddestinationen. Brugere lander et irrelevant sted, crawler-signaler bliver tvetydige, og manglende indhold maskeres som implementeringsfremskridt.

Omdirigeringer virker, men referencer forbliver gamle. Navigation, hreflang, kanoniske URL’er, strukturerede data og sitemaps fortsætter med at sende crawlers gennem unødvendige hop og modstridende destinationer.

Staging-beskyttelse når produktion. En kopieret noindex, autentificeringsregel, robots-blokering eller CDN-politik ødelægger indekserbarhed . Kræv et eksplicit fjernelsestrin og ekstern test.

Teamet validerer kun forsiden. En delt skabelon kan fejlkonfigurere tusindvis af sider, mens forsiden består. Stikprøv hver skabelon og crawl regler i stor skala.

Ikke-relaterede udgivelser sendes sammen. Når platform, analyse, samtykke, navigation, checkout og CDN-ændringer deler et vindue, bliver fejl svære at isolere eller vende.

Søgning bedømmes for tidligt eller bredt. Sitetotaler skjuler ødelagte mapper, og én volatil dag udløser unødvendige rettelser. Sammenlign flyttede kohorter, uændrede kontroller, mapper og matchede vinduer.

Rollback debatteres under nedetiden. En god plan navngiver tærskler, beslutningstager, genopretningstid, kommandoer, datakonsekvenser og valideringssekvens før lancering.

Næste fase

Når de første 72 timer er stabile, er næste skridt løbende opdatering og iteration . Den har brug for den underskrevne baseline, endelige URL-kortlægning, lanceringsannotationer, mappekohorter, kendte undtagelser, hændelseshistorik og navngivne ejere fra denne tjekliste. Uden disse inputs kan et senere trafiktab ikke pålideligt adskilles i migrationsskade, almindelig efterspørgselsændring, indholdsforfald eller målefejl.

Behold omdirigeringskortet og migrationsannotationen permanent. Flyt ikke-kritiske fund ind i den normale rapporteringsrytme med en alvorlighed, hypotese, ejer, deadline og verifikationsmetode.

Ofte stillede spørgsmål

Hvornår bør SEO-teamet deltage i en site migration?

Før ruter, skabeloner og platformbegrænsninger er låst fast. SEO har brug for tilstrækkelig tid til at inventarisere nuværende URL’er, bevare værdifulde destinationer, påvirke den nye informationsarkitektur, definere omdirigeringsadfærd og aftale målbare lancerings- og rollback-regler.

Bør gamle URL’er omdirigere til forsiden, når der ikke findes en direkte erstatning?

Nej. Omdirigér en gammel URL til den nærmeste side, der opfylder den samme brugerhensigt. Hvis der ikke findes nogen relevant destination, og indholdet ikke bør bevares, så returnér en ærlig 404 eller 410 i stedet for at sende brugere og crawlers til en ikke-relateret forside.

Hvor længe bør migrationsomdirigeringer forblive aktive?

Behold permanente omdirigeringer, så længe gamle URL’er stadig kan modtage besøg, links, bogmærker eller crawler-forespørgsler. Behandl dem som holdbar routing-infrastruktur, ikke lanceringsstillas, der skal fjernes efter et par uger.

Hvad bør fryses før migrationslancering?

Frys den godkendte URL-inventarliste, omdirigeringskort, kanoniske- og robots-regler, sitemap-generering, analyse- og samtykkekonfiguration, DNS- og CDN-ændringer samt ikke-relaterede produktionsudgivelser. Akutrettelser følger den navngivne ændringskontrolsti.

Hvornår bør en migration rulles tilbage?

Brug kriterier, der er aftalt før lancering. Rul tilbage ved fejl som vedvarende utilgængelighed, udbredte 5xx-svar, ødelagte primære brugerrejser, manglende analyse eller routingfejl, der påvirker en væsentlig andel af prioritets-URL’er og ikke kan rettes sikkert inden for den aftalte genopretningsramme.