Créer un zoning de page optimisé

Un zoning est la carte des blocs de contenu que suivra un template : ce qui apparaît, dans quel ordre, alimenté par quelles données, et ce qui se passe quand ces données manquent. Je le fais avant tout travail visuel, parce qu’en SEO programmatique une décision se répète sur chaque page. Un bloc mal placé dans un article écrit à la main vous coûte une page. Sur un template, il vous les coûte toutes.

Le dernier point de cette définition est celui que la plupart des zonings oublient. Une page statique a un contenu connu. Une page générée peut afficher 40 offres ou 6, un salaire ou aucun, un nom de ville de 4 lettres ou de 25. Votre zoning doit tenir dans tous ces cas.

Les zones d’une page générée

Voici un zoning pour le site d’emploi illustratif que je suis depuis le chapitre sur les personas, pour le type de page derrière emploi {poste} {ville} :

Ordre	Zone	Contenu	Source de données	Si la donnée manque
1	Fil d’Ariane	Accueil, métier, ville	Tables métiers et villes	Toujours présent
2	En-tête	H1, résumé d’une phrase avec nombre d’offres et dernière mise à jour	Agrégats	Page non indexable sous le seuil
3	Offres	Dernières offres, filtres	Table des offres	Afficher les villes proches
4	Salaires	Salaire courant annoncé pour ce métier et cette ville	Agrégats de salaires	Masquer le bloc
5	Contexte local	Principaux employeurs, saisonnalité	Tables villes et employeurs	Masquer le bloc
6	CTA alerte	« Recevoir les offres de {poste} à {ville} par e-mail »	Statique avec variables	Toujours présent
7	FAQ	Trois à cinq questions traitées à partir des données	Agrégats, réponses rédigées	N’afficher que les questions qui ont une réponse
8	Liens associés	Même métier à proximité, autres métiers dans la ville	Graphe des pages éligibles	Ne lier que des pages indexables
9	Pied de page	Contact, mentions légales, sections clés	Statique	Toujours présent

Remplir la dernière colonne oblige à avoir la bonne discussion tôt. Ces règles sont la partie du template que développeurs et rédacteurs supposent le plus souvent traitée par l’autre camp.

Placez la réponse là où la requête l’attend

L’ordre découle de l’intention identifiée plus tôt. Quelqu’un qui cherche un emploi de commis de cuisine à Lyon veut des offres. Les offres montent donc en haut, avec seulement un court résumé au-dessus. La vieille habitude d’ouvrir sur un long bloc de « texte SEO » repousse l’utile vers le bas et n’aide personne. Une introduction d’une ou deux phrases qui donne les vrais chiffres apporte davantage au lecteur, et elle offre aux moteurs comme aux réponses générées par IA une affirmation claire à reprendre.

Les titres suivent le même ordre. Le H1 est unique sur chaque page et porte le pattern de requête. Les H2 marquent les zones, les H3 les subdivisions internes, et la taille visuelle d’un titre ne doit jamais décider de son niveau. Le chapitre sur le balisage HTML transforme ce plan en vraies balises.

Les médias ont leur place dans le contenu principal quand ils apportent quelque chose. Les pages de Derrick intégraient des vidéos, ce qu’un template de texte maigre ne pouvait pas offrir. Une photo de banque d’images répétée sur 3 000 pages ajoute du poids et rien d’autre.

Les zones de navigation, de conversion et de confiance

La navigation repose sur un menu clair et, pour les pages générées, surtout sur la zone de liens associés. C’est ce bloc qui connecte des milliers d’URL et les empêche de devenir orphelines. Je le conçois comme un problème de données, avec ses propres règles, que le chapitre sur le maillage interne passe en revue.

Les appels à l’action doivent se voir sans effort : une action principale par page, répétée une fois après le contenu principal si la page est longue, et collante sur mobile si l’action est la raison d’être de la page.

Les blocs d’engagement comme les avis, les témoignages et les FAQ valent le coup quand ils sont authentiques et précis. Gardez la FAQ pour ce qu’elle fait bien. Google a cessé d’afficher les résultats enrichis FAQ pour la plupart des sites en août 2023 : elle ne vous fera donc pas gagner de place dans les résultats. Elle répond tout de même à de vraies objections et fournit aux réponses générées par IA des paires question-réponse bien nettes. Le critère reste le même : répondez avec vos données ou supprimez la question.

Le pied de page porte le contact, les mentions légales et les liens vers les sections clés. Gardez-le léger et identique sur toutes les pages. Les données structurées n’ont pas de zone à elles : elles vivent dans le code et décrivent ce qui est visible dans les autres zones.

Comment je construis un zoning

Commencez par la SERP. Ouvrez les premiers résultats pour environ cinq variantes de votre pattern et listez leurs blocs dans un tableur, une colonne par concurrent. Vous verrez vite quelles zones sont attendues et lesquelles personne ne propose, et cette seconde liste est souvent celle qui fait votre avantage.

Passez ensuite au wireframe dans Figma ou Whimsical. Des rectangles gris suffisent. Le piège consiste à ne dessiner que la page idéale : je dessine donc au moins trois versions à partir de données réelles, la page la plus riche du lot, une page typique, et la plus pauvre qui passe encore votre seuil de publication.

Testez ces versions sur mobile avant le desktop, car les longues listes et les CTA collants s’y comportent très différemment. Une fois le prototype en place, Lighthouse donne une première lecture de la performance, de l’accessibilité et du SEO de base. Il ne vous dira pas si la page est utile, montrez-la donc aussi à quelqu’un qui correspond à votre persona.

Rendez les zones conditionnelles

Les templates programmatiques ont besoin de souplesse dans leur structure. Chaque zone devient un module réutilisable, alimenté par des données structurées, qui n’apparaît que s’il a quelque chose à montrer. Voici l’idée sous forme de composant Astro :

---
const { role, city, jobs, stats, nearby } = Astro.props;
const showPay = stats.salarySamples >= 20;
const showNearby = jobs.length < 10 && nearby.length > 0;
---
<h1>Emploi {role.name} à {city.name}</h1>
<p>{jobs.length} offres en ligne, mises à jour le {stats.updatedAt}.</p>

<ul>
  {jobs.map((job) => <li><a href={job.url}>{job.title}</a></li>)}
</ul>

{showPay && (
  <section>
    <h2>Salaire {role.name} à {city.name}</h2>
    <p>Salaire courant annoncé : {stats.medianPay}.</p>
  </section>
)}

{showNearby && (
  <section>
    <h2>Emploi {role.name} près de {city.name}</h2>
    <ul>
      {nearby.map((c) => <li><a href={c.url}>{c.name}</a></li>)}
    </ul>
  </section>
)}

Les seuils (20 salaires observés, moins de 10 offres) sont des exemples à adapter. L’affichage conditionnel remplit deux fonctions à la fois : il évite les blocs vides, et il rend les pages réellement différentes, puisque la structure d’une page dépend désormais de ce qu’on sait de ce métier dans cette ville.

La même logique fonctionne hors du code. Webflow propose la visibilité conditionnelle sur les éléments liés au CMS, et WordPress ou un CMS sur mesure peuvent la piloter par la logique de template, avec des API et des scripts pour produire les variantes. Sur Deux.io, les variables allaient de 100 à plus de 2 500 variations selon l’élément, et c’est ce qui évitait aux pages de ressembler à des copies les unes des autres.

Fixez une dernière règle à ce stade. Décidez quelles zones sont obligatoires pour qu’une page existe. Si les offres ou les chiffres de l’en-tête ne peuvent pas être renseignés, la page ne sort pas ou reste en noindex. Retirer un bloc raccourcit une page, et passé un certain point une page raccourcie n’a plus rien à offrir. La politique de Google sur le contenu à grande échelle vise ce genre de page.

Votre prochaine étape

Copiez le tableau ci-dessus dans un tableur et réécrivez-le pour votre pattern validé : les zones dans l’ordre, la source de données de chacune, et une règle en cas de donnée manquante. Dessinez à partir de lui vos pages réelles la plus riche et la plus pauvre. Quand les deux ont encore du sens pour un lecteur, votre zoning est prêt à devenir du balisage.