Pourquoi intégrer des FAQ à vos pages programmatiques

Un bloc FAQ a sa place sur une page programmatique quand ses réponses changent avec les données de la page. Si les cinq mêmes réponses figurent sur toutes vos pages, supprimez le bloc : vous ajoutez du texte dupliqué qui ne sert à personne.

Bien fait, c’est l’un des moyens les moins coûteux que je connaisse pour rendre une page générée plus utile. Une question et sa réponse forment une petite unité pilotable depuis une base de données. C’est pour cela que les FAQ textuelles se situaient en haut de la fourchette sur le projet Deux.io, où les variables allaient de 100 à plus de 2 500 déclinaisons.

Ce qu’un bloc FAQ apporte encore à une page générée

Commencez par oublier l’ancienne promesse. Depuis août 2023, Google réserve les résultats enrichis FAQ aux sites gouvernementaux et de santé reconnus et faisant autorité, et les résultats enrichis HowTo ont été supprimés. Un site commercial ne doit pas s’attendre à voir un accordéon sous son résultat, et personne ne devrait vous vendre un projet FAQ sur cet argument.

Les raisons qui restent valent mieux de toute façon. Un visiteur qui arrive sur une page de longue traîne a souvent un dernier doute avant d’agir, et une bonne réponse le lève sur place. La formulation en questions colle aussi à la façon dont les gens rédigent leurs recherches précises : chaque réponse apporte un vocabulaire autour du sujet que votre gabarit principal ne contiendrait jamais.

Les réponses générées par IA ajoutent une raison plus récente. Ces systèmes consomment des passages de pages, et une réponse courte qui nomme le lieu et donne le chiffre se comprend toute seule. Je ne peux pas vous promettre une citation, mais un paragraphe vague ne leur offre rien d’exploitable.

Reste le support. Chaque question récurrente traitée sur la page, c’est un ticket simple de moins, et plus de temps pour les cas difficiles. Classez vos tickets par sujet avant le lancement pour vérifier cet effet sur vos propres chiffres.

Trouver les questions que les gens posent vraiment

Pour la suite de ce chapitre, disons que vous gérez un annuaire d’espaces de coworking couvrant 2 000 villes, avec une page par ville. Je collecterais les questions à ces endroits :

• Les appels, e-mails et chats du support, qui contiennent la formulation exacte des doutes réels.
• Les commentaires et messages privés sur les réseaux sociaux.
• Les requêtes de la Search Console. Dans le rapport Performances, ajoutez un filtre de requête par expression régulière, par exemple ^(comment|quel|quelle|quels|quelles|combien|pourquoi|est-ce)\s.
• Les termes saisis dans votre moteur interne, depuis Google Analytics ou vos propres logs.

Regroupez ce que vous récoltez par thème. Pour le coworking, cela peut donner les tarifs, la réservation, l’accès et les équipements. N’ajoutez des sous-thèmes que lorsqu’un groupe devient trop long à parcourir. Ces groupes décident quelles questions se côtoient sur la page, ce qui rend le bloc plus lisible et garde le vocabulaire proche pour les moteurs de recherche.

Triez ensuite chaque question dans l’une de ces deux piles. Celles dont la réponse dépend de la ville vont dans le bloc programmatique. Celles dont la réponse est la même partout (« comment annuler une réservation ? ») vont sur une page d’aide unique, reliée depuis le gabarit. Ce tri est la décision la plus utile de tout l’exercice.

Stocker chaque question avec une condition d’affichage

Chaque question a besoin d’un modèle, d’un modèle de réponse et d’une règle qui dit quand une page peut l’afficher. Les variables viennent de la même base de données que le reste de la page.

Catégorie	Modèle de question	Modèle de réponse	Afficher si
Tarifs	Combien coûte un pass journée à {city} ?	À {city}, les pass journée démarrent à {min_day_price} parmi les {space_count} espaces référencés, avec une médiane de {median_day_price}.	space_count >= 3
Quartiers	Quels quartiers de {city} comptent le plus d’espaces de coworking ?	À {city}, la plupart des espaces se trouvent à {top_area_1} et {top_area_2}.	top_area_2 renseigné
Accès	Peut-on travailler la nuit à {city} ?	À {city}, {night_access_count} espaces proposent un accès 24 h sur 24, dont {night_access_example}.	night_access_count > 0
Réservation	Peut-on louer une salle de réunion à l’heure à {city} ?	Oui. À {city}, {hourly_room_count} espaces louent des salles à l’heure, à partir de {min_room_price}.	hourly_room_count > 0

La dernière colonne fait le travail de qualité. Une petite ville avec deux espaces n’a pas de médiane qui ait du sens, elle saute donc cette question, et trois vraies réponses valent mieux que six réponses remplies à la va-vite. Effet secondaire appréciable : l’ensemble des questions varie désormais d’une ville à l’autre, en plus des valeurs.

C’est ici que la politique de Google sur l’abus de contenu à grande échelle, introduite en mars 2024, s’applique directement. Produire en masse des pages à faible valeur l’enfreint, quelle que soit la façon dont le texte a été créé, et demander 2 000 fois à un modèle de langage « une FAQ sur le coworking à {city} » produit exactement cela. Si vous utilisez l’IA ici, faites-lui formuler des réponses autour de données que vous détenez, et relisez vous-même un échantillon du résultat.

Écrire des réponses qui tiennent toutes seules

La première phrase d’une réponse doit répondre. « Le suivi de commande est une part importante de notre service » n’apprend rien au lecteur. « Pour suivre votre commande, connectez-vous à votre compte, ouvrez Mes commandes et cliquez sur Suivre ma commande » lui donne le chemin.

Nommez la ville ou le produit dans la réponse plutôt que d’écrire « ici » ou « là-bas », car un passage peut être lu hors contexte. La plupart des réponses tiennent en deux ou trois phrases. S’il y a davantage à dire, faites un lien vers la page qui va plus loin.

Afficher le bloc une seule fois dans le gabarit

Webflow, WordPress et n’importe quel générateur statique savent faire cela avec une collection CMS ou une base de données qui alimente un bloc réutilisable. Voici la version Astro. L’élément <details> fonctionne sans JavaScript et les réponses restent dans le HTML pour les robots.

---
// faqs: [{ q, a }], déjà filtrées avec show_when pour cette page
const { city, faqs } = Astro.props;

const jsonLd = {
  "@context": "https://schema.org",
  "@type": "FAQPage",
  mainEntity: faqs.map(({ q, a }) => ({
    "@type": "Question",
    name: q,
    acceptedAnswer: { "@type": "Answer", text: a },
  })),
};
---
<section>
  <h2>Questions sur le coworking à {city}</h2>
  {faqs.map(({ q, a }) => (
    <details>
      <summary>{q}</summary>
      <p>{a}</p>
    </details>
  ))}
</section>

<script
  type="application/ld+json"
  set:html={JSON.stringify(jsonLd).replace(/</g, "\\u003c")}
></script>

Je garde le balisage FAQPage parce qu’il coûte une boucle et décrit clairement le contenu aux machines, sans attendre de résultat enrichi en retour. Ne balisez que les questions visibles sur la page, et construisez les deux à partir du même tableau pour qu’ils ne puissent pas diverger. Le chapitre sur les microdonnées explique comment cela cohabite avec vos autres types.

Offrir d’autres chemins vers la réponse

Dès que vous avez beaucoup de questions, une barre de recherche interne avec autocomplétion aide à trouver la bonne. Conservez ce que les gens tapent, y compris les recherches sans résultat : ce journal devient la liste de vos prochaines questions.

Certaines réponses passent mieux en image qu’en texte. Une capture annotée éclaire une procédure confuse, et une courte vidéo convient à tout ce qui comporte plusieurs étapes. Sur Derrick, j’ai intégré des vidéos directement dans les pages générées.

Garder des réponses exactes

Les réponses issues des données se mettent à jour avec elles, tant que votre build tourne. Les modèles et la page d’aide, eux, ne bougent pas seuls : prévoyez une revue récurrente avec le support, le marketing et le produit, et confrontez la formulation à tout changement d’offre ou de politique. Entre deux revues, les nouvelles préoccupations apparaissent d’abord au support et sur les réseaux sociaux, alors demandez à quelqu’un de les faire remonter.

Votre prochaine étape : exportez trois mois de requêtes Search Console avec le filtre, ajoutez vos derniers tickets de support et gardez les questions dont la réponse varie selon la page. Rédigez les modèles et les conditions d’affichage des cinq premières, puis testez-les sur votre page la plus pauvre avant de toucher au gabarit.