Le référencement technique consiste à s'assurer que les moteurs de recherche peuvent trouver, explorer, afficher, comprendre et indexer le contenu d'un site web, et que son infrastructure ne constitue pas un obstacle à son classement. Il se distingue du référencement de contenu et d'autorité par le fait qu'il se concentre sur l'infrastructure du site plutôt que sur son contenu ou ses liens entrants. Son rôle est principalement de faciliter le classement : un site techniquement performant génère rarement un bon positionnement à lui seul, tandis qu'une défaillance technique l'empêche systématiquement.
Les exigences fondamentales sont peu attrayantes. Les pages doivent renvoyer des codes d'état corrects, être accessibles via des liens indexables et ne pas être bloquées accidentellement par des directives du fichier robots.txt ou par des métadonnées. Les balises canoniques doivent regrouper les versions dupliquées d'un même contenu au lieu de fragmenter les signaux à travers des variations de paramètres, des identifiants de session et des incohérences de protocole ou de sous-domaine. Les redirections doivent se résoudre en une seule étape, sans passer par des chaînes qui entraînent une perte de signal et un gaspillage de ressources d'exploration. Chacune de ces exigences constitue un défaut plutôt qu'une optimisation, et chacune est courante sur les sites qui se sont développés au fil des années.
Le rendu est devenu le point faible des sites web modernes. Le contenu généré côté navigateur par JavaScript n'est pas indexé de la même manière que le balisage fourni par le serveur, car le rendu s'effectue dans une étape distincte aux ressources limitées. Les sites conçus comme des applications monopages sans rendu côté serveur ni pré-rendu constatent fréquemment qu'une grande partie de leur contenu n'est pas indexée ou l'est incomplète. La seule méthode fiable consiste à vérifier ce que voit réellement un moteur de recherche, et non ce qu'affiche un navigateur.
La structure du site et le maillage interne se situent à la frontière entre le travail technique et le travail de contenu. La manière dont les pages sont liées entre elles détermine à la fois ce qui est référencé et la répartition de l'autorité sur le site. Des problèmes structurels engendrent des pages orphelines accessibles uniquement via un sitemap, des pages profondes nécessitant de nombreux clics pour y accéder, et des modèles importants quasiment dépourvus de liens internes. Ces problèmes sont invisibles lors d'audits au niveau de la page et nécessitent une exploration complète du site pour être détectés.
L'échelle d'un site modifie l'importance relative des problèmes. Sur un petit site, l'efficacité du crawl est largement négligeable et les efforts doivent se concentrer sur le contenu et la structure. Sur un grand site catalogue avec une navigation à facettes, les mêmes choix techniques déterminent si les moteurs de recherche consacrent leur budget de crawl aux pages pertinentes ou à des millions de combinaisons de filtres qui n'auraient jamais dû être explorées. Identifier la catégorie à laquelle appartient un site permet d'éviter à la fois la négligence et l'erreur inverse, qui consiste à appliquer des solutions d'envergure à un site qui n'en a pas besoin.
La priorisation est le point faible des audits techniques, car les outils automatisés génèrent des centaines de résultats sans pondération selon leur importance. Une méta-description manquante sur une page non visitée, une image sans texte alternatif dans un pied de page et une directive globale bloquant l'indexation d'une catégorie de produits entière apparaissent comme des problèmes, alors qu'un seul d'entre eux a un coût. Trier les résultats selon le nombre de pages affectées, le trafic de ces pages et la nature du problème (empêchant l'indexation plutôt que simple non-respect des bonnes pratiques) permet de transformer une liste intimidante en un ensemble restreint d'éléments justifiant une intervention des ingénieurs.
Étant donné que ces problèmes résident dans les modèles, la configuration du serveur et l'architecture de l'application plutôt que dans le contrôle éditorial, leur résolution nécessite généralement des compétences d'ingénierie plutôt que de marketing. En pratique, services de marketing L'engagement permet d'identifier et de prioriser les problèmes, la mise en œuvre se fait avec le développement de produitset les composants de rendu et de vitesse se chevauchent directement avec performances web C’est pourquoi ces deux disciplines sont plus efficaces lorsqu’elles partagent un même carnet de commandes plutôt que de se disputer le même temps d’ingénierie.