Rick Hunter est un site francophone consacré au SEO technique : crawl, indexation, logs serveur, redirections, rendu JavaScript et performance. Son parti pris consiste à partir des données brutes (logs, Search Console, crawl) plutôt que des intuitions, afin de repérer ce qui empêche une page d'être explorée, comprise ou classée.
Taper « rick hunter » dans un moteur de recherche fait remonter deux univers : un pilote de dessin animé des années 80 et un carnet de travail sur le référencement. C'est le second qui nous occupe ici. Le nom évoque la chasse, et le contenu suit cette logique : traquer les anomalies qui freinent un site, les documenter, puis proposer une correction que l'on peut vérifier. Voici comment le site aborde le SEO technique, quelle méthode il privilégie et comment l'appliquer à un projet réel, du petit blog au média qui publie des dizaines de pages par jour.
Pourquoi Rick Hunter commence par les logs serveur
La Search Console reste indispensable, mais elle livre une vue agrégée, échantillonnée et décalée de quelques jours. Les fichiers de logs, eux, enregistrent chaque requête du robot : l'URL demandée, le code de réponse, l'heure exacte et l'agent utilisateur. En croisant les URL explorées avec celles qui comptent réellement pour l'activité, on mesure le gaspillage au lieu de le supposer.
Concrètement, une analyse de logs bien menée met au jour des situations qu'aucun outil de crawl ne révèle seul :
- des pages stratégiques que Googlebot n'a pas visitées depuis plusieurs semaines ;
- des URL à paramètres (tri, filtres, sessions) qui absorbent une part importante des passages ;
- d'anciennes chaînes de redirections que le robot continue de suivre ;
- des erreurs 5xx intermittentes, invisibles quand on teste la page depuis un navigateur.
Un détail souvent négligé : l'agent utilisateur se falsifie facilement. Avant de tirer des conclusions, il faut confirmer que les visites attribuées à Googlebot viennent bien de Google, par une résolution DNS inverse ou en comparant les adresses IP aux plages publiées par le moteur.
Exploration, rendu, indexation : trois étapes à ne pas confondre
Une bonne partie des diagnostics ratés vient d'une confusion entre ces trois moments. L'exploration, c'est le téléchargement du HTML brut. Le rendu, c'est l'exécution du JavaScript par le service de rendu de Google, parfois plusieurs heures ou jours plus tard. L'indexation, enfin, c'est la décision de conserver la page, de la regrouper avec des doublons et de choisir une URL canonique. Une page peut franchir la première étape et échouer à la deuxième sans que personne ne s'en aperçoive.
Rick Hunter insiste sur une habitude simple : comparer systématiquement le code source et le HTML rendu. Les écarts sont parlants. Un contenu principal injecté tardivement par un script, une balise canonique différente entre les deux versions, un lien de navigation qui n'existe qu'après un clic : autant de signaux contradictoires envoyés au moteur. Et une directive noindex présente dans le HTML initial ne sera pas levée par un script qui la retire ensuite, car Google peut s'arrêter avant le rendu.
Publier vite sans saturer l'exploration : le cas des sites à forte cadence
Prenons une situation fréquente en audit : un site éditorial qui met en ligne plusieurs dizaines de contenus par jour, avec des pages de rubrique, des pages d'auteur, des archives par date et une profusion de tags. Le jour de sa sortie, un article a de la valeur ; trois jours plus tard, beaucoup moins. Si Googlebot passe son temps dans les archives paginées, les nouveautés entrent dans l'index avec un retard qui se paie directement en visites.
Un média d'actualité économique comme la plateforme de Journal Finance, qui suit les marchés, l'épargne et la vie des entreprises au fil de la journée, illustre bien ce besoin : la valeur d'une page dépend de la vitesse à laquelle elle est découverte, ce qui oblige à soigner le sitemap des contenus récents, le maillage depuis la page d'accueil et la tenue du serveur pendant les pics d'exploration.
Sur ce type de site, quelques réglages font la différence :
- un sitemap dédié aux contenus des 48 dernières heures, avec une date lastmod exacte et non régénérée à chaque passage ;
- des liens HTML vers les nouveautés depuis l'accueil et les rubriques, sans dépendre d'un chargement infini en JavaScript ;
- une politique de tags resserrée : les pages qui regroupent deux articles sont fusionnées ou sorties de l'index ;
- des archives par date paginées proprement, sans pages vides ni paramètres en double ;
- une surveillance du temps de réponse, puisque Google réduit son rythme de visite lorsqu'un serveur montre des signes de fatigue.
Pour savoir si ces efforts paient, un seul indicateur suffit au départ : le délai entre l'heure de publication et le premier passage de Googlebot relevé dans les logs. S'il passe de plusieurs heures à quelques minutes, la structure fait son travail.
Un tableau de bord minimal pour suivre la santé technique
Inutile de multiplier les rapports. Une poignée de mesures, relevées chaque mois, suffit à détecter la plupart des dérives avant qu'elles ne pèsent sur le trafic. Les seuils ci-dessous sont des repères indicatifs, à ajuster selon la taille et la nature du site.
IndicateurSourceRepère d'alertePart des visites de Googlebot sur des URL utilesLogs serveurMoins de 60 % des requêtesPages indexées par rapport aux pages soumisesSearch ConsoleBaisse de plus de 10 % sur un moisRéponses en erreur 5xxLogs serveurPlus de 1 % des requêtes du robotDélai entre publication et premier crawlLogs et CMSAllongement durable par rapport à la moyenneLCP mobile au 75e centileRapport Core Web VitalsAu-delà de 2,5 secondesRedirections dans le maillage interneOutil de crawlToute chaîne de plus d'un sautL'intérêt de ce tableau tient moins aux chiffres qu'à leur évolution. Une courbe qui se dégrade lentement après une mise à jour du thème ou l'ajout d'un module en dit plus long qu'une valeur isolée.
Les erreurs que Rick Hunter voit revenir audit après audit
Certaines anomalies reviennent avec une régularité étonnante, quelle que soit la taille du projet. Le fichier robots.txt qui bloque les ressources CSS et JavaScript empêche Google de rendre la page correctement. Une balise canonique qui pointe vers une URL redirigée brouille le choix de la version de référence. Un sitemap qui liste des pages en noindex ou en 404 envoie au moteur un message contradictoire, et il finit par accorder moins de crédit au fichier.
D'autres problèmes tiennent à l'organisation plus qu'à la technique : un environnement de préproduction resté ouvert aux robots, des liens internes encore en http après le passage au https, une refonte livrée sans plan de correspondance des anciennes URL. Ces oublis ne demandent pas de compétences pointues pour être corrigés, seulement une vérification au bon moment.
Ce que les lecteurs demandent souvent à Rick Hunter
Faut-il savoir coder pour suivre les conseils de Rick Hunter ?
Non. Lire du HTML et comprendre un code de réponse HTTP suffit pour l'essentiel. L'analyse de logs gagne à être outillée, mais des solutions avec interface graphique existent et évitent d'écrire des scripts.
À quelle fréquence analyser ses logs serveur ?
Une analyse mensuelle convient à la plupart des sites. Les sites qui publient beaucoup ou qui viennent de changer de structure ont intérêt à suivre les logs chaque semaine, voire en continu pendant une migration.
Un petit site doit-il se soucier du budget de crawl ?
Rarement en tant que tel. Sous quelques milliers de pages, Google explore généralement tout. Le vrai sujet devient alors la qualité des pages et la cohérence des signaux techniques, pas le volume de passages.
La méthode s'applique-t-elle à un site WordPress ?
Oui, et WordPress s'y prête bien. Les points de vigilance habituels concernent les pages de tags et d'auteur, les archives par date, les paramètres ajoutés par certaines extensions et le poids des thèmes sur les performances mobiles.
