# Mettre en place le rendu côté serveur d’un thème pour préserver l’indexation

> Un thème vitrine construit avec une application React embarquée affichait une page quasiment vide aux robots peu patients. Le pré-rendu côté serveur a réglé le problème.

- Auteur : Clément Hadrot
- Publié le : 2023-06-29
- Mis à jour le : 2023-06-29
- Catégorie : SEO & GEO
- URL : https://wpmoderne.dev.wordpress-developpement.fr/seo/rendu-cote-serveur-theme-preserver-indexation/

## L’essentiel

- Un contenu injecté uniquement en JavaScript reste un pari sur la patience du moteur
- Un pré-rendu HTML statique servi au premier chargement supprime ce pari
- Le contenu dynamique peut ensuite s'hydrater sans pénaliser l'indexation

Un studio de design avait développé un thème vitrine où la page d'accueil et les pages de portfolio étaient entièrement rendues par une petite application React embarquée dans le thème, communiquant avec WordPress via l'API REST. Le résultat visuel était soigné, les animations fluides, mais un audit d'indexation a révélé que Google indexait ces pages avec un contenu textuel quasiment vide : seul le conteneur HTML vide livré par le serveur était visible avant l'exécution du script.

Ce cas ne couvre que la mise en place du rendu côté serveur pour préserver l'indexation d'un thème existant. L'architecture headless complète, avec un WordPress purement API et un frontend totalement découplé, est traitée dans un article séparé, plus large.

## Comprendre pourquoi Google voit une page vide

Googlebot est capable d'exécuter du JavaScript, mais ce rendu se fait dans une file d'attente distincte du crawl initial, avec un délai variable qui peut aller de quelques secondes à plusieurs jours selon la charge du moteur. Sur ce projet, l'outil d'inspection d'URL de Search Console, dans son onglet « Capture d'écran », montrait effectivement un rendu final correct après exécution du JavaScript. Le problème résidait ailleurs : le contenu HTML brut initial, celui que d'autres systèmes (comme les aperçus de partage sur les réseaux sociaux ou certains robots tiers) utilisent sans exécuter de JavaScript, restait vide, et le délai de rendu différé pesait sur la fraîcheur perçue du contenu par Google lors des mises à jour fréquentes du portfolio.

## Étape 1 : identifier le point d'entrée du rendu

> L'essentiel à retenir : Un contenu injecté uniquement en JavaScript reste un pari sur la patience du moteur ; Un pré-rendu HTML statique servi au premier chargement supprime ce pari ; Le contenu dynamique peut ensuite s'hydrater sans pénaliser l'indexation

Le thème chargeait son application React via un simple conteneur vide dans le gabarit :

```
<div id="app-portfolio"></div>
<script src="<?php echo get_theme_file_uri( 'build/app.js' ); ?>"></script>
```

## Étape 2 : générer le HTML côté serveur avec Node

Plutôt que de réécrire l'application entière, un service Node léger a été mis en place pour effectuer le rendu serveur de l'application React (via `ReactDOMServer.renderToString`) et le renvoyer à WordPress sous forme de HTML statique, appelé depuis PHP au moment de la génération de la page :

```
add_filter( 'the_content', function( $content ) {
    if ( ! is_singular( 'portfolio' ) ) {
        return $content;
    }
    $rendu = wp_remote_get( 'http://localhost:4000/render/' . get_the_ID(), array(
        'timeout' => 2,
    ) );

    if ( is_wp_error( $rendu ) ) {
        return $content; // repli sur le contenu existant en cas d'échec du service de rendu
    }
    return wp_remote_retrieve_body( $rendu );
} );
```

Le délai de timeout fixé à deux secondes et le repli automatique sur le contenu existant en cas d'échec sont volontaires : un service de rendu externe qui tombe en panne ne doit jamais faire planter l'affichage du site pour ses visiteurs humains, même au prix d'une dégradation temporaire vers un contenu moins riche.

## Étape 3 : mettre en cache le rendu généré

Appeler le service Node à chaque requête aurait ajouté une latence inacceptable. Le HTML généré est mis en cache via l'API Transients de WordPress, invalidé automatiquement à chaque mise à jour de l'article concerné :

```
add_action( 'save_post_portfolio', function( $post_id ) {
    delete_transient( 'rendu_ssr_' . $post_id );
} );
```

## Étape 4 : vérifier le contenu réellement livré

Le contrôle final consiste à demander le contenu brut de la page sans exécuter de JavaScript, exactement comme le ferait un robot pressé :

```
curl -s https://exemple.fr/portfolio/campagne-hiver/ | grep -A 3 "app-portfolio"
```

Le contenu textuel du portfolio doit apparaître directement dans cette sortie, sans dépendre de l'exécution du script React.

## Le résultat

> Une fois l'hydratation React branchée sur ce HTML pré-rendu plutôt que de le remplacer entièrement au chargement, l'interactivité visuelle initiale du site est restée intacte pour les visiteurs, tout en donnant à Google un contenu texte complet dès la première requête.

## En résumé

Un rendu entièrement côté client reste un pari sur la patience et la disponibilité de la file de rendu JavaScript de Google. Ajouter une couche de rendu serveur, même partielle et mise en cache, retire ce pari de l'équation sans sacrifier l'expérience interactive construite par l'équipe de développement front-end.