Migration Webflow vers Framer : 87 redirects hub-and-spoke perdues, PageRank dilué pendant 90 jours

Jeudi 14h. Une agence design parisienne bascule le DNS de son client — un SaaS B2B de 340 pages — de Webflow vers Framer. Le site est magnifique. Les animations sont fluides. Le lighthouse score frôle 95. Trois semaines plus tard, le trafic organique a chuté de 38%. Personne ne comprend pourquoi.

T+21 jours — Le tableau de bord vire au rouge

Le 7 avril au matin, la responsable acquisition ouvre Google Search Console. Le graphique des clics ressemble à une falaise.

Le site passait de 1 240 clics/jour à 770. Pas une chute brutale, mais un décrochage linéaire, régulier, commencé exactement le jour de la migration le 17 mars.

Premier réflexe : vérifier l'indexation. Aucune page désindexée. Pas d'action manuelle. Le rapport « Couverture » affiche 338 pages valides. Presque le bon chiffre.

Deuxième réflexe : regarder les erreurs de crawl. Là, 87 URLs remontent en « Page introuvable (404) ». Toutes des URLs du type /guide/nom-du-guide, /ressources/nom-de-la-ressource, /cas-client/nom-du-client.

L'équipe SEO scrolle la liste. Ce ne sont pas des pages actuelles. Ce sont des anciennes URLs — celles de l'architecture précédente, redirigées en 301 vers les nouvelles URLs il y a huit mois lors d'une restructuration de l'arborescence.

La responsable SEO pose la question au Slack de l'agence design : « Les redirections Webflow ont été exportées ? »

Silence.

Puis : « L'export Webflow ne contient pas les redirections. »

L'équipe vérifie. L'export Webflow — qu'il soit en CMS collection ou via l'API — ne contient effectivement aucune donnée de redirection. Ni les redirects 301 custom, ni les règles de réécriture. Côté Framer, aucune fonctionnalité d'import de redirections en masse n'existe. La migration a été faite page par page, contenu par contenu. Les redirections, elles, sont restées sur Webflow — un Webflow qui ne répond plus puisque le DNS pointe ailleurs.

Le dégât est chirurgical. Les 87 URLs perdues ne sont pas n'importe lesquelles. Ce sont les anciennes URLs hub — les pages piliers /guide/, /ressources/, /cas-client/ — qui avaient accumulé des backlinks sur 18 mois. Les 301 les routaient vers les nouvelles pages spoke. Sans ces redirections, les backlinks tombent dans le vide. Le PageRank se dissipe. Et les pages spoke, privées de leur jus entrant, décrochent dans les SERPs.

En 21 jours, 14 des 20 top landing pages organiques ont perdu entre 3 et 11 positions. Le mot-clé principal du site — « [solution] pour PME » — est passé de la position 4 à la position 19.

Le bug : l'export Webflow est structurellement incomplet

Pour comprendre la mécanique du désastre, il faut regarder comment Webflow stocke les redirections et ce que Framer offre (ou n'offre pas) à l'import.

Les redirections Webflow : un silo opaque

Dans Webflow, les redirections 301 se configurent dans Project Settings > Hosting > 301 Redirects. Elles sont stockées côté plateforme, pas dans le contenu exportable.

L'export Webflow via le bouton « Export Code » génère du HTML/CSS/JS statique. Voici ce qu'on obtient pour une page type :

<!-- Export Webflow : /guide/strategie-acquisition — page exportée -->
<!DOCTYPE html>
<html data-wf-page="6523a4b1c7e8f9001d2e3a4b" data-wf-site="6523a4b1c7e8f9001d2e3a4c">
<head>
  <meta charset="utf-8">
  <title>Stratégie d'acquisition pour PME | SaaSName</title>
  <meta name="description" content="Guide complet...">
  <link rel="canonical" href="https://www.saasname.com/guide/strategie-acquisition">
  <!-- Aucune trace des 301 qui pointaient vers cette page -->
</head>
<body>
  <!-- Contenu statique -->
</body>
</html>

Aucune trace des anciennes URLs. Aucun fichier .htaccess, aucun _redirects, aucun vercel.json. Les 87 règles de redirection — certaines avec des patterns regex — n'existent que dans l'interface Webflow.

L'API Webflow v2 ne les expose pas non plus. La documentation officielle de l'API Webflow liste les endpoints disponibles : Sites, Collections, Items, Assets, Webhooks. Pas de endpoint /redirects.

Framer : pas d'import, une configuration manuelle

Côté Framer, les redirections se configurent dans Site Settings > URL Redirects. Manuellement. Une par une. Ou via un fichier JSON collé dans l'interface, avec ce format :

[
  {
    "from": "/ancienne-url-guide-seo",
    "to": "/guide/strategie-acquisition",
    "type": 301
  },
  {
    "from": "/old-resources/case-study-acme",
    "to": "/cas-client/acme-corp",
    "type": 301
  },
  {
    "from": "/blog/2023/acquisition-tips",
    "to": "/guide/strategie-acquisition",
    "type": 301
  }
]

Ce format n'est documenté nulle part dans l'export Webflow. Il faut reconstituer manuellement chaque règle.

Ce que voit le développeur vs ce que voit Googlebot

Le développeur ouvre le nouveau site Framer dans son navigateur. Toutes les pages actuelles répondent. Le contenu est là. Les metas sont correctes. Le site est rapide. Tout semble parfait.

Googlebot, lui, recrawle les 87 anciennes URLs encore présentes dans son index — des URLs qu'il connaît depuis 18 mois, pointées par des backlinks externes. Voici ce qu'il obtient :

# Simulation du crawl Googlebot sur une ancienne URL hub
curl -I -A "Googlebot" https://www.saasname.com/ancienne-url-guide-seo

HTTP/2 404
content-type: text/html; charset=utf-8
x-frame-options: DENY
# Pas de Location header — pas de redirect — juste un 404

La page 404 de Framer est jolie. Elle a un bouton « Retour à l'accueil ». Mais pour Googlebot, c'est un signal clair : cette URL n'existe plus. Le PageRank qui transitait par les 301 est coupé net.

Pourquoi les tests pré-migration n'ont rien détecté

L'agence avait fait un crawl Screaming Frog du site Framer en staging. Résultat : 0 erreur 404. Logique — le crawl partait de la homepage et suivait les liens internes. Les 87 anciennes URLs n'étaient linkées nulle part sur le nouveau site. Elles n'existaient que dans l'index Google et dans les backlinks externes.

Pour les détecter, il aurait fallu injecter la liste des URLs redirigées dans Screaming Frog en mode « List » :

# Screaming Frog CLI — crawl en mode liste
# Fichier redirects_a_verifier.txt contenant les 87 anciennes URLs
screaming-frog-seo-spider --crawl-mode list \
  --input-file redirects_a_verifier.txt \
  --export-tabs "Response Codes" \
  --output-folder ./audit-pre-migration/ \
  --headless

Ce crawl aurait immédiatement révélé 87 lignes en status 404 au lieu de 301. Mais personne n'avait cette liste — parce que personne ne l'avait extraite de Webflow avant la migration.

L'architecture hub-and-spoke amplifiait le dégât

Le site utilisait une architecture hub-and-spoke classique : 4 pages piliers (les hubs) reliaient chacune 8 à 15 pages détaillées (les spokes). Les hubs avaient été restructurés 8 mois plus tôt, générant les 87 redirections.

La distribution de backlinks était concentrée : 62 des 87 anciennes URLs pointaient vers les 4 hubs. Ces hubs distribuaient ensuite l'autorité aux spokes via le maillage interne. Quand les 301 des hubs ont cassé, l'effet domino a touché les spokes — même celles qui n'avaient aucune redirection les concernant directement.

En termes de backlinks perdus, l'audit Ahrefs montrait :

Hub /ancienne-url-guide-seo : 34 referring domains, DR moyen 41 → 404
Hub /old-resources/ : 19 referring domains, DR moyen 38 → 404
Hub /ancien-blog/category/acquisition : 28 referring domains, DR moyen 35 → 404

Trois mois de link building évaporés en un changement DNS.

Le fix — reconstruction des redirections et récupération

Étape 1 : extraire les redirections de Webflow (avant résiliation)

Premier problème : le plan Webflow du client était encore actif. L'équipe a pu se reconnecter et extraire manuellement les redirections depuis Project Settings > Hosting > 301 Redirects.

Webflow n'offrant pas d'export natif, l'extraction s'est faite via un script de scraping de l'interface (le client étant propriétaire de ses données) :

// Script exécuté dans la console du dashboard Webflow
// Navigation : Project Settings > Hosting > 301 Redirects
// Extrait toutes les redirections visibles dans l'interface

const redirectRows = document.querySelectorAll('[data-redirect-row]');
const redirects = [];

redirectRows.forEach(row => {
  const from = row.querySelector('[data-redirect-from]')?.textContent?.trim();
  const to = row.querySelector('[data-redirect-to]')?.textContent?.trim();
  if (from && to) {
    redirects.push({ from, to, type: 301 });
  }
});

// Fallback : si les selectors Webflow ont changé, parser les inputs
if (redirects.length === 0) {
  const inputs = document.querySelectorAll('.redirect-row');
  inputs.forEach(row => {
    const fields = row.querySelectorAll('input');
    if (fields.length >= 2) {
      redirects.push({
        from: fields[0].value,
        to: fields[1].value,
        type: 301
      });
    }
  });
}

console.log(JSON.stringify(redirects, null, 2));
// Copier-coller le résultat dans un fichier redirects.json

Résultat : 87 règles de redirection récupérées. Plus 14 règles supplémentaires découvertes — des anciennes URLs de blog que personne ne suivait.

Étape 2 : injecter les redirections dans Framer

L'équipe a formaté le JSON et l'a injecté dans Framer via Site Settings > URL Redirects. Pour les 101 redirections, l'opération a pris 45 minutes — Framer n'acceptant pas le copier-coller en masse de manière fiable, l'insertion s'est faite par lots de 20.

Étape 3 : vérification post-déploiement

Un crawl Screaming Frog en mode liste sur les 101 anciennes URLs a confirmé que chacune renvoyait bien un 301 :

# Vérification rapide des redirections critiques via curl
for url in $(cat anciennes_urls.txt); do
  status=$(curl -o /dev/null -s -w "%{http_code}" -L "$url")
  final=$(curl -o /dev/null -s -w "%{url_effective}" -L "$url")
  echo "$url -> $status -> $final"
done

# Résultat attendu pour chaque ligne :
# https://www.saasname.com/ancienne-url-guide-seo -> 301 -> https://www.saasname.com/guide/strategie-acquisition

Les 101 URLs répondaient en 301. Les destinations étaient correctes. Aucune chaîne de redirection.

Étape 4 : forcer le recrawl

L'équipe a soumis les 101 URLs via l'outil d'inspection d'URL de Search Console, par lots de 10 par jour (la limite de soumissions manuelles rendant le processus étalé sur 10 jours). En parallèle, un sitemap temporaire listant les URLs de destination a été soumis pour accélérer le recrawl.

Temps de récupération

Le fix a été déployé le 8 avril — 22 jours après la migration.

J+7 après le fix : 34 des 87 anciennes URLs recrawlées par Google, redirections reconnues.
J+21 : 79 URLs recrawlées. Le trafic organique remonte à 950 clics/jour.
J+45 : retour à 1 180 clics/jour. Proche du niveau pré-migration.
J+90 : 1 260 clics/jour. Le mot-clé principal revient en position 6 — pas la position 4 d'avant. Deux positions définitivement perdues.

Au total, l'incident a coûté environ 31 000 clics sur 90 jours. Deux positions sur le mot-clé principal n'ont jamais été récupérées — probablement parce que des concurrents ont profité de la fenêtre pour consolider leurs positions pendant le core update de mai 2026.

Ce qu'on en retient

Trois leçons dures.

Un. Avant toute migration de plateforme, l'inventaire des redirections est aussi critique que l'inventaire du contenu. L'export natif ne suffit jamais. Il faut un document source unique — spreadsheet, JSON, peu importe — qui liste chaque ancienne URL, sa destination, et son status code. C'est un livrable de migration, pas un détail.

Deux. Le test pré-migration doit inclure un crawl en mode liste des URLs historiques, pas seulement un crawl spider du nouveau site. Screaming Frog, Sitebulb, ou un simple script curl : l'outil importe peu. Ce qui compte, c'est de tester ce que Google va demander, pas ce que le site propose. Un article complet détaille cette approche dans le cas de WordPress vers headless, et les mêmes principes s'appliquent ici.

Trois. Le temps joue contre vous. Chaque jour sans 301, Google consolide le 404. Un monitoring continu type Seogard détecte la divergence entre les status codes attendus et les status codes réels dès le premier crawl post-migration — pas trois semaines plus tard quand le trafic a déjà décroché.

Les migrations entre plateformes no-code sont séduisantes. Elles sont aussi les plus dangereuses pour le SEO, précisément parce qu'elles cachent la plomberie technique derrière des interfaces visuelles. La plomberie, elle, ne se copie-colle pas.

Migration Webflow → Framer : 301 perdues, PageRank dilué