SEO programmatique : quand ça marche, quand ça nuit

En bref

• Générer des pages en série n’est pas un problème en soi : Google sanctionne les pages produites pour manipuler le classement, sans valeur pour le lecteur.
• Une page programmatique tient quand elle porte une donnée réelle, introuvable sous cette forme ailleurs : un prix, une surface, une disponibilité.
• Le vrai piège d’un catalogue vivant est ce qui en sort : un bien disparu répond 410 avec des alternatives utiles, jamais une page en 200 ni une redirection vers l’accueil.
• Chaque langue se vérifie à part, gabarits, accords et liens compris, sinon une erreur se répète sur des milliers de pages.

Ce que recouvre le SEO programmatique

Le SEO programmatique, c’est fabriquer des pages en série à partir d’une base de données et d’un gabarit. Une fiche par produit, une page par ville, une page par combinaison catégorie et lieu, le tout dans plusieurs langues. Un catalogue de quelques centaines d’éléments devient vite plusieurs milliers d’adresses.

L’idée n’a rien de suspect : c’est ainsi que fonctionnent tous les sites de petites annonces, de voyage ou de commerce en ligne. Ce qui est suspect, c’est l’usage qu’en font certains : produire des pages pour les mots-clés plutôt que pour les gens. Google a une règle écrite à ce sujet. Sa politique anti-spam définit l’abus de contenu à grande échelle comme le fait de générer de nombreuses pages dans le but principal de manipuler le classement plutôt que d’aider les utilisateurs. Parmi ses exemples : générer beaucoup de pages avec des outils d’IA sans valeur ajoutée, assembler du contenu récupéré ailleurs, y compris par traduction automatique, ou créer des pages qui n’ont pas de sens pour un lecteur mais contiennent des mots-clés.

La frontière ne passe donc pas entre « généré » et « écrit à la main ». Elle passe entre une page qui sert une donnée utile et une page qui ne sert qu’à exister.

Notre terrain : un catalogue immobilier en six langues

Palmora Property est notre propre site d’agence immobilière à Phuket. Son catalogue de biens est synchronisé chaque jour depuis le CRM de l’agence et publié dans six langues : anglais, français, thaï, russe, chinois et allemand. Avec les pages de catégories et les pages par zone, elles aussi en six langues, le site déclare plus de 3 000 adresses.

Rien de ce volume n’est écrit à la main. Et c’est en le faisant tourner que nous avons appris ce qui distingue un catalogue programmatique sain d’une usine à pages.

Ce qui marche : une donnée réelle par page

Une fiche de bien répond à une recherche précise, avec des informations que le visiteur ne trouvera pas sous cette forme ailleurs : prix, surface, zone, photos, disponibilité. La page existe parce que le bien existe. C’est le cas le plus sain du programmatique : la base de données est la raison d’être de la page, pas un prétexte. C’est aussi ce que les moteurs génératifs reprennent le plus volontiers, une donnée précise et vérifiable, comme nous l’expliquons dans l’article sur la façon d’être cité par ChatGPT.

Les pages de liste par zone sont plus délicates. Notre audit du 22 juillet le disait sans détour : chaque page avait un titre et une description uniques, avec le nombre de biens de la zone, mais aucun contenu éditorial, aucun sous-titre, et un titre principal réduit au nom de la zone. Ce sont pourtant ces pages qui répondent aux requêtes les plus commerciales. Une liste de cartes sans un mot de contexte reste une page mince.

Nous avons donc écrit un contenu éditorial pour huit zones (Rawai, Chalong, Bang Tao, Cherng Talay, Patong, Kata, Karon, Thalang) : le marché, les quartiers, les zones voisines, des liens vers les articles du blog. Il est rédigé en anglais puis traduit dans les autres langues avec un modèle d’IA, mais avec une règle : les liens vers les articles ne sont jamais traduits par la machine. Ils sont reconstruits à partir des vrais articles de chaque langue, et un article qui n’existe pas dans une langue est simplement retiré. Une page traduite qui pointe vers un article inexistant, c’est exactement le contenu « qui n’a pas de sens pour un lecteur ».

Ce qui marche aussi : des gabarits vraiment localisés

Un gabarit multilingue ne se résume pas à traduire des mots. Le piège classique : fabriquer le titre en collant le type de bien et le contrat, ce qui donne « Villas Zu verkaufen » en allemand, et laisser les balises de titre et de description en anglais dans les langues qu’on ne lit pas. Rien de tout cela ne se voit en relisant la version française.

La parade consiste à sortir ces textes du code. Sur Palmora, chaque langue a ses gabarits de titre, de description et de message de liste vide, avec les formes du nom par type de bien. L’accord avec un nombre aussi : le russe a trois formes selon le chiffre, et le compteur de résultats applique la même règle à l’affichage initial et après un changement de filtre. Même exigence pour les titres des biens, qui sont traduits pour de vrai et non recopiés en anglais dans les autres langues.

Une langue ne se limite pas non plus à ses routes. Une table de textes oubliée suffit à servir une page vide avec un code 200, que personne ne remarque. Il faut chercher partout où une liste de langues est écrite en dur, et tester chaque langue, page par page.

Ce qui nuit : les pages qui meurent mal

Le vrai piège d’un catalogue vivant, c’est ce qui en sort. Chaque bien vendu ou dépublié disparaît des données, donc sa page disparaît. Mais l’adresse reste indexée, partagée, enregistrée en favori. Sans traitement, elle tombe en 404 brut, et les 404 s’accumulent dans Search Console à mesure que le catalogue tourne.

Les réponses habituelles ne conviennent pas :

• Une jolie page en 200 qui dit « ce bien n’est plus disponible » : c’est un soft 404 pour Google, une nouvelle erreur dans la console.
• Une redirection 301 bien par bien : il n’y a pas de cible fiable, le bien n’existe plus, et une table de redirections à maintenir finit toujours par pointer dans le vide.

Ce que nous avons mis en place : toute adresse d’un bien disparu répond 410, qui signifie « parti définitivement », avec une vraie page utile dans la langue de l’adresse. Elle propose six biens similaires, par paliers : même zone, même type et même contrat dans une fourchette de prix de plus ou moins 20 % du dernier prix connu, puis en élargissant. La mémoire des biens disparus est tenue par la synchronisation quotidienne, et un bien remis en ligne en sort automatiquement. Pour les biens en « prix sur demande », qui n’ont pas de prix de référence, la page se replie sur la zone et le type.

Deux autres pièges du même ordre, à vérifier sur tout catalogue :

• Les adresses inconnues renvoyées vers l’accueil. Rediriger une catégorie invalide vers la page d’accueil transforme chaque adresse cassée en redirection de plus dans la console. Une adresse inconnue doit répondre 404.
• La page 404 dans la mauvaise langue. Après une réécriture interne vers la page d’erreur, un site qui lit la langue sur l’adresse de la page d’erreur, et non sur celle demandée, sert une 404 anglaise dans toutes les langues.

Ce qui nuit aussi : des signaux qui mentent

Les sitemaps d’un site programmatique sont générés, donc ils peuvent se tromper en série. Notre audit de juillet en a trouvé trois : un sitemap d’actualités qui répondait 404 quand il était vide alors qu’il était déclaré dans le robots.txt, un index de sitemaps dont la date de modification valait l’heure de la requête, et aucune date sur les fiches de biens alors que le CRM connaît la date de mise à jour de chacune. Un moteur qui constate qu’une date ment apprend à l’ignorer. Les trois sont corrigés : sitemap vide en 200, index sans date fabriquée, et la vraie date de mise à jour sur chaque fiche.

Les liens de langue sont le même genre de signal. Un hreflang qui annonce une traduction inexistante, ou qui garde le chemin de la langue de départ, envoie le moteur vers une 404. Nous détaillons ces cas dans l’article sur les erreurs de hreflang.

Une dernière règle vaut pour tout contenu généré : rien ne se publie sans relecture humaine. Un texte produit par un modèle peut contenir une affirmation inventée, et à l’échelle d’un catalogue, une erreur de gabarit se répète sur des milliers de pages.

La règle que nous appliquons

Avant de générer une famille de pages, nous posons quatre questions :

1. Chaque page répond-elle à une recherche réelle, avec une donnée que le visiteur ne trouve pas sur la page voisine ?
2. Que se passe-t-il quand l’élément disparaît ? Un 410 utile, une 404 propre, jamais une redirection vers l’accueil ni une page vide en 200.
3. La page est-elle juste dans chaque langue, gabarits, accords et liens compris, et pas seulement traduite ?
4. Les signaux sont-ils vrais : dates des sitemaps, liens de langue, canoniques ?

Si une seule réponse est non, il vaut mieux générer moins de pages. C’est ce que vérifie un audit SEO sur un site de catalogue, et ce que notre moteur SEO et GEO surveille ensuite chaque semaine en production. Le programmatique n’est qu’une partie du travail : nous décrivons le reste dans ce qu’une agence SEO doit livrer à l’heure de l’IA, et les autres articles sur le sujet sont réunis sur la page SEO et visibilité dans les IA.

Questions fréquentes

Le SEO programmatique est-il pénalisé par Google ? Non en soi. Ce que Google sanctionne, c’est l’abus : beaucoup de pages produites dans le but principal de manipuler le classement, sans aider l’utilisateur. Un catalogue où chaque page porte une donnée réelle, à jour et utile n’est pas concerné. Le risque commence quand les pages se ressemblent toutes, n’apportent rien de plus que la page voisine ou n’existent que pour une variante de mot-clé.

Faut-il un 410 ou une 301 pour une fiche retirée ? Une 301 si une page la remplace vraiment, par exemple le même produit à une autre adresse. Sinon un 410, de préférence avec une page qui propose des alternatives proches, servie avec le bon code et jamais en 200. Rediriger toutes les fiches retirées vers l’accueil ou vers une catégorie revient à fabriquer des soft 404, que Google finit par traiter comme des erreurs.

Peut-on traduire automatiquement des pages générées ? Oui, si la traduction est relue sur ses gabarits et ses accords, et si les liens sont reconstruits à partir des pages qui existent vraiment dans chaque langue. Traduire pour multiplier les adresses, sans valeur pour le lecteur, est explicitement cité par Google parmi les abus. La bonne question n’est pas de savoir qui a traduit, mais à qui la page sert.