Vad ska en checklista för SEO-migrering innehålla?
En checklista för SEO-migrering ska koppla varje risk till en ansvarig person, ett verifierbart test och ett beslut inför lansering. Den behöver täcka inventering, URL-mappning, omdirigeringar, indexering, innehåll, mätning och återställning. Dokumentera även när kontrollen görs och vilket bevis som krävs för att markera den som godkänd.
Börja med ett gemensamt körschema där projektledare, utvecklare, innehållsansvarig och SEO-ansvarig har namngivna uppgifter. Samma person kan ha flera roller, men ingen kritisk kontroll får sakna ägare. Utse en person som fattar beslut om publicering och en ersättare som kan agera om den personen inte är tillgänglig.
Beskriv flyttens omfattning: domän, protokoll, sökvägar, mallar, innehåll och teknisk plattform. Skilj nödvändiga förändringar från sådant som kan vänta. Om ni samtidigt skriver om alla tjänstesidor och byter navigering blir det svårare att förstå orsaken till senare förändringar. Minimera därför oberoende ändringar under själva flyttfönstret.
Skapa en gemensam avvikelselogg med fälten sida, problem, konsekvens, ansvarig, prioritet och omtest. Bestäm vad som blockerar lanseringen, exempelvis generell noindex eller trasiga offertformulär. Lägg också in tid för rättning. En kontrollista utan reserverad utvecklingskapacitet ger ingen praktisk beredskap när ett fel faktiskt upptäcks.
Hur inventerar ni adresser och sparar en användbar baslinje?
Inventera gamla adresser genom att kombinera en crawl med webbplatskartor, analysdata, Search Console och tillgängliga serverloggar. Ingen enskild källa visar nödvändigtvis hela webbplatsen. Spara samtidigt en daterad baslinje för trafik, indexering och affärshändelser så att ni senare kan skilja tekniska fel från normal variation och planerade förändringar.
Exportera URL, statuskod, titel, huvudrubrik, canonical, indexeringsdirektiv och antal interna länkar. Lägg till organiska klick och viktiga affärshändelser där datan finns. Ta även med PDF-filer, bilder med relevant söktrafik och gamla kampanjsidor som fortfarande har användbara externa länkar. En föräldralös sida kan saknas i crawlen men finnas i andra datakällor.
Prioritera sedan sidor efter affärsvärde och beroenden, inte enbart besöksantal. En offertadress med få men kvalificerade förfrågningar kan vara viktigare än en välbesökt informationssida. Märk ut kritiska mallar, språkversioner, filter och paginering. Dessa grupper blir underlag för både manuella stickprov och automatiserade tester.
Spara exporterna tillsammans med datum, mätperiod och kända begränsningar. Jämför gärna med motsvarande säsong om verksamheten varierar under året. Dokumentera ändringar i samtycke och analysimplementation separat. Annars kan ett mätbortfall efter publicering misstolkas som förlorad organisk trafik trots att användarna fortfarande når webbplatsen.
Hur bygger ni URL-mappningen före flytten?
Bygg URL-mappningen som en tabell där varje gammal adress får en avsedd ny destination eller ett dokumenterat beslut om borttagning. Matcha efter innehåll och användarens avsikt, inte bara efter liknande sökvägar. Tabellen ska kunna användas både för implementation av redirects och för automatiserad kontroll av slutresultatet efter publicering.
Använd kolumnerna gammal URL, nuvarande status, ny URL, åtgärd, förväntad slutstatus, prioritet och godkännare. Ange hela adresser när domänen ändras. Bestäm också hur versaler, avslutande snedstreck, kodade tecken och relevanta parametrar ska hanteras. Skilj spårningsparametrar från parametrar som faktiskt väljer en produkt eller ett innehåll.
Vid sammanslagning kan flera gamla sidor peka till samma nya sida, men ersättaren måste täcka deras huvudsakliga behov. Om en gammal tjänst saknar motsvarighet kan en tydlig 404 eller 410 vara riktigare än startsidan. Skriv skälet i mappningen så att beslutet inte senare misstas för en missad redirect.
Låt innehållsansvarig kontrollera relevansen och utvecklaren verifiera att reglerna kan genomföras utan konflikter. Lås sedan en versionsmärkt export inför lanseringen. Ändringar efter låsningen ska få en ansvarig och följas av nya tester. Det gör att testresultat och installerade regler verkligen avser samma underlag.
Hur ska permanenta redirects implementeras och testas?
Använd permanenta serverbaserade omdirigeringar, normalt 301 eller 308, när adresser flyttas permanent. Varje gammal URL ska helst nå rätt fungerande slutadress i ett enda steg. Testa både individuella undantag och generella regler, eftersom en korrekt regel för huvudstrukturen ändå kan ge fel för parametrar, språk eller äldre sökvägar.
Implementera specifika undantag före breda mönsterregler när systemets regelordning kräver det. Kontrollera HTTP till HTTPS, alternativa värdnamn och gamla sökvägar tillsammans. En vanlig miss är att först byta domän och därefter sökväg i ytterligare ett steg. Sikta i stället på den avsedda slutadressen direkt när det går.
Kör hela mappningen genom ett test som sparar första status, Location-header, antal hopp och slutstatus. Flagga loopar, oväntade domäner, kedjor och destinationer som svarar med felkod. Kontrollera också att en sida inte ger 200 men visar ett tomt felmeddelande. Sådana mjuka fel upptäcks inte genom statuskoden ensam.
Uppdatera interna länkar till slutadresserna i stället för att förlita er på omdirigeringar. Behåll kontroll över gammal domän, DNS och certifikat så att gamla HTTPS-länkar fungerar. Planera att behålla redirects minst ett år, gärna längre där gamla länkar fortfarande används. Ta inte bort dem bara för att lanseringsprojektet avslutas.
Hur skyddas staging och hur tas noindex bort säkert?
Skydda staging med autentisering eller motsvarande åtkomstkontroll och använd noindex som ett kompletterande skydd där det är lämpligt. Inför lanseringen ska produktionsmiljön uttryckligen testas utan oavsiktlig noindex. Kontrollen måste omfatta både HTML, HTTP-headers och miljöberoende inställningar, eftersom samma publiceringsflöde annars kan föra över testmiljöns spärrar till den publika sajten.
Dokumentera var indexeringsinställningarna ligger: CMS, SEO-tillägg, webbserver, CDN och eventuella byggvariabler. En borttagen metatagg hjälper inte om servern fortfarande skickar X-Robots-Tag med noindex. Låt utvecklaren visa exakt vilken konfiguration som ändras vid produktionssättning och vem som kontrollerar svaret efteråt.
Håll staging skyddad även efter lanseringen. Flytta inte bara bort lösenordet och anta att testadresserna saknar betydelse. Interna länkar, canonicals och strukturerad data ska använda produktionsdomänen på den publika webbplatsen. Sök därför igenom både rå HTML och renderat innehåll efter stagingvärdnamn innan godkännande.
Lägg en särskild kontrollpunkt direkt efter driftsättning: hämta startsida, tjänstesida, kategori och en djup undersida från den riktiga domänen. Kontrollera svarshuvuden och sidkod med samma metod som i förtestet. Om en global indexeringsspärr finns kvar ska den hanteras som ett lanseringsblockerande fel, inte som en efterföljande optimeringsuppgift.
Hur kontrolleras robots.txt, canonicals och webbplatskartor?
Kontrollera att robots.txt tillåter hämtning av avsedda publika sidor och att canonicals pekar på rätt produktionsadresser. Webbplatskartan ska innehålla indexerbara slutadresser med fungerande svar. De här signalerna behöver stämma överens med interna länkar och redirects, annars blir webbplatsens föredragna struktur otydlig för både tester och sökmotorer.
Robots.txt blockerar hämtning men är inte ett säkert sätt att ta bort en adress ur index. En blockerad robot kan inte läsa sidans noindex. Återanvänd därför inte en generell stagingregel som förbjuder hela webbplatsen. Granska även regler för resurser som behövs för att rendera innehållet korrekt.
Verifiera canonicals på representativa mallar och genom en crawl. En ny produktsida ska inte av misstag peka på gammal domän eller startsidan. Självrefererande canonical är normalt lämplig för den föredragna indexerbara versionen, medan verkliga dubbletter behöver en genomtänkt hantering. Canonical är en signal och ersätter inte en permanent omdirigering av en flyttad adress.
Generera en ny XML-webbplatskarta från produktionsdata och testa att den går att hämta. Ta bort omdirigerade och felaktiga URL:er. Om ni använder hreflang ska språkreferenserna uppdateras och vara ömsesidiga där det krävs. Spara resultaten i samma kontrollprotokoll så att en godkänd sitemap inte döljer motstridiga signaler på själva sidorna.
Vilken QA måste vara godkänd före lanseringen?
QA före lansering ska visa att prioriterade adresser, innehåll och affärsfunktioner fungerar i den nya miljön. Testa tekniska svar automatiskt och komplettera med manuell granskning av varje viktig sidtyp. Publicera först när blockerande fel är rättade och ansvariga har godkänt kvarvarande avvikelser med tydlig konsekvens och plan för åtgärd.
Jämför den nya crawlen med baslinjen. Leta efter bortfall av huvudtext, titlar, rubriker, interna länkar och strukturerad data. Kontrollera att innehåll inte bara syns efter en interaktion som sökmotorn kanske inte genomför. Granska mobil navigering, filtrering och sidindelning med verkliga exempel från sortimentet eller tjänsteutbudet.
Genomför ett fullständigt test av kontaktformulär, offertflöde eller köp. Bekräfta att meddelandet faktiskt når mottagaren, inte bara att ett tackmeddelande visas. Kontrollera analysens händelser med hänsyn till samtycke och undvik att testförfrågningar blandas ihop med riktiga affärer. Dokumentera testtid, adress och förväntat utfall.
Sätt konkreta acceptanskriterier: alla kritiska mappningar rätt, inga globala indexeringsspärrar och fungerande huvudkonvertering. Mät också prestanda på representativa mallar under jämförbara förhållanden. Enstaka poäng ska inte ensamma avgöra lanseringen, men en tydlig försämring som gör centrala funktioner svåra att använda behöver utredas innan publicering.
Hur genomförs själva lanseringen steg för steg?
Genomför lanseringen som ett tidsatt körschema med en beslutsansvarig och tydliga stoppunkter. Säkerhetskopiera först, lås förändringar och bekräfta återställningsvägen. Publicera sedan den nya miljön och omdirigeringarna, kontrollera produktionen direkt och öppna inte projektet för vanliga ändringar förrän de kritiska testerna faktiskt har passerat på den riktiga domänen.
Steg ett är en gemensam avstämning med utvecklare, SEO-ansvarig och verksamhet. Bekräfta rätt version, aktuella säkerhetskopior och tillgängliga behörigheter. Spara gammal konfiguration för DNS, redirects och server. Om DNS ska ändras behöver tidsåtgång och cacheeffekter ingå i planen, inte upptäckas under arbetets gång.
Steg två är driftsättning enligt den beslutade ordningen. Aktivera rätt produktionskonfiguration och omdirigeringsregler. Testa från en extern anslutning att gammal adress når ny, att nya sidor svarar rätt och att certifikat fungerar. Rensa relevanta cachelager när det behövs och verifiera därefter svaret igen.
Steg tre är produktionskontroll av noindex, robots.txt, canonical, sitemap och konverteringsflöde. Kör mappningstesterna igen, nu mot publika adresser. Skriv tidpunkt och resultat i körschemat. Beslutsansvarig godkänner fortsatt drift eller aktiverar åtgärdsplanen. Avsluta inte bemanningen förrän ni vet vem som bevakar fel och vem som kan rätta dem efter lanseringsfönstret.
Hur följer ni migreringen i Google Search Console?
Följ migreringen i Google Search Console genom att kontrollera egendomar, skicka den nya webbplatskartan och granska viktiga adresser. Jämför sedan klick, visningar och indexeringssignaler med er baslinje. Rapporteringen har fördröjningar, så kombinera den med direkta tester och serverdata i stället för att vänta på att varje tekniskt fel ska synas där.
Verifiera behörighet till både gammal och ny egendom före ett domänbyte. Använd verktyget för adressändring när flytttypen stöds, inte vid enbart ändrade sökvägar inom samma domän. Det ersätter varken redirects eller övriga kontroller. Behåll tillgång till den gamla egendomen så att ni kan följa hur gamla adresser hanteras.
Använd URL-granskning för ett urval av prioriterade slutadresser och misstänkta problem. Skilj det aktuella livetestet från information om den senast indexerade versionen. Kontrollera vald canonical när data finns. En begäran om indexering är ingen garanti och bör inte användas som ersättning för att rätta blockerad åtkomst eller svagt innehåll.
Planera daglig teknisk uppföljning under de första arbetsdagarna och därefter återkommande kontroller utifrån webbplatsens storlek och risk. Segmentera gamla och nya sidgrupper samt varumärkessökningar och andra sökningar. Utred större avvikelser med URL-exempel. Summerad trafik räcker inte för att upptäcka att en enskild viktig kategori har tappat sina fungerande landningssidor.
När ska ni rätta framåt eller aktivera rollback?
Rätta framåt när felet är avgränsat och kan lösas snabbt utan att skapa större risker. Aktivera rollback när avtalade kritiska funktioner inte går att återställa inom ert beslutade tidsfönster. Beslutet ska bygga på tekniska fel, affärspåverkan och återställningens genomförbarhet, inte enbart på kortsiktiga förändringar i rapporterad organisk trafik.
Bestäm före lanseringen vilka fel som utlöser beslut: exempelvis omfattande serverfel, blockerad publik webbplats eller obrukbart köpflöde. Ange vem som beslutar och hur lång felsökning som är acceptabel för respektive funktion. Skriv inte bara att ni kan återställa. Dokumentera kommandon eller leverantörssteg, ansvar och förväntad kontroll efter återställningen.
Testa att säkerhetskopian kan återläsas i en separat miljö. Vid handel eller löpande publicering måste ni också hantera data som skapats efter flytten. En återställning av databasen kan annars förlora beställningar eller förfrågningar. Utse därför någon som ansvarar för databevarande och avstämning innan äldre versioner läggs tillbaka.
Efter en rollback ska DNS, redirects, indexeringsdirektiv och mätning kontrolleras igen. Undvik upprepade byten mellan strukturer utan en stabil plan. Om ni i stället rättar framåt ska varje korrigering omtestas mot samma acceptanskriterier. Avsluta migreringen först när kritiska fel är stängda, bevakningen har en ägare och kvarvarande förbättringar har flyttats till en tydligt prioriterad arbetslista.
Vill ni ha hjälp att prioritera? Vår SEO-byrå kopplar sökmotoroptimering till er affär.