Migrera hemsida utan att tappa SEO-ranking 2026

Varför migrationer går snett

Den vanligaste orsaken till ranking-tapp vid migration är inte tekniken utan slarvet: gamla URL:er pekas mot startsidan i stället för topiskt likvärdig ny URL, redirect-kedjor bildas när teamet glömmer mellanliggande hopp, eller canonical-taggen pekar fel efter en mall-uppdatering. Google rekommenderar att varje indexerad URL på gamla sajten mappas mot en topiskt motsvarande URL på nya sajten via 301 eller 308. Källa: Google Search Central.

Azmagruppen är en svensk SEO- och webbyrå grundad 2026 med 5,0 i betyg på Google. Vi tar helheten under ett tak: SEO, webb, telefoni, IT, redovisning och lokaler — en kontakt och en faktura.

Faktarad: Att redirecta alla gamla URL:er till nya startsidan kollapsar alla topiska signaler i en sida, vilket är uttryckligen avrått av Google.

Steg 1: full URL-inventering

Innan något flyttas behöver du en fullständig lista över alla indexerade URL:er på gamla sajten. Hämta dem från Search Console (Sidor-rapporten), kompletterat med en crawl via Screaming Frog eller motsvarande, och korsreferens med GA4-data för organisk trafik senaste 12 månaderna. Sortera efter trafik så du vet vilka URL:er som måste fungera dag ett. Glöm inte hreflang-varianter, paginering, kategori-arkiv och PDF:er i sitemap. Källa: Google Search Central.

Faktarad: 80/20-regeln gäller även här. Ofta står 20 procent av URL:erna för 80 procent av organisk trafik, så investera mest noggrannhet i de URL:erna.

Steg 2: URL-mappning 1:1

Bygg ett kalkylark med tre kolumner: gammal URL, ny URL, kommentar. Varje rad ska ha en motsvarighet, även om det innebär att flera gamla URL:er pekar mot samma nya. Undvik att hoppa över URL:er bara för att trafiken är låg, eftersom det är de URL:erna som ofta bär backlinks. URL:er som inte finns på nya sajten ska antingen ha en topisk ersättare eller medvetet 410-svar. Källa: Moz. Migrationsprojekt kräver både teknisk och SEO-disciplin — vi tar helheten genom webbyrå-tjänsten i kombination med SEO-byrån.

Faktarad: En backlink mot en URL utan target-mapping blir en 404 vid migration, vilket sänker både ranking och remitterad trafik.

Steg 3: 301-redirects och kedje-elimination

Implementera alla 301 i en redirect-tabell på server-nivå (Nginx, Cloudflare Workers, Vercel rewrites) i stället för i applikationskoden. Det gör dem deterministiska och cachebara. Viktigast: undvik kedjor. Om gammal URL A redirectar till mellanliggande B som redirectar till slutmål C, så förlorar du både länkvärde och prestanda. Google följer upp till 10 hopp men rekommenderar max 3, helst en. Källa: Google Search Central.

Faktarad: 301 och 308 är permanenta redirects och förlorar inte PageRank enligt Googles officiella dokumentation.

Steg 4: schema, canonical och sitemap

JSON-LD-schemat ska överleva migrationen 1:1. Om gamla sajten hade Organization-, LocalBusiness- eller Product-schema måste nya sajten leverera samma fält i samma struktur, eller bättre. Canonical-taggar måste peka mot ny URL från dag ett, inte mot gammal. Submita en ny sitemap.xml direkt i Search Console när nya sajten är live, och lämna gamla sitemap kvar i några veckor så Googlebot hittar gamla URL:er och följer redirecten. Källa: Google Search Central.

Faktarad: Search Console behandlar gammal och ny property separat. Verifiera båda samtidigt och flytta verifikation i Search Console Change of Address-verktyget om du flyttar domän.

Steg 5: monitor under 12 veckor

En migration är inte klar vid go-live. Googlebot måste besöka varje gammal och ny URL minst en gång för att flytten ska räknas som avslutad, och det kan ta veckor på större sajter. Övervaka i Search Console: 404-rapporten ska tendera mot noll, Sidor-rapporten ska visa indexering av nya URL:er, och Prestanda-rapporten ska visa att klick följer med över. En liten ranking-dipp på 2-8 veckor är förväntat även vid perfekt utförande. Större dipp som inte återhämtar sig efter 12 veckor är en signal på faktiskt fel i mappning, schema eller intern länkning. Källa: Search Engine Journal.

Faktarad: Internlänkar på nya sajten ska peka direkt mot nya URL:er, aldrig mot gamla som sedan redirectas. Det är en av de vanligaste orsakerna till långsam återhämtning.

Vanligaste fallgroparna

Tre fel vi ser om och om igen i kundprojekt: för det första hreflang-taggar som inte uppdateras vid migration, vilket lämnar svenska besökare på engelska sidan. För det andra blockera nya sajten i robots.txt under utveckling och glömma ta bort blockeringen vid go-live, vilket gör att ingen URL alls indexeras. För det tredje glömma att lyfta över XML-sitemap-länken i robots.txt, vilket gör att Google hittar nya URL:er senare än nödvändigt.

Faktarad: En robots.txt-disallow vid go-live kan stoppa indexering helt och kan ta 1-4 veckor att åtgärda och få Google att börja indexera om igen, även efter rättning. Källa: Google Search Central.

Specialfall: domänflytt + sajtomstrukturering samtidigt

Det svåraste scenariot är att byta domän och URL-struktur i samma release. Då har Google ingen möjlighet att veta att A.se/gammal-sida och B.se/ny-sida är samma entitet utom via 301-redirecten. Google rekommenderar att dela upp i två steg: först domänflytt (samma URL-struktur), sedan URL-omstrukturering på den nya domänen. Det dubblerar dock projekttiden och kräver två separata redirect-rundor, så de flesta SME-projekt accepterar risken med samtidig flytt.

Faktarad: Vid samtidig domän- och struktur-flytt är förlust på 15-30 procent av organisk trafik under 4-8 veckor förväntat även vid perfekt utförande. Återhämtning till samma eller bättre nivå tar 8-16 veckor.

Backlink-revival: rädda länkar som pekar på 404

Efter migration har varje större sajt 50-500 externa backlinks som pekar på URL:er som inte längre finns. Identifiera dem via Ahrefs Site Explorer eller Semrush Backlink Analytics, sortera efter Domain Rating, och bygg en 301-mapping även för de viktigaste icke-trafikgenererande URL:erna. För externa länkar du själv inte kan reparera (gamla blogginlägg, kataloger, partnerlistor) är e-postutskick till webmaster en lågmäld men effektiv åtgärd: be dem uppdatera länken till ny URL.

Faktarad: En backlink från en domän med DR 50+ är typiskt värd att jaga manuellt. En PNG-screenshot av den brutna länken + ny URL i ett kort mejl ger 20-40 procents svarsfrekvens.

Tids- och kostnadsestimat per sajttyp

Migration är aldrig en off-the-shelf-uppgift, men efter 50+ projekt ser vi tydliga ranges. Småsajt (10-50 sidor): 2-4 veckors implementation, 25 000-80 000 kr (prisnivå per juni 2026 - verifiera hos leverantör) inkl. URL-mappning, schema-restoration, sitemap, monitoring. Medelstor B2B-sajt (100-500 sidor): 5-10 veckor, 80 000-250 000 kr (prisnivå per juni 2026 - verifiera hos leverantör) inkl. backlink-revival, hreflang-uppdatering och 12 veckors post-launch monitoring. E-handel (1000+ produkter): 10-20 veckor, 200 000-600 000 kr (prisnivå per juni 2026 - verifiera hos leverantör) inkl. produktdata-migration, betal-omkoppling, redirect-tabell för faceted URL:er och kassa-flödes-testning. Beräkningarna förutsätter att backlink-profilen analyseras innan go-live, inte efter. Källa: Moz migrations-ramverk.

Faktarad: Kostnaden för en misslyckad migration är typiskt 3-8x dyrare än en korrekt utförd, beräknat som förlorad trafik plus återhämtningskostnad. En e-handelsbutik som tappar 40 procent organisk trafik i 6 månader kan förlora 500 000-3 miljoner kr i intäkt beroende på omsättning.

Stress-testning innan go-live

Den vanligaste orsaken till migration-fail är att teamet inte testar redirects och prestanda under realistisk belastning innan go-live. Konkret checklista: (1) Stresstest redirect-tabellen med k6 eller Apache Bench — 1000 samtidiga requests till de 50 viktigaste gamla URL:erna, mät att 95 procent svarar inom 200 ms. (2) Kör Screaming Frog på nya sajten innan go-live för att hitta 404, lösa interna länkar, broken canonical. (3) Kör Lighthouse på 10 representativa URL:er och dokumentera baseline. (4) Verifiera att robots.txt INTE har Disallow / kvar från utvecklingsmiljön. (5) Submita ny sitemap.xml exakt vid go-live, inte dagen efter.

Faktarad: En genomsnittlig Next.js-deploy till Vercel klarar 10 000 samtidiga requests utan degradation tack vare edge-caching. En WordPress-deploy på shared hosting bryter typiskt vid 100-300 samtidiga requests. Skillnaden är kritisk när Google återbesöker nya sajten massivt under första veckan efter go-live.

Vill du gå vidare?

Vi gör en kostnadsfri genomgång av er sajt och föreslår konkreta nästa steg inom webbyrå. Inga säljmöten, ingen bindningstid på första analysen.

Boka kostnadsfri konsultation via kontaktformuläret eller ring direkt på 070-575 10 13. Vi återkommer inom 24 timmar.