Le site Next.js généré par IA : pourquoi il a l'air familier, et ce qui est rendu où

Next.js est un framework, pas un design. L'allure familière vient de ce qu'on empile dessus par défaut.

• La même stack de départ. Next.js avec Tailwind et shadcn/ui est la réponse la plus courante d'un modèle, donc les composants, les espacements et l'arrondi se répètent d'un site à l'autre.
• Les restes du kit de démarrage. La police du kit, un titre générique et une description vide survivent étonnamment souvent jusqu'en production.
• Une seule landing page pour tout. Une seule route porte tout l'argumentaire, écrit pour un visiteur moyen, au lieu d'une page par question que les gens posent vraiment.
• La voix SaaS moyenne : « Livrez plus vite », « Conçu pour les équipes modernes », « Commencez gratuitement ». Correct, irréprochable, et sur toutes les autres pages.

Chacun de ces points se règle en quelques minutes dans le code.

IntentGrid réécrit les mots qu'un visiteur lit : titres, corps de texte, descriptions de fonctionnalités et libellés des boutons, selon la façon dont ce visiteur est arrivé (source de trafic, campagne, ville approximative, appareil, langue, heure locale). Il adapte le texte que vous rendez déjà, et les noms de marque, les prix, les dates et les chiffres restent tels qu'ils sont écrits.

Il ne touche ni à votre dépôt, ni à vos composants, ni à votre build, ni à votre cache, et il n'a besoin d'aucune intégration framework. Il ne change pas le design, et ce n'est pas une source de trafic.

La partie qui fonctionne aujourd'hui est une démo qui affiche une copie réécrite de n'importe quelle URL publique dans un bac à sable sur intentgrid.ai ; l'adaptation sur votre propre domaine est en accès anticipé, mise en place site par site à la main. Comment ça marche explique la différence.

Dans l'App Router, les pages sont par défaut des composants serveur, rendus côté serveur ou pré-rendus au moment du build. Les composants marqués “use client” sont quand même d'abord rendus en HTML côté serveur, puis rendus interactifs dans le navigateur. Pour la plupart des pages Next.js, le texte est donc dans la réponse HTML, et la démo peut le réécrire.

Les exceptions comptent autant pour les robots que pour la démo : le texte récupéré dans le navigateur après le chargement de la page, les composants chargés avec le rendu serveur désactivé, et le contenu qui ne s'affiche qu'après un clic. La démo retire les scripts et voit la page telle qu'elle arrive au départ, ce qui correspond à peu près à ce que voit aussi un robot qui n'exécute pas le JavaScript.

Vous pouvez en faire une version maison. Lisez le paramètre d'URL utm_source dans la page, associez un titre à chacune de vos deux ou trois plus grosses sources, et retombez sur la version par défaut pour tous les autres, à la même URL. Les robots arrivent sans le paramètre et reçoivent la version par défaut.

Sachez ce que ça coûte. Lire les paramètres d'URL fait rendre la page à chaque requête au lieu de la servir comme un fichier construit à l'avance, ce qui convient à une landing page mais doit être un choix délibéré. Et chaque variante est du texte que vous maintenez désormais à la main. C'est à ce moment-là qu'un outil mérite sa place, et pas avant.

Même mise en page, mêmes prix, mêmes promesses. Chaque version n'utilise que ce que la page d'origine dit déjà : dans ce cas inventé, une installation par balise script, un fichier de configuration et, comme objectif affiché, moins de tickets au support.

Ce sont des changements de code, donc vous pouvez les faire avec l'outil d'IA qui a construit le site, quel qu'il soit.

• Changez le thème de shadcn/ui. Modifiez les variables CSS de couleur et d'arrondi pour que les composants cessent de ressembler à ceux de tout le monde.
• Remplacez la police du kit de démarrage avec next/font, et définissez un vrai titre et une vraie description par route avec l'API metadata.
• Découpez la longue page unique. Donnez à chaque vraie question sa propre route avec son propre titre, pour que les moteurs de recherche et de réponse puissent atterrir sur la réponse précise.
• Gardez le texte dans un seul fichier de contenu, séparé du JSX, pour que changer des mots soit une modification rapide plutôt qu'une chasse au trésor.
• Vérifiez le rendu avec curl. Récupérez votre URL depuis le terminal et cherchez votre titre dans la sortie. S'il manque, quelque chose n'est rendu que dans le navigateur.

La moitié design, et la raison pour laquelle tous les outils d'IA aboutissent à ces choix par défaut, sont traitées dans pourquoi les sites vibe codés se ressemblent.