La sortie d'une boutique SaaS (catalogue, paiements, abonnements) est traitée dans Quitter Shopify pour une boutique que vous possédez. Cet article va plus loin sur le seul sujet qui fait souvent perdre le chiffre d'affaires organique: le SEO.

Objectif: arriver le jour J avec une table ancienne URL → nouvelle URL complète, des pages qui gardent leur contenu indexable, et un plan de contrôle pour corriger les 404 avant que Google ne les traite comme une disparition du site.

Pourquoi le trafic chute après une migration

• URLs cassées sans 301: le moteur arrive sur une 404 ou une page générique. Le signal de l'ancienne URL s'évapore.
• Structure d'URL réécrite sans mapping: /products/ Nom devient /categorie/produit/ sans ligne dans le fichier de redirections.
• Titres, meta et H1 perdus à l'import: la page existe, mais elle ne ressemble plus à celle qui rankait.
• Contenu aminci: descriptions tronquées, blocs FAQ ou guides non migrés, fiches quasi vides.
• Canoniques et sitemap faux: la nouvelle boutique pointe vers d'anciennes URLs, un domaine de staging, ou oublie la moitié du catalogue.
• Liens internes morts: menus, pieds de page, blocs « associés » et articles de blog pointent encore vers l'ancien schéma.
• Facettes et paramètres: filtres couleur/taille indexés en masse, ou au contraire pages utiles bloquées par robots.txt.
• HTTPS, www, trailing slash: quatre variantes du même produit, des chaînes de redirections, ou un mélange http/https.

Une baisse courte de crawl et de positions est fréquente même quand le travail est correctement fait. Une chute nette et durable pointe presque toujours vers des 301 manquants, des soft 404, ou du contenu perdu.

1. Inventorier les URLs qui portent le trafic

Avant de toucher à la nouvelle boutique, exportez la réalité, pas l'intuition:

• Search Console: pages avec impressions et clics (12 à 16 mois si possible)
• Analytics: sessions organiques par URL, pas seulement par page vue « jolie »
• Backlinks connus (outils ou Search Console Liens) vers fiches et articles
• Sitemap XML actuel et liste des redirections déjà en place

Classez: top trafic, pages à backlinks, collections stratégiques, blog qui convertit. Ces listes deviennent la priorité absolue du mapping. Une boutique de 8 000 SKU n'a pas 8 000 URLs critiques le premier jour. Elle en a souvent quelques centaines qui font l'essentiel.

2. Figer les règles d'URL avant l'import massif

Décidez une fois pour toutes: préfixes (/produit/, /categorie/), langue dans l'URL ou non, trailing slash, gestion des accents et des caractères spéciaux. Documentez-le.

Si la destination impose un schéma différent de Shopify, PrestaShop ou WooCommerce, acceptez-le et mappez. Ne « corrigez » pas les slugs au feeling pendant l'import: chaque changement crée une ligne de redirection obligatoire.

3. Construire la table de redirections 301

Fichier (CSV ou table) avec au minimum: ancienne URL complète, nouvelle URL complète, type de page, priorité (trafic / backlink / autre). Couvrez:

• Fiches produit
• Collections / catégories
• Pages institutionnelles et landings
• Articles de blog et guides
• Anciennes redirections déjà actives (évitez les chaînes: A→B puis B→C, visez A→C)

Règle: redirection 301 permanente, une cible utile (fiche ou catégorie proche), jamais une homepage fourre-tout pour tout le catalogue. Testez le top 50 à 100 URLs Search Console sur un environnement qui sert déjà les 301 (staging avec hosts, ou préprod derrière le bon domaine de test).

4. Préserver le SEO on-page à l'import

Pour chaque URL prioritaire, vérifiez que la nouvelle page conserve:

• Title et meta description (ou équivalents clairement meilleurs, pas vides)
• H1 aligné avec l'intention de la requête
• Corps de fiche: description longue, spécifications, FAQ si elles existaient
• Images avec noms de fichiers raisonnables et attributs alt
• Données structurées produit (offre, disponibilité, prix) si vous en aviez, ou si la nouvelle stack peut les émettre proprement

Un import CSV « prix + image » sans textes SEO est une régression déguisée en migration réussie.

5. Reconstruire le maillage interne

Les 301 sauvent l'entrée depuis Google. Le maillage interne dit au moteur quelles pages comptent encore chez vous.

• Menus et mega-menus sur les nouvelles URLs uniquement
• Fil d'Ariane cohérent avec la nouvelle arborescence
• Blocs produits associés, « souvent achetés ensemble », liens dans le blog
• Pages hub (guides, lookbooks) mises à jour, pas laissées en brouillon

Crawllez la préprod (Screaming Frog, Sitebulb, ou équivalent) et traquez les 404 internes avant le DNS.

6. Technique: canoniques, robots, sitemap, perfs

• Canoniques: chaque fiche pointe vers elle-même sur le domaine final (pas le staging).
• robots.txt: n'interdit pas le catalogue utile. Bloquez les facettes inutiles si c'était déjà votre politique, sans inventer un blocage plus large le jour J.
• Sitemap XML: uniquement des URLs 200 finales, à jour, soumis dans Search Console après bascule.
• Hreflang: si vous avez plusieurs langues, les paires doivent rester cohérentes après migration.
• Perfs et Core Web Vitals: une boutique plus lente peut amplifier une baisse. Ce n'est pas le premier levier, mais ne lancez pas une préprod trois fois plus lourde sans le savoir.

Si la migration change aussi d'hébergeur, alignez l'ordre des opérations avec Changer d'hébergeur sans interruption: parallèle d'abord, DNS ensuite.

7. Contrôle qualité avant cutover

1. Échantillon top trafic: statut 301 ou 200 selon le cas, contenu présent, panier reachable
2. Crawl complet préprod: 404, chaînes, canoniques, titres dupliqués massifs
3. Comparaison titre/H1 sur 30 fiches phares (ancien vs nouveau)
4. Test paiement et emails (hors SEO, mais une boutique « SEO ok » qui ne vend pas ne sert à rien)
5. Plan de rollback: ancienne boutique encore capable de servir ou de rediriger si le cutover échoue

8. Bascule, surveillance, corrections

Le jour J:

• Activez les 301 en production en même temps que le trafic arrive sur la nouvelle stack
• Soumettez le nouveau sitemap, demandez l'indexation des hubs critiques si besoin
• Surveillez Search Console (Couverture / Pages), logs 404, et un tableau des URLs prioritaires
• Corrigez les 404 restantes dans les 48 h, puis chaque semaine pendant 4 à 8 semaines

Gardez l'ancienne plateforme en redirection (ou lecture seule + redirects) assez longtemps pour absorber les oublis. Couper trop tôt, c'est jeter le filet de sécurité.

À quoi ressemble un résultat « normal »

Avec un mapping solide et du contenu préservé:

• Quelques jours à quelques semaines de volatilité de positions (recrawl, redistribution)
• Les URLs prioritaires récupèrent l'essentiel des impressions si les 301 et les contenus sont bons
• Des pages secondaires peuvent mettre plus longtemps, surtout si elles avaient peu de liens

Ce qui n'est pas normal: une disparition large du catalogue dans l'index, des 404 sur le top 50, ou un trafic organique divisé par deux pendant des mois sans plan de correction. Dans ce cas, reprenez le fichier de redirections et le crawl avant de « attendre que ça revienne ».

Erreurs qui rendent la chute durable

• Tout rediriger vers l'accueil
• Utiliser des 302 « le temps de voir » sur des URLs permanentes
• Chaînes A→B→C et boucles
• Changer de domaine et de plateforme le même jour sans double mapping
• Abandonner le blog ou les guides qui amenaient des backlinks
• Indexer le staging (noindex oublié, puis indexé, puis nettoyé trop tard)
• Réécrire tous les slugs « pour faire plus joli » sans table 301
• Ignorer les avis et UGC qui faisaient le volume de texte indexable sur les fiches

Checklist SEO avant et après bascule

• Export Search Console / analytics des URLs à trafic
• Règles d'URL de la destination documentées
• Table ancienne URL → nouvelle URL pour le catalogue et le contenu
• 301 testés sur le top trafic (pas seulement « le module est installé »)
• Titles, meta, H1 et descriptions longues présents sur les fiches prioritaires
• Maillage interne et menus sur les nouvelles URLs
• Canoniques, robots.txt et sitemap alignés sur le domaine final
• Crawl préprod sans 404 critiques
• Suivi 404 + Search Console planifié sur 4 à 8 semaines
• Ancienne boutique encore capable de rediriger pendant la période de filet

À retenir

Protéger le SEO d'une boutique, c'est un projet de données et de contrôles, pas un thème. Les 301 et le contenu indexable se préparent avant le DNS. Le suivi après la bascule fait partie du livrable.

Leaving a SaaS store (catalog, payments, subscriptions) is covered in Leaving Shopify for a store you own. This article goes deeper on the one topic that often wipes organic revenue: SEO.

Goal: reach cutover day with a complete old URL → new URL table, pages that keep indexable content, and a monitoring plan to fix 404s before Google treats them as the site vanishing.

Why traffic drops after a migration

• Broken URLs without 301s: the crawler hits a 404 or a generic page. Equity on the old URL fades.
• URL structure rewritten without a map: /products/handle becomes /category/product/ with no row in the redirect file.
• Titles, meta and H1 lost on import: the page exists, but it is no longer the one that ranked.
• Thinned content: truncated descriptions, FAQ or guide blocks not migrated, near-empty PDPs.
• Wrong canonicals and sitemaps: the new store points at old URLs, a staging host, or omits half the catalog.
• Dead internal links: menus, footer, related blocks and blog posts still use the old scheme.
• Facets and parameters: color/size filters indexed at scale, or useful pages blocked in robots.txt.
• HTTPS, www, trailing slash: four variants of the same product, redirect chains, or mixed http/https.

A short dip in crawl and rankings is common even when the work is done well. A sharp, lasting drop almost always traces to missing 301s, soft 404s, or lost content.

1. Inventory the URLs that carry traffic

Before you touch the new store, export reality, not guesses:

• Search Console: pages with impressions and clicks (12 to 16 months if you can)
• Analytics: organic sessions by URL, not only by pretty page titles
• Known backlinks (tools or Search Console Links) to PDPs and articles
• Current XML sitemap and any redirects already live

Rank them: top traffic, pages with backlinks, strategic collections, converting blog posts. Those lists become absolute mapping priority. An 8,000 SKU store does not have 8,000 critical URLs on day one. It often has a few hundred that do most of the work.

2. Freeze URL rules before bulk import

Decide once: prefixes (/product/, /category/), language in the path or not, trailing slash, accents and special characters. Write it down.

If the destination imposes a different scheme from Shopify, PrestaShop or WooCommerce, accept it and map. Do not "fix" slugs by feel during import: every change creates a mandatory redirect row.

3. Build the 301 redirect table

File (CSV or sheet) with at least: full old URL, full new URL, page type, priority (traffic / backlink / other). Cover:

• Product pages
• Collections / categories
• Institutional and landing pages
• Blog posts and guides
• Redirects already live (avoid chains: A→B then B→C, aim for A→C)

Rule: permanent 301, a useful target (PDP or close category), never a homepage catch-all for the whole catalog. Test the top 50 to 100 Search Console URLs on an environment that already serves the 301s (staging with hosts, or a preprod behind the right test host).

4. Preserve on-page SEO on import

For every priority URL, check that the new page keeps:

• Title and meta description (or clearly better equivalents, not empty)
• H1 aligned with query intent
• PDP body: long description, specs, FAQ if they existed
• Images with sensible filenames and alt text
• Product structured data (offer, availability, price) if you had it, or if the new stack can emit it cleanly

A "price + image" CSV import without SEO text is a regression dressed up as a successful migration.

5. Rebuild internal linking

301s save entry from Google. Internal links tell the engine which pages still matter on your site.

• Menus and mega-menus on new URLs only
• Breadcrumbs consistent with the new tree
• Related products, "frequently bought together", links inside the blog
• Hub pages (guides, lookbooks) updated, not left as drafts

Crawl preprod (Screaming Frog, Sitebulb, or similar) and hunt internal 404s before DNS.

6. Technical: canonicals, robots, sitemap, performance

• Canonicals: each PDP points to itself on the final domain (not staging).
• robots.txt: does not block the useful catalog. Block useless facets if that was already your policy, without inventing a wider block on cutover day.
• XML sitemap: only final 200 URLs, current, submitted in Search Console after cutover.
• Hreflang: if you run multiple languages, pairs must stay coherent after migration.
• Performance and Core Web Vitals: a slower store can amplify a dip. Not the first lever, but do not launch a preprod three times heavier without noticing.

If the migration also changes hosting, align the order of operations with Switching hosting without downtime: parallel build first, DNS second.

7. Quality control before cutover

1. Top-traffic sample: 301 or 200 as expected, content present, cart reachable
2. Full preprod crawl: 404s, chains, canonicals, mass duplicate titles
3. Title/H1 compare on 30 flagship PDPs (old vs new)
4. Payment and email tests (not SEO, but an "SEO-ready" store that cannot sell is useless)
5. Rollback plan: old store still able to serve or redirect if cutover fails

8. Cutover, monitoring, fixes

On the day:

• Turn on production 301s at the same time traffic hits the new stack
• Submit the new sitemap, request indexing for critical hubs if needed
• Watch Search Console (Pages / indexing), 404 logs, and a sheet of priority URLs
• Fix remaining 404s within 48 hours, then weekly for 4 to 8 weeks

Keep the old platform on redirects (or read-only plus redirects) long enough to catch misses. Cutting too early throws away the safety net.

What a "normal" result looks like

With a solid map and preserved content:

• A few days to a few weeks of ranking volatility (recrawl, redistribution)
• Priority URLs recover most impressions if 301s and content are sound
• Secondary pages can take longer, especially with few links

What is not normal: a wide catalog drop from the index, 404s on the top 50, or organic traffic halved for months with no fix plan. In that case, reopen the redirect file and the crawl before you "wait for it to come back".

Mistakes that make the drop permanent

• Redirecting everything to the homepage
• Using 302s "for now" on permanent URL changes
• Chains A→B→C and loops
• Changing domain and platform on the same day without a double map
• Abandoning the blog or guides that brought backlinks
• Indexing staging (forgotten noindex, then indexed, then cleaned too late)
• Rewriting every slug "to look nicer" without a 301 table
• Ignoring reviews and UGC that made PDPs indexable at scale

SEO checklist before and after cutover

• Search Console / analytics export of traffic URLs
• Destination URL rules documented
• Old URL → new URL table for catalog and content
• 301s tested on top traffic (not only "the redirect app is installed")
• Titles, meta, H1 and long descriptions present on priority PDPs
• Internal links and menus on new URLs
• Canonicals, robots.txt and sitemap aligned to the final domain
• Preprod crawl without critical 404s
• 404 + Search Console monitoring planned for 4 to 8 weeks
• Old store still able to redirect during the safety-net period

In short

Protecting store SEO is a data and control project, not a theme. 301s and indexable content are prepared before DNS. Post-cutover monitoring is part of the deliverable.