Tu as choisi Webflow, Framer ou Bubble parce que ça va plus vite qu'un site codé à la main, et c'est un bon calcul dans la majorité des cas. Le problème, c'est que ces outils cachent une partie de leurs réglages SEO derrière des toggles qu'on oublie de cocher au lancement, et qu'aucun des guides génériques "SEO no-code" qui traînent en ligne ne parle de la partie qui compte le plus en 2026 : est-ce que les moteurs IA arrivent seulement à lire ta page.
Ce guide couvre les pièges techniques propres à chaque plateforme, une checklist avant mise en ligne, et l'angle que la quasi-totalité des comparatifs "Webflow vs Framer" zappent complètement : le rendu JavaScript et la lecture de ta page par les crawlers IA (GPTBot, ClaudeBot, PerplexityBot).
Pourquoi un site no-code cumule des soucis SEO invisibles au lancement
Un builder no-code publie un site qui a l'air fini en quelques heures. Le souci, c'est que "visuellement fini" et "correctement configuré pour le SEO" sont deux états indépendants : la plateforme gère l'hébergement, le HTTPS et la génération du HTML, mais laisse activés par défaut des réglages pensés pour un environnement de test, pas pour une mise en production.
La majorité des soucis SEO relevés sur un audit de site no-code ne viennent donc pas d'un manque de contenu, mais de trois ou quatre cases à cocher oubliées entre le moment où le site "a l'air prêt" et celui où il est réellement prêt à être crawlé.
Le sous-domaine de preview qui reste indexé (l'erreur la plus fréquente)
Chaque plateforme no-code fournit un sous-domaine gratuit pour prévisualiser ton site avant de brancher ton nom de domaine : .webflow.io pour Webflow, .framer.app ou .framer.website pour Framer, .bubbleapps.io pour Bubble. Ce sous-domaine reste techniquement en ligne et indexable même après le branchement de ton propre domaine, sauf si tu désactives explicitement son indexation.
Google peut alors se retrouver avec deux versions de ta page qui se battent pour le même contenu : les signaux de classement se dispersent, et dans le pire des cas, c'est le sous-domaine de preview, pas ta marque, qui apparaît dans les résultats de recherche.
Trois points à vérifier immédiatement après la mise en ligne :
- Le toggle "Discourage search engines" (Webflow) ou équivalent doit être désactivé sur le domaine de production, mais activé sur le sous-domaine de preview, c'est souvent l'inverse qui traîne après un lancement précipité.
- La balise
canonicalde chaque page doit pointer vers ton nom de domaine final, jamais vers le sous-domaine.webflow.ioou.framer.app. Si tu passes par un proxy inversé ou un CDN tiers, vérifie le code source après publication : la valeur peut rester bloquée sur l'ancienne URL de preview. - Le fichier
robots.txtgénéré automatiquement doit référencer ton domaine de production dans la directive sitemap, pas le sous-domaine technique.
Ce problème est cousin direct de ce qu'on décrit dans notre guide sur le crawl budget et l'indexation : chaque URL dupliquée que Google découvre est une URL de plus à crawler pour rien, au détriment de tes pages qui comptent vraiment.
CMS, migration et redirections : le trio qui casse le plus de trafic
Si tu migres un site existant (WordPress, Shopify, ou un site codé sur-mesure) vers un builder no-code, trois erreurs reviennent quasi systématiquement :
- Les slugs de collection CMS changent sans redirection. Un article qui vivait sur
/blog/mon-articlese retrouve sur/articles/mon-articleaprès l'import, sans redirection301entre les deux. - Les liens internes dans le contenu riche pointent encore vers l'ancienne structure, avec des URLs cassées ou absolues vers l'ancien domaine.
- Les métadonnées personnalisées (title, description) ne survivent pas à l'import et se retrouvent remplacées par des valeurs génériques de template, identiques sur des dizaines de pages, un cas classique de contenu dupliqué détaillé dans notre article sur les redirections HTTP et le SEO.
La règle à appliquer avant toute migration : exporte tes URLs actuelles (Search Console ou un crawler), construis un tableau ancienne URL → nouvelle URL, et teste chaque redirection en staging avant de publier.
Performance et Core Web Vitals : ce que chaque plateforme gère, et ce qu'elle ne gère pas
Webflow publie du HTML statique pré-rendu via un CDN, avec conversion automatique des images en WebP/AVIF depuis 2024, la majorité des sites tiennent les seuils Core Web Vitals sans effort particulier. Framer suit une logique proche côté livraison, mais les animations lourdes et interactions complexes font grimper le JavaScript exécuté côté client, avec un impact direct sur le CLS et l'INP à mesure que le projet se complexifie. Bubble, pensé davantage comme un constructeur d'applications qu'un générateur de sites statiques, embarque généralement un bundle JS plus lourd, un point d'attention pour des pages qui doivent aussi bien se positionner en SEO.
Dans les trois cas, même réflexe : passer chaque page publiée dans PageSpeed Insights avant le lancement, pas seulement l'accueil.
L'angle GEO : les crawlers IA ne lisent pas ton JavaScript
C'est le point que la quasi-totalité des comparatifs Webflow vs Framer ignorent, et c'est pourtant celui qui pèsera le plus lourd en 2026. Une étude Vercel/MERJ portant sur plus de 500 millions de requêtes de GPTBot est nette : zéro exécution de JavaScript détectée. GPTBot, ClaudeBot et PerplexityBot récupèrent le HTML brut et en extraient le texte tel qu'il apparaît dans le code source initial, sans jamais exécuter de script, contrairement à Googlebot, qui utilise un moteur Chrome headless capable de rendre une page complètement avant de l'indexer.
Concrètement, ça change la donne selon la plateforme :
- Webflow, en publiant du HTML pré-rendu statique par défaut, s'en sort plutôt bien : le texte principal est présent dans la réponse brute, donc lisible par un crawler IA qui n'exécute rien.
- Framer et Bubble, quand du contenu est injecté dynamiquement côté client (composants interactifs, données chargées après coup), courent un risque réel : ce contenu peut être visible pour un humain et pour Googlebot tout en étant absent de ce que récupère un crawler IA.
Le test le plus simple : récupère le HTML brut d'une page avec une requête sans navigateur (curl, ou "Récupérer comme Google" en mode HTML seul) et vérifie que ton contenu principal, titres, paragraphes, données produit, apparaît bien dans ce résultat brut, pas seulement dans le rendu final du navigateur. Même principe que dans notre guide sur le SEO JavaScript et le rendu SSR/SSG/CSR, appliqué ici aux limites des builders no-code.
Schema et données structurées : ce qui est automatique, ce qu'il faut ajouter à la main
Webflow génère automatiquement une partie du balisage de base (Organization, parfois BreadcrumbList) mais laisse le FAQ, le HowTo ou le Product schema à ta charge, via un bloc de code JSON-LD. Framer et Bubble fonctionnent pareil : rien de spécifique au métier n'est généré sans intervention manuelle. Prévoir ce bloc de code custom dès la structure du site t'évite un audit correctif quelques mois plus tard.
Mini cas chiffré : un scénario type de migration mal préparée
Prenons un scénario représentatif d'une migration WordPress vers Webflow sans plan de redirection : un site de 60 pages, dont 25 articles de blog. Sans tableau ancienne URL → nouvelle URL, on se retrouve typiquement avec une vingtaine de pages qui changent de chemin (/blog/ devient /articles/), zéro redirection 301 posée, et le sous-domaine .webflow.io resté indexable en parallèle du nouveau domaine. Sur Search Console, ça se traduit en général par une hausse nette des erreurs 404 dès les deux premières semaines, et par un partage des impressions entre ancienne et nouvelle URL sur les requêtes qui rankaient déjà. Le correctif, redirections 301 en masse plus désindexation du sous-domaine de preview, ramène la situation à la normale en quelques semaines, mais la perte de temps (et parfois de positions gagnées de longue date) aurait été évitée avec une checklist appliquée avant le lancement.
Checklist avant lancement
| Vérification | Plateformes concernées | Pourquoi ça compte |
|---|---|---|
| Sous-domaine de preview désindexé | Webflow, Framer, Bubble | Évite le duplicate content entre preview et production |
| Canonical pointant vers le domaine final | Toutes | Empêche Google de mélanger les signaux entre deux URLs |
| Redirections 301 sur toutes les URLs migrées | Toutes | Conserve le trafic et l'autorité accumulée |
| Contenu principal présent dans le HTML brut (sans JS) | Framer, Bubble surtout | Conditionne la lecture par les crawlers IA |
| Schema FAQ/Product/HowTo ajouté manuellement | Toutes | Aucune plateforme ne le génère automatiquement |
| Sitemap XML soumis dans Search Console | Toutes | Accélère la découverte des nouvelles URLs |
FAQ
Un site fait avec Webflow ou Framer est-il aussi bien indexé qu'un site codé sur-mesure ?
Techniquement oui, à condition que les réglages d'indexation par défaut (sous-domaine de preview, canonical) soient corrigés. Aucune des deux plateformes n'est pénalisée en tant que telle, les soucis viennent presque toujours d'une configuration incomplète, pas de l'outil lui-même.
Comment savoir si mon sous-domaine de preview est encore indexé par Google ?
Fais une recherche site:tonprojet.webflow.io (ou l'équivalent .framer.app, .bubbleapps.io) directement dans Google. Si des résultats remontent, désactive l'indexation du sous-domaine dans les réglages de la plateforme et demande une suppression via Search Console.
Les moteurs IA comme ChatGPT ou Perplexity peuvent-ils lire un site fait avec Framer ?
Oui, mais seulement le contenu présent dans le HTML brut au moment du chargement initial. Si des blocs de texte sont injectés dynamiquement après coup en JavaScript, ils restent invisibles pour GPTBot, ClaudeBot et PerplexityBot, qui n'exécutent pas de script.
Faut-il éviter Bubble si le SEO et le GEO sont une priorité ?
Pas nécessairement, mais Bubble est conçu d'abord comme un constructeur d'applications, avec un bundle JS plus lourd par défaut. Pour des pages qui doivent bien se positionner, vérifie que le contenu principal est présent dans le HTML brut avant de considérer le SEO comme acquis.
À retenir
- Le sous-domaine de preview (
.webflow.io,.framer.app,.bubbleapps.io) reste indexable par défaut : à désactiver explicitement au lancement. - Toute migration vers un builder no-code exige un tableau de correspondance ancienne URL → nouvelle URL, avec des redirections 301 testées avant publication.
- Les crawlers IA (GPTBot, ClaudeBot, PerplexityBot) n'exécutent pas le JavaScript : seul le contenu présent dans le HTML brut compte pour la citation par les moteurs de réponse.
- Webflow s'en sort mieux nativement sur ce point grâce à son rendu statique pré-rendu ; Framer et Bubble demandent une vérification manuelle dès que du contenu est injecté dynamiquement.
- Aucun schema métier (FAQ, Product, HowTo) n'est généré automatiquement : il faut l'ajouter via un bloc de code custom sur les trois plateformes.
Tu veux savoir si ton site no-code a un sous-domaine de preview encore indexé, un canonical mal configuré ou du contenu invisible pour les crawlers IA ? Obtiens ton score /100 gratuitement en quelques minutes, ou passe au rapport complet en PDF pour une checklist priorisée propre à ta plateforme.