Agence SEO technique : ce qu'elle fait vraiment (et comment la choisir)

Une agence SEO technique intervient sur le crawl, l'indexation, l'architecture du site, le rendu JavaScript, les Core Web Vitals, les données structurées et les migrations. Ce n'est pas un logiciel standardisé mais un ensemble de prestations d'audit et d'intervention sur l'infrastructure technique du site, distinctes du contenu et du netlinking.

La confusion classique : un annonceur cherche une "agence SEO technique" en pensant acheter un audit de balises meta et une liste de mots-clés. Il tombe sur un prestataire qui lui parle de log files, de rendu JavaScript côté serveur et de budget de crawl. Les deux ont raison sur le mot "SEO", tort sur le périmètre. Le SEO technique n'est pas une variante du SEO classique — c'est une couche d'infrastructure qui conditionne si le reste (contenu, liens) a une chance d'être vu par Google.

Ce que fait réellement une agence SEO technique

Le périmètre réel couvre sept zones d'intervention, et une agence sérieuse ne les traite pas toutes avec la même intensité selon ton site :

• Crawl et budget de crawl — vérifier que Googlebot atteint les pages qui comptent sans se perdre dans des pages à faible valeur (facettes, pagination infinie, paramètres UTM indexables).
• Indexation — contrôler ce qui entre réellement dans l'index via robots.txt, balises meta robots, canonicalisation et Search Console (rapport "Pages").
• Architecture du site — profondeur des pages, maillage interne, hiérarchie des catégories, cohérence des URLs.
• Rendu JavaScript — s'assurer que le contenu injecté en JS est bien vu par Googlebot (test via l'outil d'inspection d'URL de Search Console, comparaison DOM rendu vs HTML source).
• Core Web Vitals — LCP, INP, CLS mesurés en conditions réelles (CrUX) et pas seulement en lab (Lighthouse).
• Données structurées — schémas JSON-LD validés, pas juste présents.
• Migrations — refonte, changement de domaine, passage HTTP vers HTTPS, sans perte de trafic organique.

Une agence qui te vend uniquement "audit technique + rapport PDF" fait un tiers du travail. Le vrai chantier, c'est l'implémentation et le suivi post-correction — sinon tu paies pour un diagnostic que personne n'exécute.

Le crawl budget, concrètement

Sur un site de 50 000 pages avec un budget de crawl mal géré, Googlebot peut passer 70% de son temps sur des pages de filtres à faible valeur (ex: /produits?couleur=rouge&taille=m) et négliger les pages produits fraîchement publiées. Résultat observé en agence : des nouveaux produits indexés 3 à 4 semaines après leur mise en ligne, au lieu de 48h.

La correction typique passe par le fichier robots.txt :

User-agent: *
Disallow: /*?couleur=
Disallow: /*?taille=
Disallow: /panier
Disallow: /recherche?
Allow: /produits/
Sitemap: https://exemple.fr/sitemap_index.xml

Attention au piège classique : bloquer une URL dans robots.txt empêche le crawl, mais pas forcément l'indexation si elle est déjà liée depuis l'extérieur. Pour désindexer proprement, il faut d'abord autoriser le crawl, poser une balise noindex, attendre le recrawl, puis bloquer.

Règle de terrain : ne jamais combiner Disallow dans robots.txt ET noindex sur la même URL en même temps. Si Googlebot ne peut pas crawler la page, il ne peut pas lire la balise noindex — et l'URL reste indexée avec un statut "bloquée par robots.txt mais indexée", visible dans Search Console.

Rendu JavaScript : le piège qui coûte le plus cher

Les sites en React, Vue ou Angular avec du rendu côté client (CSR) sont le terrain de jeu préféré des audits techniques ratés. Le contenu existe dans le DOM final mais pas dans le HTML source. Google indexe le DOM rendu — en théorie. En pratique, le rendu JS ajoute de la latence au crawl, et sur un site avec des millions de pages, Googlebot ne rend pas systématiquement tout.

Pour vérifier concrètement ce que Google voit, deux méthodes complémentaires :

# Récupérer le HTML brut sans exécution JS
curl -A "Mozilla/5.0 (compatible; Googlebot/2.1)" https://exemple.fr/produit-x

# Comparer avec le DOM rendu via Chrome headless
google-chrome --headless --disable-gpu --dump-dom https://exemple.fr/produit-x

Si le contenu principal (titre H1, description, prix) n'apparaît que dans la version rendue et pas dans le curl brut, tu as un risque d'indexation partielle. La solution recommandée pour les sites e-commerce ou à fort volume : passer en SSR (server-side rendering) ou en pré-rendu statique (SSG) pour les pages stratégiques, et garder le CSR pour les interactions secondaires (filtres, favoris).

Core Web Vitals : lab vs terrain, ne confonds pas les deux

Lighthouse te donne un score en conditions contrôlées, souvent flatteur. Le CrUX (Chrome User Experience Report), visible dans Search Console sous "Signaux web essentiels", te donne la réalité vécue par tes vrais visiteurs, sur de vrais réseaux mobiles. Un site peut afficher 95/100 sur Lighthouse et être classé "à améliorer" en CrUX parce que 60% du trafic vient de 4G en zone rurale.

Métrique	Bon	À améliorer	Mauvais	Cause fréquente
LCP (Largest Contentful Paint)	< 2,5s	2,5s - 4s	> 4s	Images non optimisées, polices bloquantes
INP (Interaction to Next Paint)	< 200ms	200-500ms	> 500ms	JS trop lourd exécuté au chargement
CLS (Cumulative Layout Shift)	< 0,1	0,1 - 0,25	> 0,25	Pubs/images sans dimensions fixes

Comment choisir une agence SEO technique (et ce qu'il faut arbitrer)

Le marché est hétérogène : certains prestataires vendent des audits ponctuels, d'autres du support plateforme continu, d'autres encore intègrent le SEO directement dans le développement du site (approche "SEO-informed design"). Aucune n'est meilleure dans l'absolu — le bon choix dépend de ton contexte.

• Site vitrine ou blog simple → un audit ponctuel + recommandations suffit souvent, exécuté par ton équipe interne.
• E-commerce à fort catalogue (10 000+ pages) → tu as besoin d'un suivi continu du crawl, de log file analysis récurrente et d'une agence capable d'intervenir directement dans le code (pas juste de rapport).
• Site en pleine migration ou refonte → priorité absolue à l'agence qui a un protocole de migration éprouvé (redirections 301 mappées une à une, pas en masse par regex approximative).
• Site international multi-langue → vérifie la gestion des balises hreflang, souvent bâclée : une erreur fréquente est de pointer un hreflang vers une URL qui redirige, ce que Google ignore purement et simplement.

Sur le log file analysis, l'outil de référence côté agences est Screaming Frog (crawl classique, détection de liens cassés, contenu dupliqué, balises manquantes) couplé à des plateformes comme Lumar (anciennement DeepCrawl) pour le crawling et la surveillance automatisés à l'échelle entreprise. Une agence qui ne sait pas te montrer un extrait de log file brut analysé n'a probablement jamais fait l'exercice pour de vrai.

Exemple de lecture de log file

66.249.66.1 - - [12/Sep/2026:03:14:22 +0000] "GET /produits/chaussure-rouge?taille=42 HTTP/1.1" 200 15234
66.249.66.1 - - [12/Sep/2026:03:14:25 +0000] "GET /produits/chaussure-rouge HTTP/1.1" 200 15100
66.249.66.1 - - [12/Sep/2026:03:14:31 +0000] "GET /produits/chaussure-rouge?taille=43 HTTP/1.1" 200 15234

Ici, Googlebot (IP vérifiée 66.249.x.x) crawle trois variantes de la même page produit à cause des paramètres de taille. Sur 200 000 lignes de logs, ce pattern répété révèle un gaspillage de budget de crawl massif — c'est exactement le type de diagnostic qu'un audit visuel sur navigateur ne révèle jamais, seul le log file le montre.

Les erreurs qui coûtent cher

• Migrer un site sans plan de redirection 1:1 — rediriger tout en masse vers la page d'accueil "pour simplifier" détruit l'équité de lien accumulée sur chaque URL. Perte de trafic organique observée : 30 à 60% dans les 3 mois suivant une migration mal préparée.
• Bloquer le CSS/JS dans robots.txt — Googlebot a besoin de charger les ressources pour évaluer le rendu visuel de la page (mobile-friendliness, layout). Un Disallow: /assets/ trop large casse le rendu vu par Google.
• Ignorer les Core Web Vitals sur mobile — Google utilise l'index mobile-first depuis des années ; auditer uniquement en desktop donne une image fausse.
• Confondre canonical et redirection — une balise canonical est une suggestion, une redirection 301 est un ordre. Pour fusionner deux pages dupliquées de façon définitive, la 301 est plus fiable.
• Multiplier les données structurées non validées — un schéma JSON-LD mal formé (virgule manquante, type incorrect) est simplement ignoré par Google, sans erreur visible côté utilisateur.

Exemple de données structurées correctement implémentées

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Chaussure Running Pro X",
  "image": "https://exemple.fr/img/chaussure-x.jpg",
  "offers": {
    "@type": "Offer",
    "priceCurrency": "EUR",
    "price": "89.90",
    "availability": "https://schema.org/InStock"
  }
}
</script>

Valide systématiquement avec le Rich Results Test de Google avant mise en prod. Un schéma non validé pendant 6 mois, ça arrive plus souvent qu'on ne le croit — surtout après une mise à jour de thème ou de CMS qui casse silencieusement l'injection du script.

SEO technique et mesure : le chaînon qu'on oublie

Un audit technique parfait sans mesure fiable du trafic et des conversions ne sert à rien — tu ne sauras jamais si les corrections ont eu un impact réel. C'est là que le SEO technique rejoint directement les sujets de tracking server-side : si ton suivi des conversions est cassé ou biaisé par des bloqueurs de pub, tu peux corriger tous les Core Web Vitals du monde sans jamais voir l'effet dans tes rapports.

Beaucoup d'annonceurs découvrent ce trou noir seulement après avoir investi dans un audit SEO technique complet : le trafic organique remonte dans Search Console, mais les conversions attribuées n'évoluent pas dans Analytics, simplement parce que le tracking client-side perd 20 à 30% des événements. C'est un problème opérationnel lourd — audit technique du site d'un côté, fiabilité de la donnée de l'autre — que Parler à Wardogz permet d'adresser en combinant les deux chantiers plutôt que de les traiter en silos.

Dans la même logique, une stratégie first-party data solide dépend directement de la qualité de l'architecture technique du site : sans une structure propre de collecte des données (dataLayer bien alimenté, événements standardisés), même la meilleure agence SEO technique travaille avec des chiffres faussés en amont.

Comment vérifier que le travail de l'agence porte ses fruits

• Suivi hebdomadaire du rapport de couverture d'index dans Search Console — pages valides vs exclues, en tendance sur 90 jours minimum (le SEO technique n'a jamais d'effet en 48h).
• Comparaison CrUX avant/après sur un cycle de 28 jours (fenêtre glissante utilisée par Google), pas sur un test Lighthouse isolé.
• Recrawl ciblé via Search Console ("Demander une indexation") sur un échantillon de pages corrigées, pour vérifier que Google prend bien en compte les changements.
• Croisement trafic organique / conversions — un trafic organique en hausse sans hausse de conversions signale souvent un problème de tracking, pas un problème SEO.

À retenir

• Une agence SEO technique traite le crawl, l'indexation, l'architecture, le rendu JS, les Core Web Vitals, les données structurées et les migrations — pas les mots-clés ni le contenu.
• Ne jamais combiner Disallow robots.txt et noindex sur la même URL simultanément : ordre correct = autoriser le crawl, poser le noindex, attendre le recrawl, puis bloquer.
• Vérifie le rendu réel vu par Googlebot avec un curl user-agent Googlebot comparé au DOM rendu, avant toute correction Core Web Vitals.
• Utilise le CrUX (données terrain) comme référence de décision, pas Lighthouse (données lab) seul.
• Sur une migration, exige un mapping de redirections 301 un-à-un — jamais une redirection en masse vers la page d'accueil.
• Valide chaque schéma JSON-LD avec le Rich Results Test avant mise en production, et revalide après chaque mise à jour de thème/CMS.
• Choisis le format d'agence selon ton contexte : audit ponctuel pour un site simple, suivi continu avec log file analysis pour un catalogue volumineux.
• Ne dissocie jamais l'audit technique du contrôle de la fiabilité du tracking — sinon tu ne sauras jamais si les corrections ont un impact réel sur les conversions.