Le site est en ligne. La page s’ouvre vite sur votre ordinateur. Le texte apparaît, les photos défilent, les filtres répondent et le formulaire fonctionne. Pourtant, dans Google, une partie du catalogue reste introuvable. Une page de service importante n’obtient presque aucune impression. Certaines nouveautés mettent des semaines à apparaître.
Ce décalage est déroutant parce que deux visiteurs peuvent recevoir une page différente à partir de la même adresse :
- votre navigateur charge le HTML, puis exécute les scripts et récupère des données ;
- Google doit d’abord découvrir l’URL, l’explorer, puis rendre la page avant de pouvoir en interpréter la version finale.
Google sait exécuter JavaScript. Le problème n’est donc pas « JavaScript contre SEO ». Le vrai sujet est plus pratique : le contenu utile, les liens et les consignes d’indexation sont-ils présents de manière assez fiable pour être découverts, rendus et compris ?
Une vitrine éclairée après la fermeture
Imaginez une boutique dont la vitrine est vide au passage du premier visiteur. Les produits arrivent quelques secondes plus tard par une porte latérale. Les clients patients les voient. Ceux qui sont pressés repartent. Un problème réseau ou un script bloqué laisse parfois la vitrine vide toute la journée.
Un site peut connaître le même scénario. Le serveur renvoie un squelette de page, puis le navigateur doit appeler une API pour obtenir le titre, le prix, la description, les variantes ou les liens. Google explique traiter les pages JavaScript en trois phases : exploration, rendu et indexation. Une page peut donc être accessible avec un code HTTP 200 sans que son contenu principal soit immédiatement disponible dans le HTML reçu.
Le rendu côté serveur ou le pré-rendu reste souvent utile : il fournit plus tôt une page exploitable aux utilisateurs, à Google et aux autres robots qui n’exécutent pas tous JavaScript. Ce n’est pas une obligation universelle, mais c’est un moyen de réduire les dépendances fragiles.
Les symptômes qui justifient un vrai contrôle
Une baisse de trafic ne prouve pas, à elle seule, un problème de rendu. En revanche, plusieurs indices réunis méritent une inspection :
La page existe pour l’équipe, mais pas dans l’index. Elle est accessible depuis un lien direct, tout en restant absente des rapports d’indexation ou d’une recherche très précise.
Le HTML initial contient peu de sens. Le titre métier, le descriptif, le prix ou les liens vers les pages filles n’apparaissent qu’après l’exécution d’un script.
Des composants deviennent parfois vides. Un carrousel, un configurateur, une liste de services ou un catalogue dépend d’un appel API qui échoue ou répond trop lentement.
Les liens ne sont pas de vrais liens. Google recommande des éléments HTML <a> avec un attribut href pour découvrir les URL. Une carte entière pilotée uniquement par un clic JavaScript peut fonctionner pour l’utilisateur sans offrir un chemin de découverte aussi robuste.
Plusieurs URL montrent presque la même chose. Les filtres, paramètres de campagne, tris, variantes et facettes créent des adresses concurrentes. Le sujet n’est alors plus seulement le rendu, mais le choix de la version canonique.
Google voit une autre page que vous. L’outil d’inspection d’URL montre un contenu rendu incomplet, une ressource bloquée, une balise noindex, une canonique inattendue ou un message d’erreur invisible dans votre navigation habituelle.
Ces signes concernent autant un site vitrine moderne qu’une boutique en ligne : listes de réalisations chargées dynamiquement, témoignages injectés depuis un service externe, pages locales générées depuis une base ou tarifs affichés par un configurateur.
Le diagnostic se fait en comparant trois versions
Un audit utile ne commence pas par remplacer le framework. Il prend quelques pages représentatives et compare trois états.
1. Ce que le serveur envoie
On vérifie le code HTTP, le titre, la meta description, la balise canonique, les directives robots, le contenu principal et les liens disponibles dans le HTML initial.
Une page d’erreur qui renvoie 200 peut être interprétée comme une *soft 404*. À l’inverse, une page saine bloquée par robots.txt ne pourra pas être rendue correctement si Google ne peut pas charger ses ressources essentielles.
2. Ce que le navigateur construit
On laisse les scripts s’exécuter, puis on regarde le DOM rendu, les appels réseau et les erreurs. Le contenu attendu apparaît-il toujours ? Les liens possèdent-ils une destination réelle ? Une bannière de consentement, un script tiers ou une erreur d’API empêche-t-il le chargement ?
Ce contrôle doit inclure un téléphone et une connexion moins confortable. Une page qui ne fonctionne que sur le poste rapide du développeur n’est pas robuste.
3. Ce que Google signale
L’inspection d’URL et les rapports Search Console aident à comparer l’URL déclarée et l’URL canonique choisie, la dernière exploration, l’état d’indexation et la page rendue. Un sitemap est utile pour signaler des URL, mais Google le décrit comme un signal canonique plus faible qu’une redirection ou qu’une balise rel="canonical".
L’objectif n’est pas de « forcer Google ». Il est de supprimer les contradictions : une URL dans le sitemap, une autre dans la canonique, une troisième dans les liens internes et une quatrième produite par les filtres.
Cas concret : le catalogue qui fabrique ses propres doublons
Prenons une boutique française qui vend du mobilier professionnel. Une même chaise peut être accessible par :
- sa page produit ;
- une URL filtrée par couleur ;
- une URL filtrée par matière ;
- une URL avec un paramètre de tri ;
- une URL issue d’une campagne publicitaire.
Pour le client, ces variantes sont pratiques. Pour le moteur, elles peuvent disperser les signaux et consommer du temps d’exploration. La réponse n’est pas de masquer toutes les facettes sans discernement. Il faut décider quelles combinaisons répondent à une vraie recherche, lesquelles doivent rester fonctionnelles sans devenir des pages SEO, et quelle URL représente la version principale.
Google recommande de ne pas envoyer des signaux contradictoires : par exemple, déclarer une URL dans le sitemap tout en donnant une autre canonique. Les redirections, les balises canoniques et les liens internes doivent raconter la même histoire.
Pour une boutique, ce travail rejoint directement la création et l’optimisation d’un site e-commerce : la navigation commerciale et l’architecture SEO ne doivent pas être conçues séparément.
Ce qu’il ne faut pas conclure trop vite
Un contenu rendu côté client n’est pas automatiquement invisible. Google utilise une version moderne de Chromium et peut indexer le HTML rendu. À l’inverse, une page entièrement générée côté serveur peut rester faible si elle est dupliquée, isolée, mal canonisée ou dépourvue de contenu utile.
Il faut également éviter trois réparations réflexes :
- ajouter toutes les URL au sitemap sans corriger les doublons ;
- bloquer les paramètres dans
robots.txten pensant régler la canonicalisation ; - refondre tout le site avant d’avoir isolé le défaut sur quelques gabarits.
Le bon niveau d’intervention peut être beaucoup plus ciblé : rendre le contenu principal dans le HTML initial, transformer des cartes cliquables en liens explorables, stabiliser un appel API, corriger une canonique, retirer une balise noindex héritée d’une préproduction ou limiter les facettes indexables.
Un contrôle en une matinée, avant un chantier de plusieurs semaines
Pour une PME, la première étape peut tenir sur un petit échantillon :
- une page d’accueil ou de catégorie ;
- une page de service stratégique ;
- une fiche produit ou réalisation ;
- une page qui n’apparaît pas dans Google ;
- une URL avec filtre ou paramètre.
Pour chacune, on consigne le statut HTTP, le HTML initial, le rendu final, le titre, la canonique, les directives robots, les liens entrants et la situation dans Search Console. Cette fiche permet de distinguer un incident ponctuel d’un problème de gabarit répété sur des centaines d’URL.
Elle permet aussi de prioriser selon le chiffre d’affaires potentiel. Une page de politique interne imparfaite n’a pas la même urgence qu’une catégorie commerciale absente, qu’un formulaire inaccessible sur mobile ou qu’une fiche produit dont le prix et la disponibilité ne sont jamais rendus.
Le design n’est pas en cause ; l’absence de preuve l’est
Un site peut être élégant et techniquement sain. Il peut aussi être élégant tout en demandant trop d’efforts au moteur pour retrouver son contenu. La différence ne se juge pas à l’œil nu.
Un audit SEO technique doit relier la présentation visible, le code reçu, le rendu et les signaux d’indexation. Chez 1Design, nous pouvons examiner un échantillon de gabarits, identifier les écarts reproductibles et proposer un plan court : corrections critiques, améliorations de structure, puis contrôle après mise en ligne.
Vous n’avez pas besoin de choisir entre un beau site et un site lisible par Google. Vous avez besoin que les deux versions racontent la même page.
Si des pages importantes restent absentes ou si une refonte a fait chuter leur visibilité, contactez 1Design avec trois URL concernées. Nous pourrons cadrer le diagnostic avant de proposer une modification plus large.
Vous voulez un site plus clair, plus crédible ou mieux pensé pour convertir ?