# Concevoir un WordPress crawlable aussi bien par Google que par une IA

> Plutôt que de traiter le SEO et le GEO comme deux chantiers séparés, voici l'architecture retenue pour un site pensé dès le départ pour les deux publics de robots.

- Auteur : Clément Hadrot
- Publié le : 2026-08-18
- Mis à jour le : 2026-08-18
- Catégorie : SEO & GEO
- URL : https://wpmoderne.dev.wordpress-developpement.fr/seo/architecture-wordpress-crawlable-google-et-ia/

## L’essentiel

- Une seule architecture peut servir les deux publics sans compromis majeur
- Le rendu serveur reste le socle commun indispensable
- La séparation ne se joue pas sur le contenu mais sur le cache et l'exposition

Pour le lancement d'un site de ressources pédagogiques destiné aux enseignants, le client a posé une contrainte inhabituelle dès le brief initial : le site devait être pensé, dès sa conception, pour être aussi bien crawlé par Google que par les robots des moteurs de réponse génératifs, sans que l'un des deux publics ne soit traité comme une réflexion après coup. Ce billet ne traite pas du cache spécifique aux robots IA, déjà couvert par ailleurs, mais de l'architecture globale du site qui rend cette double exposition possible sans compromis.

## Le socle commun : tout doit exister sans JavaScript

La première décision structurante, qui conditionne tout le reste, a été de garantir que chaque page rende son contenu principal entièrement côté serveur, via les templates PHP classiques de WordPress et la boucle `WP_Query`, sans aucune dépendance à une hydratation JavaScript pour l'affichage du texte, des titres ou des données structurées. Cette contrainte sert autant Googlebot, qui exécute le JavaScript mais avec un budget de rendu limité, que les robots IA, dont une bonne partie ne l'exécute pas du tout.

## L'arborescence retenue

```
racine/
├── robots.txt                → autorise le crawl, référence le sitemap
├── llms.txt                  → sommaire en langage naturel des sections clés
├── sitemap.xml                → généré nativement par WordPress depuis 5.5
├── wp-json/
│   └── wp/v2/...             → API REST exposée en lecture pour les ressources publiques
└── templates de contenu
    ├── single-ressource.php   → rendu serveur complet, données structurées incluses
    ├── archive-ressource.php  → listes paginées, liens de pagination explicites
    └── page-sommaire.php      → pages piliers par discipline enseignée
```

## Où la différenciation intervient réellement

> L'essentiel à retenir : Une seule architecture peut servir les deux publics sans compromis majeur ; Le rendu serveur reste le socle commun indispensable ; La séparation ne se joue pas sur le contenu mais sur le cache et l'exposition

Contrairement à une idée reçue, servir les deux publics ne signifie pas dupliquer le contenu ou créer des gabarits de page distincts selon le visiteur. Le contenu affiché reste rigoureusement identique, qu'il soit lu par un enseignant, par Googlebot ou par un robot associé à un moteur de réponse. La différenciation se joue ailleurs, à deux niveaux précis : la stratégie de cache, adaptée au comportement par rafales des robots IA sans changer le contenu servi, et l'exposition contrôlée de certaines ressources via l'API REST pour les usages qui le justifient, en plus du HTML classique.

## Les données structurées comme langage commun

Le balisage Schema.org (`LearningResource`, `BreadcrumbList`, `Article` selon les gabarits) a été traité comme un langage commun aux deux publics plutôt que comme une couche ajoutée pour l'un ou pour l'autre. Googlebot s'en sert pour générer des résultats enrichis ; un robot IA s'en sert pour clarifier la nature exacte du contenu (une fiche pédagogique n'est pas un article de blog, la distinction compte pour la fiabilité perçue de l'information).

### Vérification croisée effectuée avant lancement

1. Test du rendu HTML brut de chaque gabarit via `curl`, sans JavaScript, pour confirmer la présence de tout le contenu attendu.
2. Validation du balisage Schema.org pour chaque type de page avec l'outil de test de résultats enrichis.
3. Simulation d'un pic de crawl via un script de charge reproduisant le comportement par rafales observé chez des robots IA connus, pour vérifier la tenue du cache.
4. Vérification manuelle du fichier `llms.txt` par une personne extérieure au projet, pour juger de sa clarté sans connaître le site à l'avance.

## Ce qui a failli être un mauvais compromis

> Une tentation écartée en cours de route : ajouter un mode de rendu simplifié spécifiquement pour les robots, détecté par user-agent. Ce choix aurait créé deux versions du site à maintenir, avec le risque réel de les voir diverger avec le temps. Un seul rendu, servi à tout le monde, reste plus sûr et plus simple à maintenir.

## Résultat après le lancement

| Indicateur | Constat après trois mois |
| --- | --- |
| Couverture d'indexation Search Console | Aucune page stratégique exclue |
| Passages de robots IA identifiés | Réguliers dès le premier mois, sans pic destructeur |
| Charge serveur en période de pic de crawl | Stable, grâce à l'architecture de cache dédiée |

## Notre verdict

Concevoir un site pour les deux publics de robots ne demande pas une architecture double, mais une discipline unique appliquée dès le départ : un rendu serveur complet, un balisage honnête et cohérent, et une gestion du cache qui absorbe des comportements de crawl différents sans jamais toucher au contenu lui-même. C'est cette discipline, plus qu'un outil ou un plugin particulier, qui a permis à ce site de bien démarrer sur les deux fronts en même temps.