Att migrera en e-handel innebär betydligt fler beroenden än en vanlig webbplatsflytt. Förutom URL:er och innehåll behöver ni skydda produkt- och kategoristruktur, varianter, lager, prisdata, feeds, checkout, betalning, analys och integrationer mot ERP, PIM eller CRM.
Den här guiden är en praktisk SEO- och lanseringschecklista för plattformsbyte 2026. Målet är att minska undvikbara trafik- och konverteringsproblem när ni byter exempelvis CMS, e-handelsmotor, URL-struktur eller teknisk arkitektur.
För generell webbplatsmigrering finns även vår SEO-checklista för webbplatsmigrering. För e-handelsstrategin som helhet, se starta e-handel 2026.
Varför e-handelsmigrering är extra känslig
En e-handel kan innehålla tusentals URL:er och automatiskt genererade kombinationer. Samtidigt är flera system beroende av samma produktdata.
En migrering kan påverka:
- produkt- och kategori-URL:er,
- varianter,
- filter och facetter,
- internlänkar och breadcrumbs,
- produktfeeds,
- lager och pris,
- kundkonton och orderhistorik,
- checkout och betalning,
- analytics och e-commerce events,
- ERP/PIM/CRM-integrationer.
Därför bör SEO, teknik, produktdata, marketing och operations planera flytten tillsammans.
1. Bestäm exakt vad som ska förändras
Dokumentera om migreringen innebär:
- ny plattform men samma domän,
- ny URL-struktur,
- ny kategoristruktur,
- ny design,
- ny checkout,
- ny domän,
- ny PIM/ERP-arkitektur,
- flera förändringar samtidigt.
Ju fler stora förändringar som sker samtidigt, desto svårare blir felsökningen. Behåll sådant som redan fungerar när det inte finns ett tydligt affärs- eller teknikskäl att ändra det.
2. Exportera alla befintliga URL:er
Skapa ett komplett nuläge före flytten.
Inventera minst:
- kategorier,
- produkter,
- varianter med egna URL:er,
- varumärkessidor,
- filter-/facett-URL:er,
- kampanj- och landningssidor,
- guider och köpguider,
- blogg/innehåll,
- PDF:er och viktiga dokument,
- nuvarande redirects.
Kombinera crawl med sitemap, Search Console, analytics och plattformsdata så att sidor som inte är väl internlänkade inte missas.
3. Markera vilka URL:er som faktiskt skapar värde
Prioritera sidor med:
- organiska klick eller impressions,
- försäljning eller assisterad försäljning,
- externa länkar,
- hög intern betydelse,
- viktiga produkt- eller kategorisökningar.
De ska granskas manuellt i URL-mappningen.
4. Behåll produkt- och kategori-URL:er när det går
Ett plattformsbyte kräver inte automatiskt nya adresser. Om en kategori eller produkt har samma sökintention och samma funktion kan ni ofta vinna på att behålla URL:en.
Det minskar behovet av redirects och risken för brutna interna eller externa länkar.
5. Bygg en URL-mappning före utvecklingen är klar
För varje gammal URL ska ett beslut finnas.
| Gammal sida | Ny hantering |
|---|---|
| Produkt finns kvar | Behåll URL eller 301 till motsvarande ny produkt |
| Produkt ersatt av ny modell | Bedöm relevant 301 om ersättaren verkligen matchar |
| Produkt utgången men kategorin relevant | Bedöm om produktsidan ska leva vidare med alternativ eller tas bort |
| Kategori finns kvar | Behåll eller 301 1:1 |
| Kategorier slås ihop | 301 till mest relevant konsoliderad kategori |
| Inget relevant alternativ | 404/410 kan vara bättre än irrelevant redirect |
Redirecta inte tusentals gamla produkter till startsidan. Det hjälper varken användaren eller sökintentionen.
6. Planera utgångna produkter
Utgångna produkter behöver en konsekvent strategi.
Alternativ kan vara:
- behåll sidan om produkten fortfarande har sökintresse och visa att den utgått,
- visa relevanta ersättare,
- 301 till en verklig efterföljare när relationen är tydlig,
- 404/410 om det inte finns relevant ersättning.
Ta inte bort stora mängder produkt-URL:er enbart för att sortimentet byter plattform.
7. Migrera varianter med samma logik som katalogen använder
Olika plattformar hanterar färg, storlek, modell och SKU-varianter på olika sätt.
Bestäm:
- om varje variant ska ha egen URL,
- vilken variant som är canonical,
- hur lager och pris visas,
- hur variantval påverkar indexerbarhet,
- hur gammal variant-URL mappas.
Felaktig variantlogik kan skapa stora mängder duplicerade sidor.
8. Kategoristrukturen ska styras av kund och sökintention
Plattformsbyte är ett tillfälle att förbättra en dålig kategoristruktur – men gör inte förändringen utan data.
Bedöm:
- hur kunder navigerar,
- vilka kategorier som redan rankar,
- intern sökdata,
- produktrelationer,
- filtreringsbehov,
- kommersiella sökintentioner.
En ny teknisk taxonomi behöver inte vara samma sak som den publika SEO-strukturen.
9. Breadcrumbs ska uppdateras konsekvent
Breadcrumbs hjälper användaren förstå var produkten ligger och kan stödja internlänkningen.
Efter migrering ska de:
- följa den nya informationsarkitekturen,
- länka till giltiga kategorier,
- inte gå genom redirects,
- ha korrekt BreadcrumbList-markup där det används.
10. Facetter och filter måste ha en indexeringsstrategi
Filter kan skapa miljontals möjliga URL-kombinationer. Bestäm innan lansering vilka som ska vara:
- indexerbara SEO-landningssidor,
- crawlbara men canonicaliserade,
- icke-indexerbara,
- endast klientbaserad filterfunktion.
Det finns ingen universell regel för alla butiker. Beslutet ska bygga på efterfrågan, duplicering och teknisk implementation.
11. Kontrollera canonical på produkt-, kategori- och filtersidor
Vanliga migrationsfel är:
- canonical till staging,
- alla filter canonical till fel kategori,
- produktvarianter canonical till fel SKU,
- http/https eller www/non-www blandas,
- canonical ligger kvar på gamla domänen.
Crawla därför den nya sajten och exportera canonical före lansering.
12. Pagination, ”load more” och infinite scroll
Om kategorier använder lazy loading eller infinite scroll måste sökmotorer fortfarande kunna upptäcka produkterna via crawlbara länkar eller annan robust serverrenderad struktur.
Testa att:
- produkter går att nå utan att endast förlita sig på användarscroll,
- pagination inte skapar felaktig canonical,
- viktiga produkter inte blir orphan pages.
13. Behåll produktinnehåll som redan fungerar
Vid migrering ersätts ibland bra produktdata av korta standardtexter. Jämför före och efter:
- produktnamn,
- beskrivning,
- specifikationer,
- användningsområden,
- FAQ,
- bilder,
- ALT-text,
- internlänkar,
- dokument.
Förbättra gärna innehållet, men radera inte informationsvärde omotiverat.
14. Migrera kategoritexter och köpguider
Kategorisidor med stark organisk trafik bör behålla relevant innehåll, internlänkar och kontext.
Köpguider kan dessutom länka till:
- huvudkategorier,
- underkategorier,
- relevanta produktfamiljer,
- jämförelsesidor.
Se till att dessa länkar uppdateras direkt till nya URL:er.
15. Produktrecensioner och ratings
Om recensioner ska migreras, kontrollera:
- att ni har rätt att överföra och publicera datan,
- att recensioner kopplas till rätt produkter,
- att inga dubbletter skapas,
- att datum, källa och innehåll bevaras korrekt,
- att structured data motsvarar synligt och verkligt innehåll.
Hitta inte på betyg eller fyll gamla produkter med syntetiska recensioner.
16. Bilder och media
Produktbilder kan stå för stor del av sidvikten och söktrafiken.
Kontrollera:
- att originalfiler finns,
- att bilder mappas till rätt produkt,
- att nya URL:er inte ger 404,
- att dimensioner och format är rimliga,
- att ALT-text följer med där den är relevant,
- att CDN fungerar i produktion.
17. Product structured data
Om ni använder Product-markup ska datan stämma med det användaren ser.
Kontrollera exempelvis:
- namn,
- pris,
- valuta,
- lagerstatus,
- SKU/identifierare,
- ratings/reviews där de faktiskt finns.
Felaktig eller motsägelsefull markup bör rättas före lansering.
18. Merchant Center och produktfeeds
Plattformsbytet kan ändra produkt-URL:er, bild-URL:er, pris, lager och feedstruktur. Planera därför feedmigreringen samtidigt.
Kontrollera:
- produkt-ID:n,
- landing page URL,
- bildlänkar,
- pris och kampanjpris,
- availability,
- GTIN/MPN där relevant,
- fraktinställningar.
För mer, se Google Shopping 2026.
19. Behåll stabila produkt-ID:n där möjligt
Interna produkt-ID:n, SKU och feed-ID:n används ofta av flera system. Att byta dem utan behov kan skapa problem för:
- annonsering,
- retargeting,
- ERP-synk,
- rapportering,
- historiska produktdata.
Definiera en identitetsstrategi innan migreringen börjar.
20. ERP, PIM och CRM – dokumentera source of truth
För varje datatyp ska det vara tydligt vilket system som äger sanningen.
| Data | Möjlig source of truth |
|---|---|
| Pris | ERP/prismotor |
| Lager | ERP/WMS |
| Produkttext/specifikation | PIM |
| Kundrelation | CRM |
| Webbmerchandising | E-handelsplattform |
Den exakta arkitekturen varierar, men dubbla konkurrerande datakällor skapar snabbt fel.
21. Testa lagersynk och pris före lansering
Skapa testfall för:
- produkt i lager,
- produkt slut i lager,
- kampanjpris,
- variant med annat pris,
- kundunikt pris där B2B används,
- fördröjd eller misslyckad integration.
Definiera vad webbplatsen visar när källsystemet inte svarar.
22. Checkout får inte behandlas som ett separat projekt
Migreringen är inte lyckad om organisk trafik bevaras men checkout bryts.
Testa hela köpresan:
- produkt → varukorg,
- rabatt/kampanj,
- adress,
- frakt,
- betalning,
- orderbekräftelse,
- order till ERP/OMS,
- e-post eller annan kvittens.
23. Betalmetoder
Verifiera varje aktiv betalmetod i produktion eller avtalad testmiljö. Kontrollera:
- success,
- failed payment,
- avbrutet köp,
- dubbelklick/idempotens där systemet stödjer det,
- refund/returprocess,
- orderstatus.
Betalningskrav varierar mellan leverantörer och marknader; följ respektive providers implementation och avtal.
24. Frakt, moms och marknader
Kontrollera att migreringen inte ändrar affärsregler av misstag.
Testa de marknader ni faktiskt säljer till och kontrollera:
- fraktalternativ,
- gränser/fri frakt,
- valuta,
- prisvisning,
- tillämpliga skatteinställningar,
- leveransområden.
25. Kundkonton och orderhistorik
Om konton migreras behöver ni bestämma:
- hur användar-ID mappas,
- om lösenord kan flyttas säkert eller behöver återställas,
- vilken orderhistorik som ska visas,
- hur adresser och preferenser behandlas,
- vilka dataskydds- och avtalskrav som gäller.
Planera kommunikationen till kunder om de behöver skapa nytt lösenord.
26. GA4 och e-commerce events
Ny plattform kan ändra datalagret eller eventstrukturen. Testa därför e-commerce events från början.
Exempel:
- view_item,
- add_to_cart,
- begin_checkout,
- purchase,
- refund där det används.
Kontrollera parametrar som produkt-ID, pris, valuta och order-ID så att rapporteringen inte bryts.
27. Tag Manager, annonsering och consent
Inventera befintliga taggar före flytt:
- Google Ads,
- Meta,
- TikTok,
- affiliate,
- heatmaps/UX-verktyg,
- consent platform.
Testa att taggar respekterar den consent-lösning och de regler som gäller verksamheten.
28. Staging ska vara skyddad från indexering
Staging bör inte kunna konkurrera med produktionen i sökresultatet.
Använd lämplig accesskontroll och verifiera noindex/robots-konfiguration. Före produktionslansering ska ni säkerställa att blockerande inställningar inte följer med.
29. Crawl staging före lansering
Gör en full crawl och kontrollera:
- 404/5xx,
- redirects,
- canonical,
- noindex,
- metadata,
- internlänkar,
- orphan pages,
- facetter,
- pagination,
- sitemap.
Jämför särskilt gamla och nya topplandningssidor.
30. Skapa ny XML-sitemap
Sitemap ska innehålla de indexerbara produkt-, kategori- och contentsidor ni vill signalera.
Exkludera exempelvis:
- redirectade URL:er,
- 404,
- noindex,
- facettkombinationer som inte ska indexeras.
31. Ha en rollback-plan
Bestäm före lansering vilka fel som ska trigga rollback eller stopp.
Kritiska exempel:
- checkout fungerar inte,
- stora delar av katalogen returnerar fel,
- pris/lager är felaktigt,
- redirectregler saknas,
- produktionssajten är noindex.
Backup och ansvariga personer ska vara definierade innan cutover.
32. Crawl produktion direkt efter lansering
Stagingtest räcker inte. Kör om crawl på riktiga domänen och verifiera:
- statuskoder,
- redirects,
- canonical,
- robots/noindex,
- internlänkar,
- sitemap.
33. Testa ett urval verkliga köp
Genomför verklighetsnära testorder för:
- olika betalmetoder,
- olika fraktalternativ,
- mobil/desktop,
- kampanjkod,
- olika produktvarianter,
- olika marknader där relevant.
Verifiera hela vägen till orderhanteringen.
34. Följ Search Console på sidtyp
Efter lansering bör ni följa produkt- och kategorigrupper separat.
Bevaka:
- indexerade sidor,
- 404/soft 404,
- impressions och klick,
- förändringar på viktigaste kategorierna,
- sitemap-status.
Total organisk trafik kan dölja problem på de mest lönsamma kategorierna.
35. Följ kommersiella KPI:er parallellt med SEO
En tekniskt korrekt migration kan ändå skapa sämre kundupplevelse.
Följ exempelvis:
- konverteringsgrad,
- add-to-cart-rate,
- checkout completion,
- intäkt eller marginal,
- fel i betalning/order,
- intern sök utan resultat.
36. B2B e-handel kräver extra datakontroller
Om ni har företagskunder behöver migreringen även testa:
- kundunika priser,
- kundsortiment,
- roller/behörighet,
- offertflöden,
- orderreferenser,
- ERP-kundnummer.
Se B2B e-handel 2026 för en full kravlista.
Lanseringschecklista för e-handel
- Gammal katalog crawlad och exporterad.
- SEO-kritiska produkter/kategorier markerade.
- URL-mappning klar.
- 301-regler implementerade.
- Utgångna produkter hanterade.
- Varianter och canonical verifierade.
- Facettstrategi implementerad.
- Breadcrumbs och internlänkar uppdaterade.
- Product/Breadcrumb structured data testad.
- Bilder och media verifierade.
- Feed/Merchant Center kontrollerat.
- Pris och lager testat.
- ERP/PIM/CRM testat.
- Checkout och betalning testad.
- GA4/GTM/e-commerce events testade.
- Consent/taggar testade.
- Stagingblockering borttagen från produktion.
- Sitemap uppdaterad.
- Produktion crawlad.
- Search Console och affärs-KPI bevakas.
Vanliga migrationsmisstag
- Alla gamla produkter redirectas till startsidan.
- Kategorier får helt nya URL:er utan skäl.
- Facetter börjar indexeras okontrollerat.
- Produktvarianter skapar dubbletter.
- Feed-ID:n byts och annonseringshistorik bryts.
- Pris eller lager visar gammal data.
- Analytics purchase-event tappar order-ID eller värde.
- Checkout testas först efter lansering.
- Staging-noindex följer med till produktion.
- Teamet följer bara trafik och missar konverteringsfall.
Vanliga frågor
Tappar en e-handel alltid ranking vid plattformsbyte?
Nej, men stora tekniska och strukturella förändringar innebär risk. En genomtänkt migrering minskar undvikbara problem men kan inte garantera oförändrade rankingar.
Måste alla produkt-URL:er behållas?
Nej. Men produkter med organisk trafik, externa länkar eller fortsatt relevans behöver en tydlig plan. Ändra inte URL enbart för att den nya plattformen föreslår en annan standardstruktur.
Ska utgångna produkter redirectas till kategorin?
Inte automatiskt. Om produkten har en tydlig ersättare kan en relevant redirect vara rimlig. I andra fall kan det vara bättre att behålla en informationssida eller låta URL:en bli 404/410.
Hur länge bör gamla redirects finnas kvar?
Permanenta redirects bör inte tas bort snabbt. Gamla länkar, bokmärken och sökmotorers historik kan fortsätta använda dem långt efter lanseringen.
Vad är viktigast första dygnet efter lansering?
Kontrollera att sajten är indexerbar, redirects fungerar, pris/lager är korrekt, checkout och betalningar fungerar, tracking registrerar rätt och inga kritiska produkt- eller kategorisidor returnerar fel.
Migrera katalog, SEO och affärsflöde tillsammans
Kontakta SveaMedia om ni planerar att byta e-handelsplattform och vill ta fram en migreringsplan som täcker produkter, kategorier, redirects, feeds, integrationer, tracking och konvertering – inte bara själva designflytten.
