🏗️ Couche 02

Création de site & SEO technique

La base technique — construisez-la correctement (0 → 1)

📖 14 min de lecture 🕑 Mis à jour 2026-06-22

La couche Construction du site et SEO technique résout un seul problème : permettre aux moteurs de recherche de trouver, explorer, comprendre et indexer vos pages sans accroc. Elle se situe après la recherche de mots-clés et avant la production de contenu. Peu importe la précision de votre recherche ou la qualité de votre rédaction : si les robots ne peuvent pas lire vos pages, si vos URL sont en désordre, ou si la page met trois secondes à afficher un écran blanc, le classement est hors de portée.

La bonne nouvelle : c’est la couche où les personnes qui écrivent du code ont le plus gros avantage. Une fois le jargon écarté, la plupart des « problèmes de SEO technique » se résument à des fichiers de configuration, des en-têtes HTTP, des balises HTML et du travail de performance — des choses que vous faites déjà au quotidien. Voyez un robot comme un client HTTP un peu impatient, sans aucune patience pour le JavaScript et avec un budget temps strict. Votre travail consiste à lui servir du HTML propre, rapide et bien étiqueté. Cette page parcourt chaque élément, avec du code prêt à copier-coller.

Domaines et hébergement

Avant qu’un seul octet de contenu n’ait d’importance, la requête doit se résoudre, se connecter et répondre rapidement. C’est le rôle du domaine et de l’hébergement.

Choix du domaine. Optez pour quelque chose de court, mémorable et thématiquement plausible. Quelques règles pratiques :

  • Un domaine flambant neuf ne reçoit aucun bonus « d’ancienneté », mais il ne traîne pas non plus d’historique de backlinks toxiques — une page blanche, c’est très bien.
  • Évitez les domaines en correspondance exacte bourrés de tirets (best-cheap-seo-tools-2026.com) ; ils paraissent spammeux et classent moins bien, pas mieux.
  • Choisissez un seul hôte canonique et tenez-vous-y. Décidez une fois pour toutes entre www et non-www, puis redirigez l’autre pour toujours.

Le HTTPS est non négociable. C’est un signal de classement confirmé (même s’il est léger), et les navigateurs modernes signalent le HTTP simple comme « Non sécurisé ». Imposez-le partout avec une redirection 301 et un en-tête HSTS, pour que les navigateurs n’essaient même plus jamais le HTTP :

# nginx: redirect all HTTP to HTTPS, then enforce HSTS
server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://example.com$request_uri;
}
server {
  listen 443 ssl;
  server_name www.example.com;
  return 301 https://example.com$request_uri;   # consolidate www -> apex
}
server {
  listen 443 ssl;
  server_name example.com;
  add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
  # ... your site ...
}

Le schéma ci-dessus réunit quatre adresses — http://, https://, avec-www, sans-www — en une seule origine canonique. Si vous sautez cette étape, les moteurs de recherche risquent de les traiter comme jusqu’à quatre sites distincts qui se partagent la même autorité.

TTFB et temps de réponse du serveur. Le Time To First Byte est le temps que met le serveur à envoyer le premier octet après la requête. Google considère les réponses lentes comme un problème d’efficacité de l’exploration : un serveur poussif signifie moins de pages explorées par visite. Visez un TTFB inférieur à ~200 ms pour les réponses mises en cache/statiques, et inférieur à ~600 ms pour les réponses dynamiques.

CDN. Un Content Delivery Network met en cache vos pages sur des serveurs physiquement proches des utilisateurs, réduisant drastiquement la latence pour une audience mondiale et absorbant les pics de trafic. Pour un site statique, c’est presque gratuit et presque magique — le HTML, le CSS et les images sont servis depuis un nœud en périphérie situé à quelques centaines de kilomètres du visiteur, plutôt qu’à un continent de distance.

🧑‍💻 Point de vue développeur : inspectez la réponse en direct avec curl. Vérifiez un 200, la présence d’un strict-transport-security, et l’absence d’un x-robots-tag: noindex surprise :

curl -sI https://example.com | grep -iE 'http/|strict-transport|x-robots'

Architecture du site

L’architecture, c’est la façon dont vos URL et vos liens sont organisés. Bien menée, l’autorité circule sans entrave et les robots atteignent tout ; mal menée, des pages importantes restent orphelines, enfouies trois sous-dossiers plus bas, sans aucun lien vers elles.

Des URL propres et sémantiques. Une URL devrait se lire comme un fil d’Ariane. Comparez :

Good:  example.com/seo/technical/canonical-tags
Bad:   example.com/index.php?p=482&cat=7&ref=nav

Règles de base : minuscules, tirets (pas de tirets bas ni d’espaces) entre les mots, pas d’extensions de fichier, pas d’identifiants de session ni de paramètres de suivi dans le chemin canonique, et des mots qu’un humain taperait réellement. L’URL est lue par des personnes, par des robots, et par quiconque décide de cliquer ou non sur votre lien dans la SERP — gardez-la descriptive. Vous voulez voir comment une URL s’affiche dans les résultats ? Utilisez l’outil d’aperçu SERP de ce site.

Hiérarchie plate. Maintenez chaque page importante accessible en environ trois clics depuis la page d’accueil. Plus l’arbre est peu profond, plus le « jus de lien » atteint les pages profondes, et plus les robots les trouvent facilement. Une page qui demande sept clics pour être atteinte signale, à juste titre, que vous ne la considérez pas comme importante.

Maillage interne et modèle de cluster thématique. Les liens internes remplissent deux fonctions : ils acheminent les robots à travers votre site, et ils transmettent de l’autorité entre les pages. La structure la plus efficace est le cluster thématique :

  • Une page pilier couvre largement un grand sujet (/seo/technical-seo).
  • Plusieurs pages de cluster approfondissent chacune un sous-point (/seo/technical-seo/robots-txt, /seo/technical-seo/sitemaps).
  • Chaque page de cluster pointe vers le pilier ; le pilier pointe vers chaque cluster.

Cela indique aux moteurs de recherche « ce site fait autorité sur le SEO technique », et pas seulement « ce site a une page sur robots.txt ». Utilisez toujours un texte d’ancre descriptif (robots.txt configuration) plutôt que click here — le texte d’ancre est un signal de classement pour la page liée.

💡 Astuce : imaginez votre site comme un arbre. La page d’accueil est la racine, les catégories sont les branches, les articles sont les feuilles. Les robots grimpent l’arbre en suivant les liens internes — une page orpheline sans aucun lien interne entrant est une feuille qui flotte dans les airs, et elle risque de ne jamais être explorée.

SEO technique

C’est le cœur de la couche et votre terrain de jeu. Tout ce qui suit est un fichier, une balise ou un en-tête.

robots.txt

Un fichier texte brut placé à la racine du site (example.com/robots.txt) qui indique aux robots quels chemins ils peuvent demander. Point crucial : il contrôle l’exploration, pas l’indexation. Une page bloquée dans robots.txt peut tout de même apparaître dans les résultats (sous forme d’URL nue, sans extrait) si d’autres sites pointent vers elle. Pour garder un élément hors de l’index, vous avez besoin de noindex — voir ci-dessous.

User-agent: *
Allow: /
Disallow: /admin/
Disallow: /cart/
Disallow: /*?sort=          # block faceted/sort parameter URLs

Sitemap: https://example.com/sitemap.xml

⚠️ Attention : ne mettez jamais en Disallow une page que vous voulez aussi désindexer via noindex. Si le robot ne peut pas récupérer la page, il ne pourra jamais voir la balise noindex, et la page restera coincée dans l’index. Bloquez l’exploration ou autorisez l’exploration + noindex — pas les deux.

sitemap.xml

Une liste XML des URL que vous voulez voir indexées. Elle ne garantit pas l’indexation, mais c’est la façon de tendre à Google un inventaire propre — précieux pour les grands sites ou les pages avec peu de liens internes. N’incluez que des pages canoniques, indexables, au statut 200 (pas de redirections, pas de noindex, pas de doublons).

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/seo/technical-seo</loc>
    <lastmod>2026-06-22</lastmod>
  </url>
  <url>
    <loc>https://example.com/seo/technical-seo/robots-txt</loc>
    <lastmod>2026-06-20</lastmod>
  </url>
</urlset>

Soumettez-le dans Google Search Console (section Sitemaps) et référencez-le depuis robots.txt. Ne maintenez pas cela à la main — générez les deux fichiers avec le générateur de robots.txt et sitemap de ce site.

canonical

Lorsqu’un même contenu est accessible via plusieurs URL (paramètres de suivi, barres obliques finales, HTTP vs HTTPS, versions imprimables), une balise canonical désigne la « vraie » version pour que l’autorité se consolide au lieu de se diviser. Placez-la dans le <head> et rendez-la auto-référentielle sur la page préférée :

<!-- on https://example.com/shoes?color=red -->
<link rel="canonical" href="https://example.com/shoes" />

Utilisez des URL absolues, une seule balise canonical par page, et assurez-vous que l’URL canonique elle-même renvoie un 200 (pas une redirection ni un noindex). Une balise canonical est une indication forte, pas une commande — gardez vos signaux cohérents et ne pointez pas, par exemple, vers une page que vous avez aussi bloquée dans robots.txt.

hreflang (multilingue)

Si vous servez le même contenu dans plusieurs langues ou régions, hreflang indique à Google quelle version montrer à quel utilisateur. La règle qui piège tout le monde : les références doivent être bidirectionnelles et complètes — chaque page de l’ensemble doit lister toutes les versions, y compris elle-même. Ajoutez un x-default pour la version de repli.

<!-- in <head> of every page in the language set -->
<link rel="alternate" hreflang="en"    href="https://example.com/en/build" />
<link rel="alternate" hreflang="zh-CN" href="https://example.com/zh/build" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/build" />

Si la page anglaise pointe vers la page chinoise mais que la page chinoise ne renvoie pas la pareille, Google ignore tout le cluster. Utilisez des codes de langue ISO (en, zh-CN), et n’appliquez jamais robots.txt ni noindex aux versions alternatives — elles doivent toutes être explorables.

Données structurées Schema

Les données structurées sont des métadonnées lisibles par les machines qui décrivent ce qu’est une page — un article, une recette, un produit, une FAQ. Google les utilise pour alimenter les résultats enrichis (notes en étoiles, accordéons de FAQ, fils d’Ariane dans la SERP), qui augmentent le taux de clic même quand votre classement ne bouge pas. Utilisez le JSON-LD dans une balise <script> — c’est le format recommandé par Google et il garde le balisage séparé du contenu :

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "A Developer's Guide to Technical SEO",
  "author": { "@type": "Person", "name": "Jane Dev" },
  "datePublished": "2026-06-22",
  "dateModified": "2026-06-22",
  "image": "https://example.com/img/technical-seo.png"
}
</script>

Ne balisez que du contenu réellement visible sur la page (le falsifier vous expose à une pénalité manuelle), puis validez avec le Test des résultats enrichis de Google. Générez du JSON-LD valide pour les Articles, fils d’Ariane, FAQ et Organisations avec le générateur de Schema de ce site.

Indexation mobile-first

Google indexe et classe en utilisant la version mobile de votre page, pas la version desktop. Les conséquences pratiques : ne cachez pas de contenu, de titres ou de données structurées derrière un chemin « réservé au desktop » ; assurez-vous que la page mobile a le même corps de texte, les mêmes balises hreflang/canonical et le même Schema. Une mise en page responsive (un seul payload HTML, des points de rupture pilotés par le CSS) est le modèle le plus sûr, car il n’y a qu’une seule version à garder synchronisée.

Core Web Vitals

Trois métriques qui quantifient l’expérience utilisateur réelle et alimentent directement le classement. Les cibles correspondent aux seuils « bons » :

MétriqueMesureBonCorrectif courant
LCP (Largest Contentful Paint)Temps jusqu’au rendu du plus grand élément≤ 2,5 sOptimiser l’image principale, la précharger, accélérer le TTFB
INP (Interaction to Next Paint)Réactivité aux interactions utilisateur≤ 200 msDécouper les longues tâches JS, livrer moins de JavaScript
CLS (Cumulative Layout Shift)Stabilité visuelle (pas de saut)≤ 0,1Définir width/height sur les images, réserver l’espace des pubs/intégrations

Le plus grand gain en CLS consiste à dimensionner vos médias pour que le navigateur réserve l’espace avant le chargement :

<!-- browser reserves the box immediately; nothing jumps when the image arrives -->
<img src="/hero.webp" width="1200" height="630" alt="Technical SEO diagram" />

Mesurez avec Lighthouse (données de labo) et le rapport Core Web Vitals dans Search Console (données de terrain réelles, issues d’utilisateurs réels) — optimisez pour les données de terrain, puisque c’est ce que Google utilise réellement.

Budget d’exploration, gestion de l’index et contenu dupliqué

Le budget d’exploration est le nombre fini d’URL que Google va récupérer sur votre site dans une fenêtre donnée. Les petits sites atteignent rarement le plafond ; les grands sites (50 000+ URL, gros facettages e-commerce) le font sans aucun doute. Vous gaspillez du budget quand les robots le dépensent sur du superflu : combinaisons de paramètres infinies, impasses de pagination, chaînes de redirection, soft 404.

Le contenu dupliqué dilue ce budget et embrouille le classement. La boîte à outils :

  • Utilisez la balise canonical pour consolider les quasi-doublons (listes de produits filtrées/triées).

  • Utilisez noindex pour les pages légères que vous devez garder publiques mais ne voulez pas voir classées (résultats de recherche interne, archives de tags) :

    <meta name="robots" content="noindex, follow" />

    Ou l’en-tête équivalent pour les fichiers non-HTML :

    X-Robots-Tag: noindex

  • Utilisez robots.txt pour empêcher les robots de gaspiller du budget sur des sections entières sans valeur SEO (/cart/, URL à paramètres de facettage).

  • Corrigez les chaînes de redirection (A → B → C) en sauts uniques (A → C) ; chaque saut brûle du budget et fait fuir un peu d’autorité.

🧑‍💻 Point de vue développeur : raisonnez en vous disant que « chaque URL est une requête que le robot paie ». Avant le lancement, explorez votre propre site avec un outil comme Screaming Frog et auditez la liste — vous y trouverez généralement quelques centaines d’URL à paramètres, de pages calendrier ou d’archives paginées qui grignotent discrètement du budget.

Choisir une stack

Le framework ou le CMS que vous choisissez détermine la part de SEO gérée pour vous par rapport à celle que vous câblez à la main. Le facteur décisif est la façon dont le HTML parvient au robot : du HTML rendu côté serveur/statique (excellent) vs un rendu côté client où la première réponse est une coquille vide <div id="root"> qui ne se remplit qu’après l’exécution du JavaScript (risqué — les robots peuvent effectuer le rendu en retard ou de façon incomplète).

StackRenduCompatibilité SEONotes
WordPressRendu côté serveurÉlevée, avec des extensionsYoast / Rank Math gèrent les méta, sitemaps, Schema. La performance repose sur les plugins de cache.
WebflowRendu côté serveur/statiqueÉlevée d’embléeConstructeur visuel avec des champs title/canonical/hreflang intégrés. Logique personnalisée limitée.
Next.jsSSR ou SSG (ou CSR)Élevée si configuréContrôle total, mais vous câblez le SEO vous-même via generateMetadata et des routes de sitemap dynamiques. Le CSR par défaut est défavorable.
AstroStatique (SSG) par défautTrès élevéeLivre zéro JS par défaut → HTML rapide, gain naturel sur les Core Web Vitals. Idéal pour le contenu/docs/blogs. Ce site fonctionne sous Astro.

⚠️ Attention : une application monopage purement rendue côté client sert une coquille HTML vide au premier chargement. Google peut effectuer le rendu du JavaScript, mais c’est plus lent, moins fiable, et d’autres robots (certains bots sociaux et IA) n’effectuent aucun rendu. Si le SEO compte, choisissez le SSG ou le SSR pour que le premier octet contienne déjà votre contenu.

Pour un développeur qui construit de zéro un site SEO axé sur le contenu, un générateur statique-first (Astro, ou Next.js en mode SSG) offre les meilleurs réglages par défaut : un TTFB rapide, du HTML propre dans la première réponse, et un contrôle facile sur chacune des balises couvertes ci-dessus.

Résumé

L’état d’esprit pour cette couche : servir aux robots du HTML propre, rapide et bien étiqueté, et ne jamais les laisser deviner. Chaque « problème de SEO technique » se réduit à un fichier, une balise, un en-tête ou une milliseconde — exactement le genre de problème que vous savez déjà résoudre. N’écrivez pas à la main les fichiers délicats ; générez-les avec les outils robots/sitemap et Schema de ce site, puis vérifiez tout.

✅ Checklist

  • Imposer le HTTPS sur tout le site, ajouter HSTS, et rediriger en 301 chaque variante de domaine (http, www) vers une seule origine canonique
  • Générer et soumettre robots.txt et sitemap.xml, en n’incluant que des pages canoniques au statut 200
  • Ajouter une balise canonical auto-référentielle à chaque page importante et résoudre les URL dupliquées/à paramètres
  • Définir des balises hreflang complètes et bidirectionnelles (plus x-default) si vous servez plusieurs langues
  • Ajouter des données structurées JSON-LD pour les Articles, fils d’Ariane et Organisations, puis réussir le Test des résultats enrichis
  • Lancer Lighthouse et confirmer LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 — vérifier par rapport aux données de terrain dans Search Console
  • Auditer votre liste d’URL (par ex. avec Screaming Frog) pour repérer les pages orphelines, les chaînes de redirection et les URL à paramètres qui gaspillent du budget