John Mueller, Search Advocate chez Google, a posé le diagnostic sans détour : les outils d'IA générative produisent des sites fonctionnels en quelques minutes, mais ignorent systématiquement les fondamentaux techniques du SEO. Pas de robots.txt, pas de sitemap.xml, pas de balises canonical, pas de gestion propre des status codes. Le "vibe coding" — cette pratique qui consiste à décrire un site en langage naturel et laisser l'IA le construire — livre du code qui compile, mais qui reste invisible pour les moteurs de recherche.
Ce constat n'est pas une opinion. C'est une observation vérifiable sur la quasi-totalité des projets générés par Bolt, v0, Lovable ou Claude Artifacts. Et les conséquences sur des sites de plusieurs milliers de pages sont dévastatrices.
Le problème structurel : l'IA optimise pour le navigateur, pas pour le crawler
Les LLM qui génèrent du code web sont entraînés sur des corpus massifs de code source. Leur objectif d'optimisation : produire du code qui fonctionne visuellement dans un navigateur. Le rendu Googlebot n'a jamais fait partie de leur fonction de loss.
Concrètement, quand vous demandez à un outil comme Bolt de créer un site e-commerce, vous obtenez un SPA React avec du client-side rendering, des routes dynamiques gérées par React Router, et zéro indication pour les robots d'indexation. Le site s'affiche parfaitement dans Chrome. Googlebot, lui, voit une coquille vide.
L'absence de SSR comme symptôme
La majorité des sites AI-built utilisent des frameworks SPA (React, Vue) sans configuration SSR. Le code généré ressemble à ceci :
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>MonShop</title>
</head>
<body>
<div id="root"></div>
<script type="module" src="/src/main.tsx"></script>
</body>C'est le HTML complet que Googlebot reçoit lors du premier fetch. Pas de balise <meta name="description">, pas de <link rel="canonical">, pas de données structurées, pas de contenu textuel. Tout dépend de l'exécution JavaScript côté client.
Google peut exécuter du JavaScript, mais avec un délai. La documentation officielle de Google sur le JavaScript SEO rappelle que le rendering se fait dans une "file d'attente de rendu" séparée du crawl initial. Sur un site de 8 000 pages produit en vibe coding, cela signifie potentiellement des semaines avant que le contenu soit réellement indexé — si le crawl budget le permet.
Le problème ne se limite pas au SSR. Même sur des sites statiques générés par IA, les éléments SEO critiques sont absents par défaut, simplement parce que personne ne les a demandés dans le prompt.
Ce que Mueller dit vraiment
La position de Mueller, relayée par Search Engine Journal, se résume en une phrase : les outils d'IA ne font que ce que vous leur demandez explicitement. Si votre prompt dit "crée un site vitrine pour un cabinet d'architecte", vous obtenez des composants visuels. Vous n'obtenez pas un robots.txt configuré, un sitemap.xml dynamique, une gestion des canonicals sur les pages paginées, ni des redirections 301 sur les anciennes URLs.
Ce n'est pas un bug. C'est le fonctionnement normal d'un LLM : il résout le problème posé. Le SEO technique n'est jamais "le problème posé" par un non-spécialiste.
Les cinq failles SEO récurrentes des sites AI-built
Après audit de plusieurs dizaines de sites générés par des outils de vibe coding (Bolt, v0, Lovable, Replit Agent), un pattern émerge. Les mêmes failles reviennent systématiquement.
1. Absence de robots.txt
Aucun des outils testés ne génère de fichier robots.txt par défaut. Sur un site Next.js ou Astro classique, ce fichier est souvent configuré manuellement ou via un plugin. Sur un site AI-built, il n'existe tout simplement pas.
L'absence de robots.txt n'empêche pas l'indexation — Googlebot crawle par défaut tout ce qu'il trouve. Mais elle empêche le contrôle du crawl budget. Sur un site e-commerce avec des pages de filtres (couleur, taille, prix), l'absence de robots.txt laisse Googlebot crawler des milliers de combinaisons de paramètres URL sans valeur d'indexation.
Voici un robots.txt minimal qu'aucun outil IA ne génère, mais que tout site de plus de 500 pages devrait avoir :
User-agent: *
Disallow: /api/
Disallow: /checkout/
Disallow: /account/
Disallow: /search?*
Disallow: /*?sort=
Disallow: /*?filter=
User-agent: GPTBot
Disallow: /
User-agent: Google-Extended
Disallow: /
Sitemap: https://www.monshop.fr/sitemap.xmlNotez les deux derniers blocs : la gestion des bots IA (GPTBot, Google-Extended) est un sujet en soi que les outils de vibe coding ignorent totalement. Si vous gérez un site dont le contenu propriétaire a de la valeur, ces directives de contrôle des bots IA deviennent critiques, et Google teste d'ailleurs un nouveau standard d'autorisation des bots.
2. Pas de sitemap.xml
Même constat. Les outils IA ne génèrent pas de sitemap. Sur un blog de 30 pages, l'impact est faible — Googlebot trouvera les pages via les liens internes. Sur un catalogue de 12 000 produits avec une arborescence à 4 niveaux de profondeur, l'absence de sitemap signifie que les pages orphelines ou faiblement maillées ne seront jamais découvertes.
3. Canonicals absents ou incohérents
C'est probablement la faille la plus dangereuse. Les sites AI-built ne posent jamais de balise <link rel="canonical">. Sur un site avec des variantes d'URL (paramètres UTM, filtres, versions HTTP/HTTPS, trailing slashes), Google doit deviner la version canonique. Et Google devine mal, régulièrement.
4. Meta tags génériques ou manquants
Quand ils existent, les <title> et <meta description> sont soit identiques sur toutes les pages, soit générés à partir du nom du composant React. Un audit Screaming Frog typique sur un site AI-built révèle 80 à 95 % de pages avec des titles dupliqués.
5. Aucune gestion des erreurs HTTP
Pas de page 404 personnalisée, pas de redirections, pas de gestion des soft 404. Les routes inexistantes retournent souvent un status 200 avec le contenu de la page d'accueil — le pire scénario possible pour l'indexation.
Scénario concret : migration d'un catalogue e-commerce vers un site AI-built
Prenons un cas réaliste. Une marque de mobilier DTC (direct-to-consumer) exploite un site Shopify de 4 200 pages (850 produits, 120 collections, le reste en pages CMS et blog). Le trafic organique : 45 000 visites/mois, principalement sur des requêtes mid-tail ("table basse chêne massif", "étagère murale métal noir").
L'équipe décide de reconstruire le site avec Bolt + Next.js pour gagner en flexibilité. Le prompt initial : "Crée un site e-commerce de mobilier moderne avec un catalogue produit, des pages collection, un panier et un checkout." Bolt livre un site fonctionnel en 3 heures. Design propre, navigation fluide, composants réutilisables.
Ce que l'audit révèle
Deux semaines après la mise en production, l'équipe SEO lance un crawl Screaming Frog :
- 4 200 URLs crawlées, dont 3 800 retournent un status 200 mais avec un
<title>identique : "MonMobilier | Accueil" - 0 balise canonical sur l'ensemble du site
- Aucun
robots.txt— Screaming Frog découvre 11 400 URLs crawlables en comptant les variantes de filtres - Pas de sitemap.xml — Google Search Console affiche "Sitemap non détecté"
- Toutes les pages produit sont rendues en CSR : le HTML source ne contient que le
<div id="root"> - Les anciennes URLs Shopify (
/products/table-basse-chene) retournent un 404 au lieu de rediriger vers les nouvelles (/catalogue/tables/table-basse-chene-massif)
L'impact en chiffres
En 6 semaines :
- Le trafic organique passe de 45 000 à 8 200 visites/mois
- 2 100 pages précédemment indexées sont supprimées de l'index (vérifiable dans le rapport "Pages" de Search Console)
- Les 850 pages produit ne sont toujours pas indexées — elles restent dans la file de rendering JavaScript de Google
- Le rapport "Couverture" affiche 3 400 URLs en "Découverte, actuellement non indexée"
Ce scénario n'est pas hypothétique. C'est le pattern exact observé sur des dizaines de migrations vers des sites AI-built depuis début 2025.
Le kit technique de rattrapage : ce que l'IA ne fera pas pour vous
Corriger un site AI-built pour le SEO revient à ajouter rétroactivement toute la couche technique que l'IA a ignorée. Voici les interventions prioritaires, avec du code prêt à l'emploi.
Forcer le SSR et injecter les meta tags côté serveur
Si le site utilise Next.js (le framework le plus fréquemment généré par les outils IA), la correction passe par la migration des composants vers le App Router avec des metadata statiques ou dynamiques.
// app/catalogue/[slug]/page.tsx
import { Metadata } from 'next'
import { getProduct } from '@/lib/api'
import { notFound } from 'next/navigation'
interface Props {
params: { slug: string }
}
export async function generateMetadata({ params }: Props): Promise<Metadata> {
const product = await getProduct(params.slug)
if (!product) {
notFound()
}
return {
title: `${product.name} — Mobilier design | MonMobilier`,
description: product.metaDescription || `${product.name} en ${product.material}. Livraison gratuite dès 500€. Fabrication française.`,
alternates: {
canonical: `https://www.monmobilier.fr/catalogue/${params.slug}`,
},
openGraph: {
title: product.name,
description: product.shortDescription,
images: [{ url: product.imageUrl, width: 1200, height: 630 }],
},
}
}
export default async function ProductPage({ params }: Props) {
const product = await getProduct(params.slug)
if (!product) notFound()
return (
<main>
<h1>{product.name}</h1>
{/* Contenu produit rendu côté serveur */}
</main>
)
}Ce code fait trois choses essentielles que l'IA n'a pas faites : il rend la page côté serveur (Googlebot reçoit du HTML complet), il injecte un canonical explicite par page, et il retourne un vrai 404 quand le produit n'existe pas au lieu d'un soft 404.
Pour aller plus loin sur les pièges JavaScript spécifiques au SEO e-commerce, les 5 leçons JavaScript SEO tirées de sites e-commerce majeurs détaillent les patterns à éviter.
Générer le sitemap.xml dynamiquement
Next.js App Router permet de générer un sitemap via une route app/sitemap.ts. Voici une implémentation qui couvre un catalogue produit et des pages CMS :
// app/sitemap.ts
import { MetadataRoute } from 'next'
import { getAllProducts, getAllCollections, getAllBlogPosts } from '@/lib/api'
export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
const baseUrl = 'https://www.monmobilier.fr'
const products = await getAllProducts()
const collections = await getAllCollections()
const posts = await getAllBlogPosts()
const productUrls = products.map((p) => ({
url: `${baseUrl}/catalogue/${p.slug}`,
lastModified: new Date(p.updatedAt),
changeFrequency: 'weekly' as const,
priority: 0.8,
}))
const collectionUrls = collections.map((c) => ({
url: `${baseUrl}/collections/${c.slug}`,
lastModified: new Date(c.updatedAt),
changeFrequency: 'weekly' as const,
priority: 0.7,
}))
const blogUrls = posts.map((post) => ({
url: `${baseUrl}/blog/${post.slug}`,
lastModified: new Date(post.publishedAt),
changeFrequency: 'monthly' as const,
priority: 0.5,
}))
return [
{ url: baseUrl, lastModified: new Date(), changeFrequency: 'daily', priority: 1.0 },
...productUrls,
...collectionUrls,
...blogUrls,
]
}Sur un site de 4 200 pages, ce sitemap permet à Googlebot de découvrir l'intégralité du catalogue sans dépendre du maillage interne — maillage qui, sur un site AI-built, est souvent incomplet.
Configurer les redirections 301 pour la migration
Le point que les outils IA ne gèrent jamais : le mapping des anciennes URLs. Lors d'une migration depuis Shopify, chaque ancienne URL doit pointer vers sa nouvelle destination. En Next.js, cela se configure dans next.config.js :
// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
async redirects() {
return [
// Mapping produits Shopify → nouvelle structure
{
source: '/products/:slug',
destination: '/catalogue/:slug',
permanent: true, // 301
},
// Mapping collections Shopify → nouvelle structure
{
source: '/collections/:slug',
destination: '/collections/:slug',
permanent: true,
},
// Pages spécifiques
{
source: '/pages/about',
destination: '/a-propos',
permanent: true,
},
// Catch-all pour les anciennes URLs de blog
{
source: '/blogs/journal/:slug',
destination: '/blog/:slug',
permanent: true,
},
]
},
async headers() {
return [
{
source: '/:path*',
headers: [
{
key: 'X-Robots-Tag',
value: 'index, follow',
},
],
},
{
// Bloquer l'indexation des pages de recherche interne
source: '/search',
headers: [
{
key: 'X-Robots-Tag',
value: 'noindex, nofollow',
},
],
},
],
},
}
module.exports = nextConfigSur un site avec 850 produits, le mapping un-à-un est rarement suffisant. Les slugs changent entre Shopify et la nouvelle structure. La bonne pratique : exporter toutes les URLs Shopify via l'API, mapper chacune manuellement ou via un script, et tester les redirections avec un crawl Screaming Frog en mode "list" avant la mise en production.
Au-delà du code : la checklist d'audit pour tout site AI-built
Le code ne suffit pas. Avant de mettre en production un site généré par IA, un audit systématique s'impose. Voici la procédure en cinq étapes, avec les outils associés.
Étape 1 : Valider le rendu Googlebot
Utilisez l'outil d'inspection d'URL de Google Search Console. Soumettez 5-10 URLs représentatives (page d'accueil, page catégorie, page produit, article de blog, page de résultat de recherche interne). Comparez le HTML rendu avec le code source. Si le contenu principal n'apparaît pas dans le HTML source, vous avez un problème de CSR.
Alternative pour un test rapide : Chrome DevTools > désactivez JavaScript (Settings > Debugger > Disable JavaScript) et rechargez la page. Ce que vous voyez est approximativement ce que Googlebot voit lors du premier fetch.
Étape 2 : Crawl complet avec Screaming Frog
Configurez Screaming Frog en mode "JavaScript rendering" (Configuration > Spider > Rendering > JavaScript). Lancez un crawl complet. Les métriques critiques à vérifier :
- Titles dupliqués : triez par "Title 1 Duplicate" dans l'onglet Page Titles
- Meta descriptions manquantes : filtre "Missing" dans l'onglet Meta Description
- Canonicals : onglet Canonicals > vérifiez que chaque page a un canonical self-referencing
- Status codes : triez par code de réponse, cherchez les soft 404 (pages retournant un 200 avec un contenu générique)
- Pages orphelines : croisez les URLs du sitemap avec les URLs découvertes par le crawl
Étape 3 : Vérifier les fichiers techniques
Testez manuellement :
https://votre-site.fr/robots.txt— doit exister et contenir des directives pertinenteshttps://votre-site.fr/sitemap.xml— doit exister, être valide XML, et lister toutes les URLs indexables- Soumettez le sitemap dans Google Search Console si ce n'est pas déjà fait
Étape 4 : Tester les redirections
Si vous migrez depuis un ancien site, exportez toutes les URLs indexées (Search Console > Pages > filtrer par "Indexées"). Testez chaque URL avec curl ou un crawl Screaming Frog en mode list :
# Tester le status code et la destination de redirection
curl -sI "https://www.monmobilier.fr/products/table-basse-chene" | grep -E "HTTP/|Location:"
# Résultat attendu :
# HTTP/2 301
# location: https://www.monmobilier.fr/catalogue/table-basse-cheneÉtape 5 : Monitoring continu
C'est le point que Mueller ne mentionne pas explicitement, mais qui découle logiquement de son analyse. Si l'IA ne configure pas les fondamentaux SEO à la construction, elle ne les maintiendra pas non plus lors des itérations suivantes. Chaque nouveau prompt qui modifie le site peut casser un canonical, supprimer un sitemap, ou introduire un soft 404.
Un outil de monitoring comme Seogard détecte automatiquement ces régressions — une meta description qui disparaît après un déploiement, un canonical qui change, un robots.txt modifié — avant qu'elles n'impactent l'indexation.
Le vrai problème : la compétence SEO ne s'encode pas dans un prompt
Le constat de Mueller touche un point plus profond que la simple absence de robots.txt. Le SEO technique est un système de contraintes interdépendantes. Le canonical d'une page dépend de l'architecture d'URL. Le robots.txt dépend de la structure des facettes. Le sitemap dépend de la logique d'indexation que vous avez définie.
Ces décisions ne sont pas des tâches d'implémentation — ce sont des décisions d'architecture qui requièrent une compréhension du fonctionnement des moteurs de recherche, de votre maillage interne, de votre stratégie de contenu. Un LLM peut écrire le code d'un sitemap dynamique si vous lui demandez. Mais il ne peut pas décider quelles pages méritent d'être dans le sitemap.
Le vibe coding fonctionne remarquablement bien pour le prototypage, le front-end, les fonctionnalités utilisateur. Mais il crée un faux sentiment de complétude. Le site "a l'air terminé", donc l'équipe le met en production. Les conséquences SEO n'apparaissent que 4 à 8 semaines plus tard, quand le trafic organique s'effondre et que Search Console affiche des centaines de pages en "Découverte, non indexée".
Ce phénomène va s'amplifier. Plus les outils IA deviennent capables, plus de sites seront construits par des équipes sans expertise SEO. Et plus le rôle du SEO technique — celui qui audite, configure, et monitore — deviendra critique.
Pour les sites qui aspirent à être visibles non seulement dans la recherche classique mais aussi dans les résultats générés par IA, la construction pour les agents IA ajoute une couche de complexité supplémentaire que le vibe coding est encore moins capable de gérer. Et si votre contenu n'est déjà pas crawlable correctement, il ne sera jamais cité par l'AI Search.
Ce qu'il faut retenir
Le vibe coding n'est pas l'ennemi du SEO. Mais il ne fait le travail qu'à moitié, et c'est la moitié visible — celle que le navigateur affiche. La moitié invisible — celle que Googlebot interprète — reste entièrement à votre charge. Chaque site AI-built devrait passer par un audit SEO technique complet avant mise en production, et être surveillé en continu après chaque itération. Les outils IA construisent vite. Mais seul un monitoring permanent — comme celui que propose Seogard — garantit que les fondamentaux SEO survivent à chaque déploiement.