SEO pour les sites créés avec l'IA : ce qui compte vraiment

Un site créé avec l'IA peut se classer aussi bien qu'un autre : les moteurs de recherche jugent ce que contient la page et la qualité du service rendu au visiteur, pas l'outil qui a écrit le code. Le piège est technique. De nombreux créateurs IA produisent des applications monopages qui envoient au navigateur un fichier HTML presque vide et dessinent le contenu avec JavaScript, ce qui rend chaque page plus difficile à lire et à partager pour les robots. Réglez cela par le pré-rendu ou le rendu côté serveur, donnez à chaque page son propre titre, sa description et son URL, ajoutez un plan de site, gardez-le rapide, puis faites la part que aucun outil ne fait à votre place : rédiger un contenu que les gens recherchent.

Pourquoi les applications monopages peinent dans les moteurs de recherche

Un site traditionnel envoie le texte complet de chaque page dans son HTML. Une application monopage (SPA), le résultat par défaut de nombreux créateurs IA, généralement React avec un outil comme Vite, envoie une petite coquille HTML, quelque chose comme un <div id="root"> vide, accompagnée d'un paquet JavaScript. Le navigateur exécute le JavaScript, qui construit alors la page.

Cela pose trois problèmes pour la recherche :

1. Le rendu est une étape supplémentaire. Google décrit trois phases pour les pages JavaScript : explorer le HTML, le rendre dans un navigateur Chromium sans interface, puis indexer le résultat rendu. Les recommandations de Google indiquent que le rendu côté serveur ou le pré-rendu reste une bonne idée, car c'est plus rapide pour les utilisateurs comme pour les robots, et parce que tous les robots ne peuvent pas exécuter JavaScript.
2. Les autres lecteurs de votre page ne font aucun rendu. Les aperçus de liens dans les applications de messagerie et les réseaux sociaux, ainsi que de nombreux robots, ne lisent généralement que le HTML initial. Si votre titre et votre image d'aperçu sont définis par JavaScript après le chargement, ces aperçus affichent les valeurs par défaut de la coquille vide, souvent le même titre pour chaque page.
3. Tout partage un seul fichier HTML. À moins que l'application ne le mette à jour, chaque URL a le même <title> et la même description, ce qui en dit peu aux moteurs sur chaque page.

Rien de tout cela n'empêche une application monopage d'être indexée. Cela signifie que vous comptez sur le robot pour faire plus de travail, et que vous perdez le contrôle sur ce que voient les lecteurs qui ne rendent pas la page.

Choisir une approche de rendu

Il existe quatre façons courantes de fournir un vrai HTML aux robots. Dans l'ordre approximatif de leur impact sur votre application :

Une règle pratique : la partie publique et indexable de votre site doit être statique ou pré-rendue ; l'application connectée derrière peut rester une application monopage classique. Les moteurs de recherche n'ont de toute façon pas à indexer les tableaux de bord.

Si vous partez de zéro et que le SEO compte, dites-le dès la première consigne pour que l'IA choisisse une configuration adaptée :

Construis un site vitrine pour un cabinet de kinésithérapie avec les pages Accueil, Services (une page par service), À propos, Tarifs et Contact. Le SEO est important : chaque page doit fournir l'intégralité de son contenu et son propre titre et sa propre méta-description dans le HTML initial. Utilise une configuration statique ou pré-rendue, pas une application monopage uniquement côté client.

Si vous avez déjà une application Vite monopage, demandez le pré-rendu des routes publiques :

Garde cette application React telle quelle, mais pré-rends les routes publiques (/, /pricing, /about, /blog et chaque /blog/:slug) en HTML statique à la compilation, chacune avec son propre titre, sa méta-description, son URL canonique et ses balises Open Graph. Les routes /app connectées peuvent rester rendues côté client.

Ensuite, vérifiez vous-même le résultat : ouvrez une page, choisissez Afficher le code source de la page (et non l'onglet Éléments des outils de développement, qui montre la page rendue) et confirmez que le texte et le titre figurent dans le HTML brut.

Maîtriser les bases de la page

Ces points s'appliquent quelle que soit l'approche de rendu.

Titres et méta-descriptions

• Un <title> unique par page, avec le sujet principal de la page en premier. Une longueur d'environ 50 à 60 caractères est une recommandation courante, car les titres plus longs tendent à être tronqués dans les résultats.
• Une méta-description unique par page : une phrase qu'une personne aurait envie de cliquer, et non une liste de mots-clés. Google peut la réécrire, mais une bonne description est souvent reprise.
• Ne mettez pas de méta-mots-clés. Google indique que la balise n'a aucun effet sur l'indexation ni sur le classement.

URL, titres et liens

• De vraies URL pour de vraies pages. Chaque contenu a besoin de son propre chemin (/services/massage-sportif), et non d'un onglet ou d'une fenêtre modale qui n'existe qu'après un clic. Évitez le routage par fragment # pour les contenus que vous voulez indexer.
• Un seul h1 par page, puis une structure cohérente de h2/h3. Les designs générés par l'IA utilisent parfois des titres pour le style ; demandez des titres sémantiques.
• Des liens explorables. Utilisez de vrais liens <a href> pour la navigation. Les boutons qui changent la page par JavaScript sont invisibles pour les robots qui suivent les liens.
• Des balises canoniques qui indiquent l'URL préférée de chaque page, pour que les variantes ?utm= et les doublons avec ou sans barre oblique finale ne se fassent pas concurrence.
• Un texte alternatif descriptif sur les images significatives.

Aperçus sur les réseaux sociaux

Ajoutez des balises Open Graph (og:title, og:description, og:image, og:url) à chaque page publique, dans le HTML initial. C'est le point que les applications monopages ratent le plus souvent, car les robots d'aperçu de liens n'exécutent pas JavaScript.

Plans de site et robots.txt

Un plan de site est un fichier XML qui liste les URL que vous voulez voir indexées. Il aide les moteurs à trouver les pages, surtout sur les nouveaux sites qui reçoivent peu de liens. Selon la documentation de Google, en septembre 2026 :

• Un seul plan de site peut contenir jusqu'à 50 000 URL ou 50 Mo non compressés ; découpez les sites plus grands avec un index de plans de site.
• Google ignore <priority> et <changefreq>.
• Google n'utilise <lastmod> que s'il est systématiquement exact ; mettez-le à jour pour les véritables changements de contenu, et non à chaque compilation.

Le fichier robots.txt indique aux robots quels chemins ne pas explorer. Utilisez-le pour tenir les robots à l'écart de /app, /admin et des routes d'API, et indiquez-y l'emplacement du plan de site. Rappelez-vous que robots.txt empêche l'exploration, pas l'indexation : pour qu'une page n'apparaisse pas dans les résultats, utilisez une balise meta robots noindex et laissez la page être explorée.

Soumettez le plan de site dans la Search Console de Google une fois le site sur son domaine définitif. La Search Console indique aussi quelles pages sont indexées et pourquoi d'autres ne le sont pas : c'est l'outil SEO gratuit le plus utile qui existe.

Données structurées

Les données structurées sont un balisage lisible par machine qui décrit ce qu'est une page : une organisation, une entreprise locale, un produit, un article, un événement. Google recommande le format JSON-LD et est clair sur deux points :

• Elles peuvent rendre les pages éligibles à des résultats enrichis, mais ne les garantissent pas.
• Elles doivent décrire des informations visibles sur la page. Ne balisez pas des avis, des prix ou des FAQ que les visiteurs ne peuvent pas voir.

Points de départ raisonnables : Organization ou LocalBusiness sur la page d'accueil, Product sur les pages produit, Article sur les articles de blog, BreadcrumbList sur les pages profondes. Testez avec l'outil Test des résultats enrichis de Google.

Ajoute des données structurées JSON-LD : LocalBusiness sur la page d'accueil, avec l'adresse, le téléphone et les horaires d'ouverture déjà affichés sur la page, et Article sur chaque article de blog. N'ajoute pas de notes ni d'avis.

Vitesse et mobile

Google utilise des signaux d'expérience de page, dont les Core Web Vitals, et la vitesse compte de toute façon pour les visiteurs. Les seuils « bon » de Google, mesurés au 75e percentile des chargements de page, sont :

Les correctifs habituels pour les sites créés avec l'IA :

• Images : redimensionnez, compressez, utilisez des formats modernes, indiquez la largeur et la hauteur (ce qui évite les décalages de mise en page), et chargez en différé ce qui est sous la ligne de flottaison.
• JavaScript : un paquet volumineux ralentit tout sur une application monopage. Le pré-rendu aide ; le découpage du code par route aussi.
• Polices : limitez le nombre de familles et de graisses, et précharger celle utilisée au-dessus de la ligne de flottaison.
• Scripts tiers : chaque widget de chat et pixel de suivi coûte en vitesse. Gardez seulement ceux que vous utilisez.

Testez l'URL en ligne avec PageSpeed Insights ou Lighthouse en mode mobile.

Le contenu reste l'essentiel

Le SEO technique supprime les obstacles ; il ne crée pas la demande. Les pages se classent parce qu'elles répondent à une recherche mieux que les alternatives. Pour la plupart des petits sites, cela signifie :

• Une page par sujet que les gens recherchent. Un plombier a besoin d'une page par service et par zone desservie, et non d'une seule page « Services » qui liste tout.
• Des détails spécifiques et originaux : prix, méthode, photos de réalisations réelles, réponses aux questions que vos clients posent au téléphone.
• Mis à jour quand les choses changent. Des horaires périmés ou d'anciens prix font vite perdre la confiance.

L'IA peut rédiger rapidement des pages, ce qui tente de publier beaucoup de pages minces et semblables. Les consignes de Google visent les contenus produits principalement pour se classer plutôt que pour aider les personnes, quelle que soit leur méthode de production. Utilisez l'IA pour ébaucher, puis ajoutez ce que vous seul savez. Les sites de type annuaire sont les plus exposés ; voir comment créer un site annuaire pour rendre les pages de fiches dignes d'être indexées.

Liste de contrôle avant lancement

• Les pages publiques fournissent tout leur contenu dans le HTML initial (vérifiez avec « Afficher le code source de la page »)
• Un titre, une méta-description et une URL canonique uniques sur chaque page
• Balises Open Graph et image de partage sur chaque page publique
• Un seul h1 par page, de vrais liens <a href>, un texte alternatif sur les images
• Un sitemap.xml avec de vraies URL ; un robots.txt qui bloque les chemins de l'application et de l'API
• Données structurées uniquement pour le contenu visible, et testées
• LCP, INP et CLS dans la plage « bon » sur mobile
• Site sur son domaine définitif, en HTTPS, et soumis à la Search Console

Adopter votre propre domaine avant de commencer à viser du trafic de recherche évite des redirections plus tard — voir comment connecter un domaine personnalisé. Pour le processus de construction global, lisez comment construire un site web avec l'IA, et pour les pages destinées à convertir des visiteurs, comment créer une page de destination qui convertit.

Le SEO sur Mythex

Mythex ne dispose pas de panneau SEO séparé ; vous améliorez le SEO en modifiant l'application par le chat ou par le code. Les nouvelles applications web utilisent par défaut une application monopage Vite et React, donc si la recherche compte, demandez dès le départ un site statique ou pré-rendu, ou Next.js. La documentation propose une consigne type pour les titres, les balises Open Graph, le plan de site et robots.txt dans Le SEO de votre application, et les sites statiques traite des sites centrés sur le contenu. Après les modifications, publiez à nouveau pour que le site en ligne les prenne en compte. Les domaines personnalisés sont disponibles avec Pro.

Questions