Le référencement d'un site EmDash : ce que le socle fait, et ce qu'il reste à faire
Rendu statique, balises, sitemap, données structurées, performances : ce qu'EmDash produit tout seul, et les cinq points qui restent à la charge de l'éditeur.
Un CMS ne référence pas un site. Il peut en revanche lui éviter la plupart des fautes techniques qui l’empêchent d’être exploré et compris. EmDash en évite beaucoup par construction — et il en laisse quelques-unes entièrement à votre charge, ce qui n’est pas toujours dit.
Ce guide fait le partage : ce que vous n’avez pas à faire, et ce que personne ne fera à votre place.
Ce que l’architecture règle d’elle-même
Le rendu, et la question du JavaScript
C’est l’avantage structurel le plus important, et il vient de l’intégration Astro décrite dans notre guide de l’architecture d’EmDash.
Les pages sont rendues côté serveur ou générées à l’avance. Le robot reçoit du HTML complet, avec le texte, les liens et les titres déjà présents dans la réponse. Il n’a pas à exécuter de JavaScript pour découvrir le contenu.
Cela paraît banal. Ce ne l’est pas : sur les architectures qui construisent la page dans le navigateur, l’indexation dépend d’une seconde passe de rendu, plus lente et moins fiable. Les contenus qui n’apparaissent qu’après exécution sont explorés tard, parfois mal. EmDash évite cette classe entière de problèmes sans que vous ayez à intervenir.
Les performances au chargement
Les pages servies depuis le réseau de diffusion de Cloudflare arrivent depuis un point proche du visiteur. Les temps de réponse sont bas et réguliers, y compris sous charge.
C’est un facteur d’expérience réel, et un facteur de crawl : un site lent est exploré moins souvent, parce que le robot ajuste son rythme au temps de réponse du serveur. Le détail de l’infrastructure est traité dans l’écosystème Cloudflare d’EmDash.
Les URL
Le routage produit des URL lisibles, stables, dérivées du slug du contenu. Pas de paramètres de requête, pas d’identifiants numériques.
Point important : le slug ne doit jamais changer après publication. Une URL modifiée est une URL perdue, avec l’historique qui va avec. Si un changement s’impose malgré tout, il faut poser une redirection permanente — le sujet est traité dans la migration WordPress et les redirections.
Le sitemap et le fichier robots
Le sitemap est généré à partir des collections de contenu et se met à jour à chaque publication. Le fichier robots.txt est servi et référence le sitemap.
Deux vérifications valent la peine après une mise en ligne : que le sitemap contient bien toutes les collections, et que les pages de brouillon en sont exclues. Un site à plusieurs collections — articles, guides, tutoriels — expose parfois un sitemap partiel si la configuration n’a pas été complétée.
Ce que le socle fait, à condition de le renseigner
Ici, l’outil fournit le mécanisme et attend vos données. Ne rien saisir ne produit pas d’erreur : cela produit un défaut silencieux.
Le titre et la description
Chaque contenu porte un title et une description repris dans les balises de la page. C’est le seul texte que vous contrôlez entièrement dans les résultats de recherche.
Les deux erreurs courantes : reprendre le titre éditorial tel quel alors qu’il dépasse la longueur affichée, et laisser la description vide, auquel cas le moteur compose lui-même un extrait, en général moins bon que ce que vous auriez écrit.
Visez un titre court et explicite, et une description qui dit le bénéfice concret plutôt qu’elle ne résume le plan.
La canonique
Elle est émise automatiquement et pointe vers l’URL de la page. C’est le comportement correct dans la quasi-totalité des cas.
Vérifiez cependant qu’elle correspond bien à l’URL réellement servie : un site accessible à la fois avec et sans www, ou en http et https, doit rediriger vers une forme unique. Sans quoi vous servez plusieurs URL pour un même contenu, ce qui dilue les signaux. La configuration se traite au niveau du domaine, comme l’explique mettre EmDash en production.
Les données structurées
EmDash émet le balisage correspondant au type de contenu, et les questions fréquentes déclarées en frontmatter produisent un balisage FAQPage.
C’est un point à connaître : les questions écrites dans le corps du texte ne sont pas balisées. Seules celles déclarées dans le frontmatter le sont. Une FAQ rédigée en ## dans le markdown reste un texte ordinaire.
Les images
Les images passent par le pipeline de traitement et sont servies dans des formats modernes, aux dimensions demandées.
Reste à votre charge le texte alternatif, qui n’est pas devinable. Il décrit ce que montre l’image, factuellement. C’est un point d’accessibilité avant d’être un point de référencement, et c’est aussi ce qui ouvre l’accès à la recherche d’images — un canal que beaucoup d’éditeurs négligent alors qu’il apporte un volume d’affichages non négligeable sur les sujets illustrables.
Ce qui reste entièrement à votre charge
Aucun CMS ne fait ces cinq choses. C’est là que se joue l’essentiel.
Le maillage interne
C’est le point le plus sous-estimé, et il a un effet mécanique direct sur ce qui est exploré.
Un robot découvre les pages en suivant les liens. Un contenu qui ne reçoit aucun lien depuis une page régulièrement explorée peut rester inconnu pendant des mois, même s’il figure au sitemap : le sitemap est une suggestion, pas une obligation d’exploration.
La conséquence pratique est simple : vos contenus doivent être atteignables en peu de clics depuis l’accueil, et les pages qui reçoivent le plus de visites du robot — l’accueil, les index de collection — doivent pointer vers ce que vous voulez faire découvrir. Une arborescence profonde, où les contenus ne sont liés que depuis d’autres contenus eux-mêmes peu explorés, produit des pages orphelines de fait.
Ce maillage se joue en grande partie dans les mécanismes de structure du site — menus, archives de taxonomie, encarts de zones de widgets — dont nous détaillons le partage des rôles dans le guide menus, taxonomies et zones de widgets. Une archive par étiquette ouverte à l’exploration a d’ailleurs l’effet inverse de celui qu’on cherche : elle multiplie les pages quasi vides.
La structure du contenu
Un seul h1 par page, une hiérarchie de titres cohérente, des sections qui répondent à une question identifiable. Le markdown vous laisse écrire ce que vous voulez, y compris une structure incohérente.
La profondeur réelle
Un CMS ne peut pas juger si votre page apporte quelque chose. C’est la seule variable qui décide sur le long terme, et elle ne se délègue pas.
Le suivi
Déclarer le site auprès des moteurs, soumettre le sitemap, surveiller ce qui est exploré et ce qui ne l’est pas. Sans ce retour, vous publiez à l’aveugle.
Les redirections
À chaque changement de structure, chaque suppression, chaque fusion de contenus. C’est le poste le plus oublié lors des refontes, et le plus coûteux.
Une liste de vérification avant mise en ligne
| Point | Comment vérifier |
|---|---|
| HTML complet sans JavaScript | Afficher le code source de la page, chercher le texte |
| Titre et description renseignés | Sur chaque contenu, pas seulement l’accueil |
| Canonique cohérente | Comparer avec l’URL servie |
| Une seule forme d’hôte | Tester avec et sans www, en http |
| Sitemap complet | Compter les URL, vérifier chaque collection |
| Brouillons exclus | Chercher un contenu non publié dans le sitemap |
| Textes alternatifs | Parcourir les images du corps |
| Profondeur de clic | Combien de clics depuis l’accueil vers le dernier contenu |
| Redirections en place | Tester quelques anciennes URL si migration |
Les points de sécurité et de durcissement qui accompagnent une mise en ligne sont traités séparément dans la sécurité des plugins, et la comparaison avec l’écosystème WordPress dans EmDash contre WordPress.