Le SEO technique concerne les conditions qui permettent à Google d'explorer, rendre, indexer et comprendre correctement les pages d'un site. Tant qu'elles ne sont pas réunies, le contenu et les liens ne comptent pas : ils n'ont pas été lus. Ce guide reprend les vérifications que nous faisons pendant nos audits, avec le correctif pour chacune, tel que nous l'avons implémenté sur ce site.
Chaque section sépare ce que Google documente, page Search Central à l'appui, de ce que nous recommandons, qui n'engage que nous.
Tous les problèmes techniques ne se valent pas
Cent constats à plat ne se corrigent pas. Nous classons chaque problème sur trois niveaux, et chaque section indique le niveau typique de ce qu'elle couvre.
- Bloquant : la page ne peut pas être vue ou comprise. Exemples : un gabarit entier interdit par robots.txt ou en noindex par erreur ; un site rendu côté client dont le HTML initial ne contient ni texte ni liens.
- Important : la page est vue, mais le signal est brouillé. Exemples : des chaînes de redirections héritées de deux refontes ; des paires hreflang non réciproques, ou une canonique qui contredit les liens internes.
- Optimisation : la page est correcte et peut faire mieux. Exemples : un balisage Article sans auteur ni dates ; un LCP dans l'orange sur mobile.
Un seul bloquant passe avant vingt optimisations.
1. Crawl et budget d'exploration impact : bloquant
Ce que Google documente. Le budget d'exploration est « l'ensemble des URL que Google peut et veut explorer » : une limite de capacité et une demande d'exploration. La page sur la gestion du budget d'exploration vise les grands sites, plus d'un million de pages ou plus de dix mille pages modifiées par jour, et liste ses bonnes pratiques : consolider les doublons, bloquer par robots.txt les URL inutiles, renvoyer 404 ou 410 pour les pages supprimées, tenir le sitemap à jour avec lastmod, éviter les longues chaînes de redirections.
Ce que nous recommandons. Un site de cent pages n'a pas de problème de budget, mais les mêmes règles lui donnent un signal net : une seule redirection par ancienne URL, jamais une chaîne ; un sitemap généré depuis les routes, jamais un fichier statique qui vieillit ; un robots.txt réduit aux zones réellement inutiles ; un vrai 404 pour ce qui n'existe plus.
Comment le vérifier
curl -sI https://votre-site.fr/ancienne-url doit renvoyer un seul 301 vers l'URL finale. Dans Search Console, « Statistiques sur l'exploration » donne les codes renvoyés à Googlebot et le rapport « Pages » liste les URL « avec redirection ». Les cas fréquents sont dans notre article sur les dix erreurs SEO techniques.
Comment le corriger
Une redirection serveur, directe, paramètres conservés ; un robots.txt qui ne liste que l'inutile.
# nginx : directement vers l'URL finale, jamais vers une URL qui redirige elle-même
location = /ancien-service {
return 301 https://votre-site.fr/seo-geo/nouveau-service$is_args$args;
}
# robots.txt : uniquement les zones inutiles à l'index
User-agent: *
Disallow: /admin/
Disallow: /api/
Sitemap: https://votre-site.fr/sitemap.xmlCe que nous avons fait sur seoforge.fr
Chaque ancienne URL de service est redirigée en 301 par un contrôleur dédié, paramètres conservés, et un test automatisé vérifie qu'aucune redirection n'en appelle une autre. Le sitemap est une route de l'application, construite depuis la carte du site ; la date lastmod d'une page vient de l'historique git de son gabarit, celle d'un article de son champ de mise à jour.
2. Indexation et canonicalisation impact : bloquant
Ce que Google documente. Sur la consolidation des URL en double : sans canonique déclarée, Google « identifiera quelle version de l'URL est objectivement la meilleure à montrer aux utilisateurs » ; l'annotation rel="canonical" est un signal parmi d'autres ; la page canonique doit porter la même canonique auto-référente ; une redirection permanente est « un signal fort » que la cible doit devenir canonique ; avec hreflang, la canonique doit être dans la même langue.
Ce que nous recommandons. Une seule forme d'URL par contenu : sans paramètre, sans slash final, sans www, avec le préfixe de langue, identique dans la canonique, le sitemap, les liens internes et le hreflang. Le noindex va dans la meta robots pour une page, dans l'en-tête X-Robots-Tag pour une réponse non HTML ou un fragment chargé en arrière-plan. Il n'agit que sur une page que le robot peut lire : jamais avec une interdiction robots.txt.
Comment le vérifier
Le rapport « Pages » de Search Console donne le motif de chaque exclusion ; « Google a choisi une URL canonique différente » se traite en premier. En ligne de commande : curl -s URL | grep -i canonical et curl -sI URL | grep -i x-robots-tag.
Comment le corriger
Une canonique absolue dans le head, un noindex là où il est voulu.
<!-- dans le head de chaque page indexable -->
<link rel="canonical" href="https://votre-site.fr/fr/guides/seo-technique">
<!-- page à exclure : meta robots -->
<meta name="robots" content="noindex, nofollow">
# réponse non HTML ou fragment chargé en arrière-plan : en-tête HTTP
X-Robots-Tag: noindex, nofollowCe que nous avons fait sur seoforge.fr
La canonique de chaque page est construite par un service unique à partir de la route : paramètres retirés, slash final retiré, https imposé, www supprimé, préfixe de langue toujours présent. Le sitemap et le hreflang utilisent la même forme. Les fragments de résultats de nos outils gratuits répondent avec X-Robots-Tag: noindex, et un test vérifie qu'aucune URL du sitemap ne porte cet en-tête.
3. Architecture et maillage interne impact : important
Ce que Google documente. Google « utilise les liens comme signal pour déterminer la pertinence des pages et pour trouver de nouvelles pages à explorer ». Il ne peut explorer un lien que s'il s'agit d'un élément a avec un attribut href, n'extrait pas de façon fiable les URL portées par des événements de script, et lit le texte d'ancre comme une information sur la page de destination (bonnes pratiques pour les liens).
Ce que nous recommandons. Une hiérarchie déclarée une seule fois, dont tout découle : chaque page a un parent, au plus trois niveaux depuis l'accueil, un fil d'Ariane visible et des liens HTML vers ses pages sœurs. Le maillage ne se maintient pas à la main : une liste « voir aussi » écrite dans les gabarits diverge en quelques mois. Les critères de la page elle-même sont dans notre checklist SEO on-page.
Comment le vérifier
Comparez les URL du sitemap aux pages atteintes par un crawl depuis l'accueil : la différence est vos pages orphelines. Le rapport « Liens » de Search Console classe vos pages par liens internes reçus.
Comment le corriger
Pas un lien ajouté à la main : une source unique de la hiérarchie, lue par la navigation, le fil d'Ariane et les blocs de pages liées.
# carte du site : un nœud par page, source unique du menu,
# du fil d'Ariane, des blocs « voir aussi » et de l'ordre du sitemap
audit_service:
parent: seo_geo
related: [seo_tech_guide, cwv_service, speed_tool]
<!-- rendu : un vrai lien, une vraie ancre -->
<nav aria-label="Fil d'Ariane"><ol>
<li><a href="/fr">Accueil</a></li>
<li><a href="/fr/seo-geo">SEO & GEO</a></li>
<li aria-current="page">Audit SEO technique</li>
</ol></nav>Ce que nous avons fait sur seoforge.fr
Toute la hiérarchie vit dans une carte thématique : un nœud par page, avec son parent, son hub et ses pages liées. Le menu, le fil d'Ariane et son balisage BreadcrumbList, les blocs « voir aussi » et l'ordre du sitemap en dérivent. Une commande reconstruit le graphe des liens internes et échoue si une page reçoit moins de trois liens de contenu, ou si un hub oublie un enfant.
4. Rendu et JavaScript impact : bloquant
Ce que Google documente. Google traite les applications JavaScript « en trois phases principales : exploration, rendu, indexation ». « Une fois que les ressources de Google le permettent, un Chromium headless rend la page et exécute le JavaScript » ; la page « peut rester dans cette file d'attente quelques secondes, mais cela peut prendre plus longtemps ». « Le rendu côté serveur ou le pré-rendu reste une excellente idée », plus rapide pour les utilisateurs et les robots, « et tous les robots ne peuvent pas exécuter JavaScript » (principes de base du SEO JavaScript).
Ce que nous recommandons. Contenu, titre, meta description, canonique et liens dans le HTML initial ; le JavaScript sert à l'interaction. Une application entièrement cliente passe par un rendu serveur ou un pré-rendu au déploiement. Une route inexistante renvoie un vrai 404, jamais une coquille en 200.
Comment le vérifier
curl -s URL | grep -c "<h1" doit trouver le titre sans exécuter de script. Dans Search Console, « Inspection de l'URL » puis « Tester l'URL en ligne » montre le HTML tel que Google l'a rendu.
Comment le corriger
Le contenu passe dans la réponse, le script n'ajoute que l'interaction.
<!-- coquille : rien à lire sans JavaScript -->
<body><div id="app"></div><script src="/app.js"></script></body>
<!-- rendu serveur : le contenu est dans la réponse, le script n'ajoute que l'interaction -->
<body>
<main><h1>Audit SEO technique</h1><p>Ce que nous vérifions…</p></main>
<script src="/app.js" defer></script>
</body>Ce que nous avons fait sur seoforge.fr
Chaque page est rendue côté serveur : le HTML reçu contient le texte, le titre, la canonique et les liens. Les résultats de nos outils gratuits arrivent après coup depuis un fragment marqué noindex ; la page de l'outil est complète sans lui.
5. Performance impact : optimisation
La performance est un pilier à part entière : les métriques dans notre guide des Core Web Vitals, les correctifs dans le guide Performance web.
Ce que Google documente. Trois Core Web Vitals et leurs seuils : un LCP « dans les 2,5 premières secondes », un INP « inférieur à 200 millisecondes », un CLS « inférieur à 0,1 ». Ces signaux, « avec d'autres aspects de l'expérience sur la page, correspondent à ce que nos systèmes de classement principaux cherchent à récompenser » (Core Web Vitals et résultats de recherche).
Ce que nous recommandons. Mesurer avec des données de terrain, et corriger dans l'ordre LCP, CLS, INP. Le temps de réponse serveur conditionne le LCP : un cache HTTP sur les pages anonymes vient avant toute optimisation d'image.
Comment le vérifier
Notre test de vitesse donne le score et les trois métriques d'une page ; le rapport « Core Web Vitals » de Search Console donne l'état du site par groupe de pages.
Comment le corriger
Les deux gestes de chaque audit : un cache HTTP sur les pages anonymes, des dimensions déclarées sur les images.
# page anonyme : cachable, revalidée au bout de cinq minutes
Cache-Control: public, max-age=300, must-revalidate
<!-- image principale préchargée, dimensions déclarées : LCP et CLS -->
<link rel="preload" as="image" href="/img/hero.avif">
<img src="/img/hero.avif" width="1200" height="630" alt="…">Ce que nous avons fait sur seoforge.fr
Les pages publiques sont servies par le cache HTTP applicatif de Symfony, cinq minutes avec revalidation ; le sitemap et le fichier llms.txt sont cachés une heure. Quand la performance est le sujet, c'est le service Optimisation des Core Web Vitals qui s'en charge.
6. Données structurées impact : optimisation
Ce que Google documente. Les données structurées sont « un format standardisé pour fournir des informations sur une page et classifier son contenu ». Google « recommande en général d'utiliser JSON-LD si la configuration du site le permet », demande qu'elles décrivent le contenu de la page sans « ajouter de données structurées sur des informations qui ne sont pas visibles pour l'utilisateur », et propose le Test des résultats enrichis pour les valider (fonctionnement des données structurées).
Ce que nous recommandons. Un graphe unique par site, Organization et WebSite, auquel chaque page rattache ses nœuds par identifiant : Service et Offer avec prix pour une page commerciale, Article avec auteur Person et dates réelles pour un guide, BreadcrumbList partout, FAQPage uniquement sur les pages qui affichent une FAQ.
Comment le vérifier
Le Test des résultats enrichis pour une page, le rapport « Améliorations » de Search Console pour le site. curl -s URL | grep -o '<script type="application/ld+json">.*</script>' montre ce qui est réellement émis.
Comment le corriger
Un bloc JSON-LD par page, généré par le gabarit à partir des mêmes données que le contenu visible.
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{"@type": "ListItem", "position": 1, "name": "Accueil", "item": "https://votre-site.fr/fr"},
{"@type": "ListItem", "position": 2, "name": "SEO & GEO", "item": "https://votre-site.fr/fr/seo-geo"},
{"@type": "ListItem", "position": 3, "name": "Audit SEO technique"}
]
}Ce que nous avons fait sur seoforge.fr
Un graphe Organization, LocalBusiness et WebSite est émis par le gabarit de base, et chaque page y rattache ses nœuds : Service et Offer avec prix, Article et Person pour les guides, BreadcrumbList calculé depuis la carte du site. Un test parcourt chaque page, valide le JSON-LD et vérifie les types attendus.
7. International et hreflang impact : important
Ce que Google documente. « Chaque version linguistique doit se lister elle-même ainsi que toutes les autres versions linguistiques » ; « si deux pages ne pointent pas l'une vers l'autre, les balises sont ignorées ». La valeur x-default désigne la page à montrer pour toute langue non listée. Les codes suivent l'ISO 639-1, avec une région ISO 3166-1 alpha 2 facultative, les URL sont complètes avec leur protocole, et les balises link, les en-têtes HTTP et le sitemap sont trois méthodes équivalentes (versions localisées d'une page).
Ce que nous recommandons. Une langue, un préfixe d'URL. Un jeu complet, fr, en et x-default, sur chaque page indexable, généré par le même code que la canonique. Jamais de hreflang vers une page absente dans l'autre langue : mieux vaut l'omettre que de pointer vers une redirection ou une 404. Les mêmes alternates sont répétées dans le sitemap.
Comment le vérifier
curl -s URL | grep hreflang sur la version française puis sur l'anglaise : les deux doivent lister les mêmes URL. C'est le contrôle à automatiser : une seule page migrée sans sa jumelle casse la paire.
Comment le corriger
Le jeu complet, absolu, sur les deux pages.
<!-- identique sur /fr/guides/seo-technique et /en/guides/technical-seo -->
<link rel="alternate" hreflang="fr" href="https://votre-site.fr/fr/guides/seo-technique">
<link rel="alternate" hreflang="en" href="https://votre-site.fr/en/guides/technical-seo">
<link rel="alternate" hreflang="x-default" href="https://votre-site.fr/fr/guides/seo-technique">Ce que nous avons fait sur seoforge.fr
Les balises hreflang sont générées par le même service que la canonique, à partir de la route : fr, en et x-default vers la page française. Un test automatisé lit le sitemap, visite chaque URL, exige un jeu complet et vérifie que chaque paire fr/en est réciproque.
8. Monitoring impact : important
Ce que Google documente. Search Console « fournit des informations sur la façon dont Google explore, indexe et diffuse les sites web ». Le rapport d'indexation donne « une vue d'ensemble de toutes les pages que Google a indexées ou tenté d'indexer », le rapport « Performances » montre le trafic issu de la recherche « avec des répartitions par requête, page et pays », et « Inspection de l'URL » donne l'état d'indexation d'une page et permet de demander une exploration (premiers pas avec Search Console).
Ce que nous recommandons. Une revue hebdomadaire de trois rapports, « Pages », « Performances » et « Core Web Vitals », avec une alerte sur toute chute du nombre de pages indexées. Les journaux serveur en complément : ce que Googlebot demande réellement et les codes qu'il reçoit. Et des tests automatisés dans le dépôt, qui échouent avant la mise en production plutôt qu'après.
Comment le vérifier
Sur les journaux d'accès, la répartition des codes renvoyés à Googlebot dit si quelque chose s'est cassé.
Comment le corriger
Une procédure : chaque contrôle de ce guide devient un test qui bloque le déploiement, et le journal serveur est lu chaque semaine.
# codes renvoyés à Googlebot cette semaine, par fréquence
grep -i googlebot access.log | awk '{print $9}' | sort | uniq -c | sort -rn
# URL demandées par Googlebot qui ne sont pas dans le sitemap
grep -i googlebot access.log | awk '{print $7}' | sort -u > crawled.txt
grep -o '<loc>[^<]*' sitemap.xml | sed 's/<loc>//' | sort -u > sitemap.txt
comm -23 crawled.txt sitemap.txtCe que nous avons fait sur seoforge.fr
Les contrôles de ce guide sont des tests automatisés dans le dépôt du site, exécutés avant chaque déploiement : redirections sans chaîne, sitemap complet sans URL interdite, hreflang réciproque, canonique, longueurs des titres et descriptions, JSON-LD attendu, absence de texte provisoire. Search Console reste la source pour ce que Google en a réellement fait.
Ce qu'un audit SEO technique livre chez nous
- Les problèmes prioritaires identifiés, classés bloquant, important, optimisation.
- L'analyse du crawl et de l'indexation : robots.txt, sitemap, codes de statut, redirections, pages exclues et leur motif.
- L'analyse de l'architecture, du maillage interne et des signaux techniques : canonique, hreflang, rendu, données structurées, performance.
- Les recommandations hiérarchisées par impact, avec l'effort estimé pour chacune.
- L'implémentation des corrections dans votre code, par nous.
Sur devis, selon la taille et la technologie de votre site ; premier diagnostic gratuit sous 24 h ouvrées. L'audit ne s'arrête pas au rapport : les correctifs sont implémentés, pas seulement listés.
Par où commencer
Lancez le test de vitesse sur votre page la plus importante : score, Core Web Vitals et premiers points SEO. Pour aller plus loin, l'Audit SEO technique reprend les huit sections de ce guide sur tout votre site, seul ou dans l'Audit Croissance, qui y ajoute l'analyse Ads, la vérification e-mail et un plan d'action à 90 jours. Côté IA, le guide du référencement IA couvre ce que les moteurs de réponse attendent en plus.