Sitemigrering som skyddar trafik, ranking och förfrågningar

Vad är en sitemigrering?

En sitemigrering är en förändring som påverkar hur webbplatsens innehåll, adresser eller tekniska plattform presenteras för användare och sökmotorer. Det kan vara ett byte från WordPress till ett annat CMS, en ny design med nya sidmallar, en övergång från http till https, en sammanslagning av två webbplatser, ett domänbyte eller en större omstrukturering av URL:er. Även ett projekt som internt kallas ”bara en redesign” kan vara en SEO-migrering om navigation, rubriker, innehåll eller interna länkar förändras.

Riskerna uppstår när den nya webbplatsen lanseras utan en komplett bild av vad den gamla redan har byggt upp. Gamla sidor kan ha länkar, ranking, historik och konverteringar som inte syns i designskissen. Om de tas bort, får nya adresser utan redirects eller ersätts med tunnare innehåll kan Google behöva börja om med sin förståelse. Därför behandlar vi sitemigrering som ett gemensamt projekt för SEO, innehåll, design, utveckling och analys.

SEO ska in före designen är låst

Det mest kostnadseffektiva är att involvera SEO tidigt. Då kan vi kartlägga vilka sidor som driver organisk trafik, vilka sökintentioner de möter och vilka delar som måste bevaras. Informationen påverkar navigation, sidtyper och innehållsplan. Om arbetet börjar veckan före lansering återstår ofta bara skadebegränsning: en redirect-lista skapas under tidspress, gamla texter saknas och viktiga mallfunktioner är redan beslutade.

Tidig planering betyder inte att den gamla webbplatsen måste kopieras. Tvärtom är migreringen ett bra tillfälle att slå samman överlappande innehåll, förbättra svaga sidor och skapa en tydligare struktur. Skillnaden är att besluten fattas med data. En sida tas bort för att den saknar värde och har en genomtänkt efterföljare, inte för att den råkade glömmas bort i det nya webbprojektet.

URL-inventering: grunden för en säker migrering

Vi börjar med att samla gamla URL:er från flera källor. En crawl visar sidor som går att nå via interna länkar. Sitemap visar vad webbplatsen själv har deklarerat. Google Search Console och analysverktyg visar sidor som faktiskt får visningar, klick och besök. Backlinkdata kan identifiera adresser med externa länkar. Serverloggar och gamla exportfiler kan komplettera bilden. Ingen enskild källa är fullständig, därför behöver de kombineras och dedupliceras.

Varje URL klassificeras efter sidtyp, trafik, konverteringar, länkar och framtida destination. Vi markerar om sidan ska behållas, förbättras, slås samman, tas bort eller omdirigeras. Inventeringen gör det även möjligt att upptäcka gamla tekniska problem som inte bör följa med, exempelvis flera indexerbara varianter av samma sida eller redirect-kedjor från tidigare lanseringar.

Underlag	Vad det visar	Hur det används
Crawl och sitemap	Befintlig struktur, länkar och statuskoder	Bas för URL-lista och tekniska avvikelser
Search Console	Organiska klick, visningar och sökfrågor	Identifierar SEO-värdefulla landningssidor
Analys och konverteringar	Besökarnas beteende och affärsvärde	Skyddar sidor och flöden som skapar förfrågningar
Externa länkar	Adresser med auktoritet och hänvisningstrafik	Prioriterar relevanta permanenta redirects

Redirect mapping sida för sida

En redirect-karta kopplar varje gammal värdefull URL till den mest relevanta nya adressen. Redirecten ska vara permanent, normalt 301, och leda direkt till slutdestinationen. Om en gammal sida om teknisk SEO ersätts av en ny sida med samma ämne är kopplingen enkel. Om flera svaga sidor slås samman ska alla leda till den nya heltäckande sidan. Om innehållet saknar en relevant efterföljare kan en 404 eller 410 ibland vara ärligare än att skicka allt till startsidan.

Massredirects till startsidan skapar en dålig upplevelse och kan behandlas som soft 404. Besökaren klickade på en länk med ett specifikt löfte och ska komma så nära samma svar som möjligt. Vi undviker också kedjor där gammal URL går till en mellanadress som i sin tur går vidare. Direkta regler är snabbare, lättare att felsöka och minskar risken för att en gammal länk tappar signaler i flera steg.

Stagingmiljön ska vara testbar men inte indexerbar

Den nya webbplatsen byggs normalt i en stagingmiljö. Den behöver gå att crawla av projektets verktyg men ska inte hamna i Googles index. Lösenordsskydd är ofta säkrare än att enbart lägga noindex, eftersom ett noindex-direktiv kan glömmas kvar vid lansering. Om staging måste vara offentligt kontrollerar vi robots, autentisering och canonical noggrant.

På staging granskar vi navigation, sidmallar, interna länkar, metadata, rubrikhierarki, bilder, formulär och strukturerad data. Vi jämför även innehållet med den gamla webbplatsen. Det räcker inte att URL:en finns; viktiga avsnitt, frågor och bevis behöver följa med eller förbättras. Det gäller särskilt sidor som redan rankar på kommersiella sökfraser.

Canonical, hreflang och indexeringssignaler

Canonical-taggen ska peka på den föredragna indexerbara versionen av sidan. Under en migrering är det vanligt med fel där nya sidor fortfarande pekar mot staging, gamla domänen eller en generell startsida. Vi kontrollerar canonicals i källkoden och säkerställer att de överensstämmer med interna länkar, sitemap och redirects. Motstridiga signaler gör det svårare för Google att förstå vilken URL som ska visas.

För flerspråkiga webbplatser behöver hreflang bevaras och uppdateras med nya adresser. Varje språkversion ska ha korrekta ömsesidiga referenser och en fungerande självreferens. Vi granskar även robots-direktiv, paginering, parameterhantering och eventuella filter. Inget globalt noindex får följa med från staging, och viktiga resurser ska inte blockeras av robots.txt.

Schema och strukturerad data efter flytten

Organization, LocalBusiness, Service, Article, FAQPage och BreadcrumbList är exempel på schema som kan finnas på den gamla webbplatsen eller behöva byggas in i den nya. Vid migrering uppdaterar vi URL:er, logotyp, kontaktuppgifter, sidnamn och relationer. Schema ska spegla det synliga innehållet och inte innehålla frågor, recensioner eller erbjudanden som användaren inte kan se.

Vi testar strukturerad data på flera sidtyper, inte bara startsidan. Ett fel i en gemensam mall kan påverka hundratals URL:er. Samtidigt kontrollerar vi att brödsmulor i gränssnittet motsvarar BreadcrumbList och att informationen är konsekvent med webbplatsens faktiska struktur.

Pre-launch: kontroll innan DNS eller publicering

Lanseringsdagen: rätt ordning minskar risken

Vid lansering tas blockeringen av den skarpa miljön bort, redirects aktiveras och rätt canonical, robots.txt och sitemap publiceras. DNS och cache kan göra att olika besökare ser olika versioner en kort tid, därför testar vi både gamla och nya adresser från flera perspektiv. Kritiska flöden som kontaktformulär, köp, meny och inloggning får högsta prioritet.

Vi kör en ny crawl så snart webbplatsen är tillgänglig. Då upptäcks skillnader mellan staging och produktion, exempelvis filer som saknas, regler som inte följde med eller interna länkar som pekar mot testdomänen. Den nya sitemap skickas i Search Console och relevanta domäninställningar kontrolleras. Vid ett domänbyte används även de verktyg som sökmotorerna tillhandahåller när de är tillämpliga.

Post-launch: de första dagarna och veckorna

En migrering är inte klar när den nya designen syns. Under de första dagarna följer vi 404-fel, serverfel, indexering, crawlstatistik och konverteringar. Gamla topplandningssidor kontrolleras särskilt. Om en viktig URL tappar klick behöver vi avgöra om redirecten, innehållet, internlänkarna eller renderingen har förändrats. Snabb diagnos är enklare när baslinjen dokumenterades före lansering.

Under följande veckor jämförs organiska klick och visningar med historiska nivåer, med hänsyn till säsong och andra samtidiga förändringar. Google behöver tid att crawla och bearbeta nya adresser, så mindre rörelser är inte automatiskt ett problem. Däremot kräver ihållande tapp på prioriterade sidor en konkret undersökning. Vi uppdaterar redirect-kartan när nya gamla URL:er dyker upp och ser till att interna länkar alltid pekar direkt på de nya adresserna.

Vanliga orsaker till trafikfall efter en ny hemsida

De vanligaste problemen är inte mystiska algoritmförändringar utan genomförandefel. Värdefulla sidor har tagits bort, redirects saknas, texten har kortats kraftigt, title och H1 har blivit generiska eller navigationen har gjort sidorna svårare att nå. Andra orsaker är noindex från staging, felaktiga canonicals, JavaScript-innehåll som inte renderas stabilt, långsammare laddning eller spårning som slutat registrera trafik.

En annan risk är att för många saker ändras samtidigt. Ny domän, nytt CMS, ny design, ny struktur och helt nytt innehåll gör det svårare att isolera orsaken om resultatet försämras. Ibland är en stor förändring nödvändig, men då blir dokumentation och kontrollpunkter ännu viktigare. När det går kan projektet delas i faser.

Symptom	Trolig kontroll	Första åtgärd
Många gamla URL:er ger 404	Redirect-regler och serverkonfiguration	Matcha mot inventering och skapa relevanta 301
Nya sidor indexeras inte	Noindex, canonical, robots och interna länkar	Ta bort motstridiga signaler och stärk upptäckbarheten
Ranking tappas på en tjänst	Innehållsparitet, title, H1 och sökintention	Jämför gammal och ny landningssida
Trafik ser låg ut överallt	Analytics och samtyckeshantering	Verifiera mätningen innan SEO-slutsats dras

Vad kostar en SEO-säker sitemigrering?

Omfattningen beror på antal URL:er, sidtyper, språk, domäner, plattformar och hur mycket som förändras. En mindre företagswebb med tydlig struktur kan kräva en fokuserad inventering, redirect-karta och två kvalitetskontroller. En stor e-handel med filter, produktvarianter och flera marknader kräver mer data, testning och utvecklingssamordning. Kostnaden påverkas också av om vi enbart granskar eller ansvarar för innehåll, implementation och uppföljning.

Det rimliga är att väga migreringskostnaden mot värdet som redan finns. Om organisk trafik genererar leads eller försäljning kan ett onödigt tapp snabbt bli dyrare än planeringen. Vi avgränsar arbetet utifrån risk och affärspåverkan, och ser till att leveransen innehåller konkreta filer, tester och ansvar – inte bara en allmän rekommendationsrapport.