Sjekkliste for nettstedsmigrering (SEO)

En nettstedsmigrering er en kontrollert endring av et nettsteds plattform, domene, protokoll, informasjonsarkitektur, URL-struktur eller gjengivelsessystem. Den er fullført først når brukere, kravroboter og analyseverktøy kan nå det ønskede innholdet via stabile ruter, og teamet kan bevise at verdifull synlighet har overlevd.

Sjekkliste: SEO-nettstedsmigrering. Tidsramme: start 6–12 uker før lansering for et mellomstort nettsted; reserver de siste 5 virkedagene for endringsfrys, lanseringsdagen for bemannet validering, og minst 4 uker for aktiv overvåking. Eier: én migreringsleder ansvarlig for hele utrullingen, støttet av navngitte eiere for utvikling, SEO, analyse, innhold og infrastruktur.

Hvorfor denne sjekklisten finnes, og hvorfor den kjøres her

Dette utrullingskontrolllaget i SEO-prosessen bruker krav- og indeksevidence fra teknisk grunnlagsrevisjon , beholde/slå-sammen/fjerne-beslutninger fra innholdsoversikt og -revisjon , og destinasjonshierarkiet fra emnekart og informasjonsarkitektur . Disse resultatene må eksistere før omdirigeringer eller staging kan vurderes.

Kjør den etter at destinasjonsstrukturen er godkjent, men før produksjonsrutene er fryst. Hvis den kjøres for tidlig, kartlegger teamet omdirigeringer til destinasjoner som fortsatt kan endres. Hvis den kjøres for sent, kan ruting, maler, analyseverktøy eller lanseringskommunikasjon allerede være for kostbare å rette trygt.

Omdirigeringskartet er den enkeltstående høyrisikoartefakten fordi det forbinder gamle ruter med nye. Hver verdifull gammel URL bør gå én-til-én til nærmeste destinasjon som bevarer dens formål. Bruk aldri startsiden som en samlepost: det frustrerer besøkende og skjuler manglende destinasjoner.

Inndata og utdata

Utdatene er kontrakten med lanseringsoperasjonene. Et regneark uten eiere, bevis eller akseptkriterier er ikke en overlevering.

Sjekklisten

Hvert punkt angir hva, hvorfor, hvordan, verktøy og en observerbar ferdig-når-tilstand. Erstatt en terskel kun med en strengere regel eller en dokumentert referansebasert regel.

Fase 1: pre-migreringsbeholdning

1. Bygg den samlede URL-beholdningen. Hva: kombiner alle oppdagbare gamle URL-er fra krav, XML-sidekart, analyseverktøy, Search Console, tilbakelenkeeksporter, CMS-poster, betalte kampanjer og serverlogger. Hvorfor: ingen enkeltkilde inneholder alle verdifulle eller etterspurte URL-er; en side som mangler i navigasjonen kan fortsatt ha lenker, trafikk eller kontraktsmessig betydning. Hvordan: normaliser protokoll, vert, store/små bokstaver, etterfølgende skråstrek, parametere og kodede tegn mens du beholder den rå kildeverdien. Dedupliser først etter at du har registrert hvor hver URL ble funnet. Verktøy: kravrobot, CMS-eksport, analyseverktøy, Search Console, tilbakelinkedata og logger. Ferdig når: hver kilde er datert, hver rad har en normalisert URL og oppdagelseskilde, duplikater er løst, og kildetotalene stemmer overens med den endelige beholdningen.

2. Klassifiser disponeringen for hver URL. Hva: merk hver URL med behold, flytt, slå sammen, fjern eller undersøk. Hvorfor: omdirigeringer kan ikke kartlegges korrekt før innholdsbeslutningen er tydelig. Hvordan: kombiner trafikk, konverteringer, tilbakelenker, indekstilstand, innholdskvalitet, forretningsbehov og intensjon; registrer beviset og godkjennende eier. Verktøy: beholdningsarbeidsbok og innholdsrevisjon. Ferdig når: 100 % av URL-er innenfor omfanget har én disponering, en eier, en destinasjon eller fjerningsårsak, og ingen uløste «undersøk»-rader gjenstår ved frys.

3. Fang opp den signerte referansen. Hva: bevar pre-lanseringsdata for organiske økter, klikk, visninger, konverteringer, inntekt, indekserte URL-er, kravfeil, responskoder, oppetid og ytelse for prioriterte maler og kataloger. Hvorfor: uten et datert sammenligningspunkt ser normal variasjon og migreringsskade like ut. Hvordan: eksporter minst 28 sammenlignbare dager, annoter kampanjer og sesongvariasjoner, og identifiser prioriterte URL-er som krever daglig gjennomgang. Verktøy: analyseverktøy, Search Console, kravrobot, rangeringdata og overvåking. Ferdig når: referansen er skrivebeskyttet, reproduserbar, segmentert, tidsstemplet og godkjent av SEO- og analyseeiere.

Fase 2: omdirigeringskartlegging

4. Kartlegg kilder én-til-én der det er mulig. Hva: tilordne hver flyttet eller sammenslått gammel URL til nærmeste nye URL med samme primære intensjon. Hvorfor: en presis destinasjon bevarer kontinuitet for besøkende og gir kravroboter et sammenhengende erstattingssignal. Hvordan: sammenlign emne, produkt, geografi, språk og oppgave; kartlegg sammenslåinger til den overlevende siden og dokumenter bevisste fjerninger. Kartlegg aldri uovertrufne URL-er til startsiden. Verktøy: omdirigeringskart-arbeidsbok, beholdning og krav av destinasjoner. Ferdig når: hver endrede kilde har nøyaktig ett godkjent utfall, hver destinasjon er relevant og innenfor omfanget, og startsidens samlepostkartlegginger er lik null.

5. Valider omdirigeringsmekanikk før lansering. Hva: test statuskoder, destinasjoner, spørringsatferd, varianter av store/små bokstaver, protokoll, underdomener, etterfølgende skråstreker, filer og kampanje-URL-er. Hvorfor: et korrekt utseende regneark kan fortsatt produsere løkker, kjeder, jokertegn som svelger gyldige sider, eller destinasjoner som returnerer feil. Hvordan: generer staging- eller proxy-reglene, forespør hver kilde, følg hopp og sammenlign den endelige URL-en med det godkjente kartet. Verktøy: automatisert HTTP-test, kravrobot og serverkonfigurasjonsgjennomgang. Ferdig når: 100 % av kartlagte kilder når den godkjente 200-destinasjonen i ett permanent omdirigeringshopp; løkker, kjeder, midlertidige omdirigeringer og feildestinasjoner er null.

6. Avstem kanoniske URL-er, lenker og sidekart med omdirigeringer. Hva: få den kanoniske URL-en , interne lenker, hreflang-referanser, strukturerte data, strømmer og XML-sidekart til å peke direkte til endelige URL-er. Hvorfor: å omdirigere gamle URL-er mens du fortsetter å publisere dem skaper motstridende migreringssignaler og sløser med kravrobotforespørsler. Hvordan: krav hver referansekilde og sammenlign normaliserte mål med omdirigeringskartet. Verktøy: kravrobot, gjengitt HTML, sidekartparser og konfigurasjonsdiff. Ferdig når: endelige sider selvkanoniserer med mindre et godkjent unntak sier noe annet, interne referanser til omdirigerte URL-er er null, og nye sidekart inneholder kun kanoniske 200-URL-er.

Fase 3: staging-validering

7. Test staging uten å gjøre det offentlig indekserbart. Hva: krav hele staging-utrullingen mens du forhindrer søkemotorer fra å indeksere miljøet. Hvorfor: teamet trenger kravrobot-nivå bevis uten å tillate et duplikatnettsted i søkeresultatene. Hvordan: bruk tilgangskontroll for eksterne kravroboter, kjør deretter en autentisert intern krav med JavaScript-gjengivelse der produksjonsnettstedet er avhengig av det. Behandle en staging-blokkering som midlertidig utrullingskonfigurasjon, ikke noe å kopiere blindt til produksjon. Verktøy: autentisert kravrobot, nettleser og response-header-inspeksjon. Ferdig når: den forventede staging-beholdningen er kravbar av testteamet, uautorisert offentlig indeksering er blokkert, og produksjonslanseringssjekklisten fjerner eksplisitt staging-only-kontroller.

8. Verifiser maler og prioriterte brukerreiser. Hva: test representative sider fra hver mal pluss navigasjon, søk, skjemaer, registrering, utsjekk, lokalisering, paginering, filtre og feilsider. Hvorfor: en bestått startside avslører ikke en kanonisk feil på produktsider eller en ødelagt samtykketilstand som undertrykker analyseverktøy. Hvordan: lag en enhets- og malmatrise, test rene og returnerende økter, og registrer skjermbilder eller responsevidence for hvert resultat. Verktøy: nettleser, tilgjengelighetskontroll, validator for strukturert data, analyseverktøy for feilsøking og transaksjonstester. Ferdig når: hver mal innenfor omfanget og primær brukerreise består på avtalte nettlesere og enheter, med null kritiske feil åpne.

9. Sammenlign staging med de godkjente kontraktene. Hva: diff titler, beskrivelser, overskrifter, kanoniske URL-er, robots-direktiver, strukturerte data, interne lenker, responskoder, innhold og analyse-tagger mot det gamle nettstedet og destinasjonsspesifikasjonen. Hvorfor: plattformmigreringer mister ofte metadata eller endrer gjengivelse selv når den synlige teksten ser intakt ut. Hvordan: krav gammel produksjon og staging med matchede innstillinger, segmenter forskjeller etter mal, og godkjenn kun tilsiktede endringer. Verktøy: krav-diff-rapport og kildeinspeksjon. Ferdig når: hver vesentlig forskjell er enten rettet eller oppført som en godkjent endring med eier og årsak; utilsiktede noindex-, kanoniske-, innholds- og sporingsendringer er lik null.

10. Frys lanseringskandidaten. Hva: frys URL-beholdningen, omdirigeringskartet, rutedefinisjonene, kanoniske og robots-regler, sidekartgenerering, analyse- og samtykkeoppsett, DNS/CDN-plan og urelaterte produksjonsutrullinger. Hvorfor: et testresultat gjelder kun for versjonen som er testet. Hvordan: merk lanseringsartefaktene, begrens endringer til hendelsesstien, og krev omtesting av alt som påvirkes av en nødredigering. Verktøy: distribusjonssystem, endringslogg og godkjenningsjournal. Ferdig når: én uforanderlig kandidat er navngitt, tilgangen er begrenset, alle unntak har en eier, og hver endring etter frys har et testresultat.

Fase 4: lanseringsdagen

11. Utfør én eid runbook. Hva: distribuer ruting, applikasjon, DNS/CDN, analyseverktøy, sidekart og overvåkere i godkjent rekkefølge. Hvorfor: parallelle usekvenserte endringer gjør feil vanskelige å isolere og tilbakerulling utrygg. Hvordan: én migreringsleder kaller hvert steg, den tildelte operatøren registrerer fullføring, og validatorer tester bevisene før neste avhengige steg. Verktøy: runbook, distribusjonslogger, DNS-sjekker og delt hendelseskanal. Ferdig når: hver linje har et faktisk tidspunkt, operatør, resultat og bevislenke, og ingen avhengighet er merket fullført kun på muntlig forsikring.

12. Kjør lanserings-røykprøven. Hva: test startsiden, robots-filen, sidekart, minst én URL per mal, hver prioritert brukerreise, analysekvittering og et stratifisert utvalg av omdirigeringskilder. Hvorfor: den raskeste trygge responsen kommer fra å oppdage en bred feil før cacher og kravroboter sprer den. Hvordan: test fra utenfor produksjonsnettverket, bruk desktop og mobil, verifiser både serverlevert HTML og gjengitt utdata, og sammenlign med de frosne forventningene. Verktøy: kravrobot, nettleser, HTTP-klient, analyse-sanntidsvisning og transaksjonsovervåker. Ferdig når: kritiske sider returnerer tiltenkt status og innhold, prioriterte omdirigeringer når sine eksakte destinasjoner, analysehendelser ankommer med korrekte URL-er, og alle lanseringsblokkerende sjekker består.

13. Send inn og verifiser oppdagelsessignaler. Hva: publiser de endelige sidekartene, bekreft robots- og kanonisk atferd, og be om inspeksjon for et lite sett prioriterte URL-er. Hvorfor: rene oppdagelsessignaler hjelper kravroboter med å finne destinasjonssettet uten å behandle innsending som en garanti for indeksering. Hvordan: send inn hvert produksjonssidekart én gang, inspiser representative nye URL-er, og registrer Googles rapporterte kanoniske og indekstilstand. Verktøy: Sidekart og indeksering og URL-inspeksjon . Ferdig når: sidekart er tilgjengelige og inneholder den frosne kanoniske beholdningen, representative inspeksjoner viser ingen produksjonsblokkering eller feil kanonisk, og hver advarsel har en eier.

Fase 5: overvåking etter lansering

14. Overvåk de første 72 timene som et hendelsesvindu. Hva: overvåk oppetid, 5xx, 4xx, omdirigeringsfeil, ventetid, kravvolum, analysekvittering, konverteringer, sidekartbehandling og prioriterte brukerreiser kontinuerlig eller med kortest mulig intervall. Hvorfor: infrastruktur- og rutedefekter oppdages raskt, mens søkeytelse tar lengre tid og bør ikke brukes som den eneste lanseringsalarmen. Hvordan: sammenlign med den signerte referansen, segmenter etter mal og katalog, og ruter varsler til en vakt-eier. Verktøy: logger, analyseverktøy, kravrobot, Oppetidsovervåkere og hendelsesdashboard. Ferdig når: dashbordet har ingen uforklarte lanseringskritiske varsler, hver hendelse har en eier og tidsstempel, og 24-, 48- og 72-timersgjennomganger er signert.

15. Fortsett søk- og indeksovervåking etter stabilitet. Hva: spor klikk på sidenivå, visninger, indekstilstand, valgte kanoniske URL-er, kravfeil, katalogytelse og konverteringsresultater i minst fire uker. Hvorfor: krav, kanonisk valg og indekserstatning ligger etter infrastrukturvalidering. Hvordan: sammenlign like-for-like-vinduer, separer flyttede URL-er fra uendrede kontroller, og undersøk klynger i stedet for å reagere på én dags total. Verktøy: Google Search-sider , Katalogvisning , URL-inspeksjon, analyseverktøy og logger. Ferdig når: prioriterte destinasjoner er oppdagbare og indekserbare, gamle URL-er løses konsekvent til godkjente destinasjoner, uforklarte tap har billetter, og eierskap flyttes over til normal rapporteringsrytme.

Verktøy i AmICited

AmICited tilbyr lanseringsbevis og overvåkingsflater; det godkjente omdirigeringskartet og distribusjonsloggene forblir den operative sannhetskilden.

Beslutningsregler

Dette er utrullingssikringer, ikke universelle søkemotorterskler. Bli enige om dem før lansering og stram dem inn der risiko krever det.

Tilbakerulling gjenoppretter en kjent god tjenestetilstand; den reverserer ikke vanlige søkefluktuasjoner. Lanseringsmyndigheten anvender de avtalte reglene og registrerer bevisene.

Leveranse

Overlevere én versjonert migreringskontrollpakke tilgjengelig for utvikling og SEO. Bruk et regneark eller en database for poster på radnivå, en runbook for lanseringshandlinger og et dashboard for sanntidsmål.

Den må inneholde den frosne beholdningen og kildeavstemmingen; godkjent omdirigeringskart med eiere og tester; matchede gamle, staging- og nye krav; metadata-, kanonisk-, robots-, sidekart-, hreflang-, strukturert data-, lenke- og analysediffer; signert referanse og prioriterte kohorter; lanserings-runbook og gjenopprettingsprosedyre; numeriske tilbakerullingsregler og beslutningstaker; og 24-, 48- og 72-timersbevisene med fireukers overvåkingsansvar.

Migreringslederen må kunne identifisere den nøyaktige utrullingen, bevise hver kritisk test, rekonstruere hver rutebeslutning og tilordne hvert unntak. Ellers er pakken ufullstendig.

Hva går galt

Omdirigeringskartet bruker kun gjeldende sidekart. Foreldreløse URL-er, kampanje-URL-er, tilbakelenker og tidligere indekserte ruter forsvinner, så hver regnearkrad består mens reelle forespørsler feiler.

Startsiden blir standarddestinasjonen. Brukere havner et sted irrelevant, kravrobotsignaler blir tvetydige, og manglende innhold forkles som implementeringsfremgang.

Omdirigeringer fungerer, men referanser forblir gamle. Navigasjon, hreflang, kanoniske URL-er, strukturerte data og sidekart fortsetter å sende kravroboter gjennom unødvendige hopp og motstridende destinasjoner.

Staging-beskyttelse når produksjon. En kopiert noindex, autentiseringsregel, robots-blokkering eller CDN-policy ødelegger indekserbarhet . Krev et eksplisitt fjerningssteg og ekstern test.

Teamet validerer kun startsiden. En delt mal kan feilkonfigurere tusenvis av sider mens startsiden består. Sample hver mal og krav regler i stor skala.

Urelaterte utrullinger leveres sammen. Når plattform, analyse, samtykke, navigasjon, utsjekk og CDN-endringer deler et vindu, blir feil vanskelige å isolere eller reversere.

Søk vurderes for tidlig eller for bredt. Nettstedtotaler skjuler ødelagte kataloger, og én ustabil dag utløser unødvendige rettinger. Sammenlign flyttede kohorter, uendrede kontroller, kataloger og matchede vinduer.

Tilbakerulling diskuteres under driftsforstyrrelsen. En god plan navngir terskler, beslutningstaker, gjenopprettingstid, kommandoer, datakonsekvenser og valideringssekvens før lansering.

Neste fase

Når de første 72 timene er stabile, er neste steg kontinuerlig fornying og iterasjon . Det trenger den signerte referansen, endelig URL-kartlegging, lanseringsannoteringer, katalogkohorter, kjente unntak, hendelseshistorikk og navngitte eiere fra denne sjekklisten. Uten disse inndataene kan et senere trafikktap ikke skilles pålitelig mellom migreringsskade, ordinær etterspørselsendring, innholdsforfall eller målefeil.

Behold omdirigeringskartet og migreringsannoteringen permanent. Flytt ikke-kritiske funn til normal rapporteringsrytme med alvorlighetsgrad, hypotese, eier, forfallsdato og verifiseringsmetode.

Ofte stilte spørsmål

Når bør SEO-teamet delta i en nettstedsmigrering?

Før ruter, maler og plattformbegrensninger er låst. SEO trenger nok tid til å kartlegge gjeldende URL-er, bevare verdifulle destinasjoner, påvirke den nye informasjonsarkitekturen, definere omdirigeringsatferd og bli enige om målbare lanserings- og tilbakerullingsregler.

Bør gamle URL-er omdirigeres til startsiden når det ikke finnes noen direkte erstatning?

Nei. Omdiriger en gammel URL til nærmeste side som tilfredsstiller samme brukerintensjon. Hvis ingen relevant destinasjon finnes og innholdet ikke bør bevares, returner en ærlig 404 eller 410 i stedet for å sende brukere og kravroboter til en urelatert startside.

Hvor lenge bør migreringsomdirigeringer være på plass?

Behold permanente omdirigeringer så lenge gamle URL-er fortsatt kan motta besøk, lenker, bokmerker eller kravrobotforespørsler. Behandle dem som varig ruteinfrastruktur, ikke lanseringsstillaser som skal fjernes etter noen uker.

Hva bør fryses før migreringslansering?

Frys den godkjente URL-beholdningen, omdirigeringskartet, kanoniske og robots-regler, sidekartgenerering, analyse- og samtykkekonfigurasjon, DNS- og CDN-endringer, og urelaterte produksjonsutrullinger. Nødrettinger følger den navngitte endringskontrollstien.

Når bør en migrering rulles tilbake?

Bruk kriterier som er avtalt før lansering. Rull tilbake for feil som vedvarende utilgjengelighet, utbredte 5xx-svar, ødelagte primære brukerreiser, manglende analyseverktøy eller rutedefekter som påvirker en vesentlig andel av prioriterte URL-er og ikke kan rettes sikkert innenfor det avtalte gjenopprettingsvinduet.