Un candidat qui récite la définition d'un canonical tag n'est pas un SEO technique. Un candidat qui explique pourquoi un canonical auto-référencé sur une page paginée avec paramètre ?sort=price peut fragmenter le crawl budget d'un catalogue de 30 000 SKU — celui-là mérite votre attention. Search Engine Journal a publié 15 questions d'entretien pour recruter des digital marketers en 2026. L'angle est pertinent, mais les questions restent souvent en surface. Voici comment aller plus loin avec des questions qui exposent la pensée technique et stratégique réelle d'un candidat.
Le problème avec les questions d'entretien classiques en SEO
La majorité des grilles d'entretien SEO testent la connaissance déclarative : "Qu'est-ce qu'un fichier robots.txt ?", "Quelle est la différence entre noindex et nofollow ?". Ces questions éliminent les débutants complets mais ne discriminent pas entre un profil intermédiaire qui a lu la doc Google et un expert qui a diagnostiqué des régressions en production sur des sites à fort trafic.
Le marché du recrutement SEO en 2026 est saturé de profils qui maîtrisent le vocabulaire sans maîtriser l'exécution. Les certifications se multiplient. Les prompts ChatGPT permettent à n'importe qui de produire un audit SEO structuré en 30 secondes. Ce qui différencie un profil senior, c'est sa capacité à :
- Diagnostiquer un problème à partir de symptômes ambigus (baisse de trafic sans cause évidente dans Search Console).
- Prioriser correctement quand tout semble urgent (migration SSR, dette technique, contenu thin, perte de backlinks simultanés).
- Écrire ou lire du code suffisamment pour collaborer avec les développeurs sans dépendre d'eux pour chaque vérification.
Les 15 questions qui suivent sont organisées par compétence. Chacune inclut ce que vous attendez comme réponse d'un profil réellement senior, et les signaux d'alerte qui trahissent un profil qui bluff.
Questions sur le rendering et l'architecture JavaScript
C'est le filtre le plus efficace en 2026. Un SEO technique qui ne comprend pas les implications du rendering côté client est obsolète depuis trois ans déjà.
Question 1 : "Voici le code source d'une page produit. Expliquez-moi ce que Googlebot voit."
Donnez au candidat ce snippet dans un Google Doc ou sur écran :
<!DOCTYPE html>
<html lang="fr">
<head>
<title>Chargement...</title>
<meta name="description" content="">
<script src="/static/js/bundle.a3f8c2.js" defer></script>
</head>
<body>
<div id="root"></div>
</body>
Ce qu'un senior répond : Le title est un placeholder. La meta description est vide. Le body ne contient qu'un point de montage React/Vue. Si le site repose sur le client-side rendering, Googlebot doit exécuter le JavaScript pour voir le contenu. Même si le WRS (Web Rendering Service) de Google supporte l'exécution JS, il y a un délai entre le crawl et le rendering — parfois plusieurs jours sur des sites à faible PageRank interne. En pratique, la page risque d'être indexée avec "Chargement..." comme title, ce qui est catastrophique pour les SERP. Le candidat devrait mentionner la distinction entre SSR et CSR et recommander soit un passage en SSR/SSG, soit du prerendering.
Signal d'alerte : Le candidat dit "Google sait exécuter le JavaScript maintenant, donc c'est bon". Sans nuance sur le délai de rendering, le crawl budget, ou les cas d'échec (timeout JS, erreurs réseau internes).
Question 2 : "Un site e-commerce de 18 000 pages migre de Create React App vers Next.js. Quels risques SEO anticipez-vous dans les 72 premières heures ?"
Ce qu'un senior répond : Il structure sa réponse en couches :
- Redirections : chaque ancienne URL doit avoir une 301 vers la nouvelle. Si le routing change (ex:
/product/123devient/produits/chaussure-running-nike), une map de redirection exhaustive est nécessaire. Un oubli sur 5% des URLs d'un site de 18K pages = 900 pages en 404, potentiellement les plus linkées. - Rendering : vérifier que le mode de rendering Next.js (SSR, SSG, ISR) est correctement configuré par template. Les pages catégories en ISR avec un
revalidatetrop long peuvent servir du contenu stale aux bots. - Hydration mismatch : le HTML servi côté serveur peut différer du DOM post-hydration, ce qui crée des bugs invisibles pour le SEO. Googlebot indexe le HTML initial, mais si un mismatch fait disparaître des blocs de contenu, les pages peuvent perdre en pertinence.
- Canonicals et hreflang : vérifier que la migration n'a pas cassé les balises
<link rel="canonical">ou les attributs hreflang si le site est multilingue.
Le candidat devrait mentionner un outil de monitoring pour détecter les régressions post-migration en temps réel plutôt que de s'en remettre à un crawl Screaming Frog quotidien.
Question 3 : "Comment vérifiez-vous ce que Googlebot voit réellement sur une page JavaScript ?"
Un profil senior connaît au minimum trois méthodes et leurs limites :
- L'outil d'inspection d'URL dans Search Console : montre le HTML rendu tel que Google le perçoit, mais sur une version "fraîche" — pas forcément ce qui est indexé.
site:url+ cache Google : permet de voir la version en cache, mais Google retire progressivement cette fonctionnalité.- Un test automatisé headless qui simule le comportement de Googlebot :
# Comparer le HTML source vs le HTML rendu avec Puppeteer
curl -s "https://shop.exemple.fr/produit/nike-air-max" | wc -l
# -> 47 lignes (HTML source minimal)
node -e "
const puppeteer = require('puppeteer');
(async () => {
const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.goto('https://shop.exemple.fr/produit/nike-air-max', {waitUntil: 'networkidle0'});
const html = await page.content();
console.log(html.split('\n').length);
await browser.close();
})();"
# -> 312 lignes (HTML après exécution JS)
Si le delta est massif, le site repose sur le CSR. Le candidat devrait aussi évoquer la possibilité d'utiliser des outils dédiés pour tester ce que Google voit réellement.
Questions sur la performance et le crawl budget
Question 4 : "Un site média de 40 000 articles voit son crawl rate baisser de 60% en deux semaines. Aucun changement dans le robots.txt. Qu'investigez-vous ?"
Ce qu'un senior répond (par ordre de priorité) :
- Temps de réponse serveur : si le TTFB est passé de 200ms à 1.5s suite à une charge accrue ou un changement d'infra, Googlebot ralentit automatiquement le crawl pour ne pas surcharger le serveur. Vérifiable dans Search Console > Paramètres > Statistiques sur l'exploration.
- Erreurs 5xx en série : un pic de 500/503 déclenche un backoff exponentiel du crawl.
- Changement de sitemap : un sitemap corrompu ou un fichier XML mal formé peut silencieusement couper la découverte de nouvelles pages.
- Boucles de redirection ou explosion de facettes : si un déploiement a généré des milliers de nouvelles URLs (variantes de filtres, paramètres de tracking), le crawler peut s'y perdre au détriment des pages importantes.
# Vérifier les temps de réponse sur un échantillon d'URLs
cat urls_critiques.txt | xargs -I {} curl -o /dev/null -s -w "%{url_effective} %{http_code} %{time_total}s\n" {}
# Résultat attendu si le serveur est sain :
# https://media.exemple.fr/article/politique-europe 200 0.187s
# https://media.exemple.fr/article/tech-ia-2026 200 0.203s
# Résultat problématique :
# https://media.exemple.fr/article/politique-europe 200 2.341s
# https://media.exemple.fr/article/tech-ia-2026 503 0.002s
Signal d'alerte : Le candidat mentionne uniquement le robots.txt et le sitemap. Pas de réflexe sur les temps de réponse serveur ou les logs d'accès.
Question 5 : "Expliquez-moi comment vous configureriez le crawl d'un site de 25 000 pages pour que Screaming Frog ne fasse pas tomber le serveur de staging."
Cette question teste la connaissance opérationnelle des outils. Un profil qui "utilise Screaming Frog" mais ne sait pas le configurer correctement pour un site de cette taille n'est pas opérationnel.
Ce qu'un senior répond :
- Limiter les threads à 1-2 (contre 5 par défaut) sur un serveur de staging sous-dimensionné.
- Configurer un délai entre les requêtes (crawl delay) de 500ms à 1s.
- Utiliser le mode liste plutôt que le mode spider si l'objectif est de vérifier un sous-ensemble d'URLs.
- Exclure les ressources non critiques (images, fonts, analytics JS) via la config de crawl.
- Augmenter la mémoire allouée à la JVM si le crawl dépasse 15K URLs.
Sur Screaming Frog, cela se traduit par : Configuration > Vitesse > 1 thread, 1000ms de délai. Configuration > Spider > Décocher "Check Images", "Check CSS", "Check JavaScript" si non pertinent pour l'audit en cours.
Questions sur les meta tags et la gestion des régressions
Question 6 : "Vous découvrez que 3 200 pages produit ont perdu leur meta description depuis un déploiement il y a 5 jours. Comment réagissez-vous ?"
Scénario concret et réaliste. Un e-commerce avec un template produit modifié par un développeur frontend qui a accidentellement supprimé le composant <MetaDescription> dans un refactoring React.
Ce qu'un senior répond :
- Quantifier l'impact immédiat : vérifier dans Search Console si Google a déjà re-crawlé et ré-indexé ces pages avec des meta descriptions vides. Si le crawl rate du site est élevé (média, gros e-commerce), 5 jours suffisent pour que Google ait pris en compte le changement sur une portion significative.
- Hotfix prioritaire : faire un revert du composant ou un fix ciblé. Pas besoin d'attendre le prochain sprint.
- Forcer le re-crawl : soumettre les URLs impactées via l'API d'indexation Google (si éligible) ou via un sitemap dédié avec une date
<lastmod>mise à jour. - Post-mortem : mettre en place un test automatisé dans la CI/CD pour détecter l'absence de meta tags critiques avant chaque déploiement.
// Test Playwright dans la CI pour vérifier les meta tags critiques
import { test, expect } from '@playwright/test';
const CRITICAL_URLS = [
'/produit/nike-air-max-90',
'/produit/adidas-ultraboost-24',
'/categorie/chaussures-running',
];
for (const url of CRITICAL_URLS) {
test(`Meta tags présents sur ${url}`, async ({ page }) => {
await page.goto(`https://staging.shop.exemple.fr${url}`);
// Title tag non vide et non placeholder
const title = await page.title();
expect(title).not.toBe('');
expect(title).not.toContain('Chargement');
expect(title.length).toBeGreaterThan(20);
expect(title.length).toBeLessThan(65);
// Meta description présente et non vide
const metaDesc = await page.$eval(
'meta[name="description"]',
(el) => el.getAttribute('content')
);
expect(metaDesc).not.toBe('');
expect(metaDesc!.length).toBeGreaterThan(80);
// Canonical auto-référencé
const canonical = await page.$eval(
'link[rel="canonical"]',
(el) => el.getAttribute('href')
);
expect(canonical).toContain(url.split('?')[0]);
});
}
Ce type de test dans la pipeline CI est exactement le filet de sécurité qui manque dans 90% des organisations. Un outil de monitoring continu comme SEOGard détecte automatiquement ces régressions post-déploiement, mais la première ligne de défense reste un test dans le pipeline.
Signal d'alerte : Le candidat propose de "réécrire les meta descriptions" sans d'abord chercher la cause technique (template cassé, composant supprimé, bug de rendering). Il traite le symptôme, pas la cause.
Question 7 : "Quelle est la différence entre un title tag réécrit par Google et un title tag absent ? Comment diagnostiquez-vous chacun ?"
Un candidat senior sait que Google réécrit les title tags dans environ 33% des cas (source : étude Zyppy, reprise dans les discussions de la communauté SEO). Mais un title réécrit et un title absent sont deux problèmes radicalement différents.
Title réécrit : Google considère que votre title ne correspond pas bien à la requête. Il puise dans les H1, les ancres de liens, le contenu. Diagnostic : comparer le title dans le code source vs le title affiché dans les SERP via Search Console (rapport Performance > Pages > comparer le title indexé).
Title absent : le HTML ne contient pas de <title> ou contient un title vide/placeholder. Souvent causé par un bug de rendering sur les SPA ou un composant React défectueux. Diagnostic : inspecter l'URL dans Search Console, vérifier le HTML rendu.
Le candidat devrait aussi mentionner les erreurs courantes sur les title tags : duplication massive, title tronqués, title identiques au H1 mot pour mot.
Questions sur la stratégie de liens et la visibilité
Question 8 : "Un concurrent vous dépasse systématiquement sur vos 50 mots-clés principaux. Son contenu est comparable au vôtre. Qu'analysez-vous en priorité ?"
Ce qu'un senior répond : Au-delà du contenu, les axes différenciants sont :
- Profil de liens : analyser via Ahrefs/Majestic le nombre et la qualité des domaines référents sur les pages spécifiques qui rankent (pas au niveau du domaine). Un concurrent peut avoir un DA global inférieur mais des liens éditoriaux ciblés sur ses pages stratégiques.
- Architecture interne : vérifier la profondeur de crawl des pages cibles. Si vos pages produits sont à 4+ clics de la homepage alors que le concurrent les place à 2 clics, l'équité de lien interne est mécaniquement inférieure.
- Performance technique : LCP, CLS, INP comparés. À contenu égal, les Core Web Vitals peuvent servir de tie-breaker selon la documentation de Google (Page Experience documentation).
- Fraîcheur et E-E-A-T : le concurrent met-il à jour ses pages plus fréquemment ? A-t-il des auteurs avec des profils identifiables ?
Question 9 : "Comment la montée en puissance des AI Overviews change-t-elle votre stratégie SEO en 2026 ?"
Question ouverte qui teste la veille stratégique. Un profil senior ne répond pas "le SEO est mort" ni "il faut créer du contenu de qualité" (merci Captain Obvious).
Ce qu'un senior répond : Les AI Overviews cannibalisent le CTR des résultats informationnels, mais la visibilité des liens dans les AI Overviews est un signal que Google cherche à préserver l'écosystème éditorial. La stratégie doit évoluer vers :
- Le contenu transactionnel et de décision (comparatifs, guides d'achat détaillés) qui reste mieux protégé du résumé IA.
- La structuration des données pour maximiser les chances d'être cité comme source dans l'AI Overview.
- Le monitoring des citations IA pour comprendre quels contenus sont retenus comme sources fiables — un sujet abordé dans l'analyse de l'impact de la visibilité organique sur les citations IA.
Questions sur le rendering avancé et le choix d'architecture
Question 10 : "SSR, SSG, ISR, dynamic rendering — lequel recommandez-vous pour un catalogue produit de 12 000 SKU mis à jour quotidiennement ?"
Pas de bonne réponse unique. La qualité de la réponse se mesure à la capacité du candidat à raisonner sur les trade-offs.
Ce qu'un senior répond :
- SSG pur : impossible à 12K pages avec des mises à jour quotidiennes. Le build time serait prohibitif et chaque changement de prix nécessiterait un re-build complet.
- SSR : fonctionnel mais coûteux en ressources serveur à l'échelle. Chaque requête génère un render côté serveur.
- ISR (Incremental Static Regeneration) : le meilleur compromis pour ce cas. Les pages sont générées statiquement et re-validées à intervalle configurable (
revalidate: 3600pour une mise à jour horaire). Les pages peu visitées ne consomment pas de ressources. - Dynamic rendering : à éviter comme solution permanente. Google le tolère mais le considère comme un workaround temporaire. Le risque de divergence entre la version bot et la version utilisateur augmente avec le temps.
Le candidat devrait référencer les différences entre ISR, SSR et SSG et mentionner que le prerendering reste une option viable pour les sites qui ne peuvent pas migrer leur stack.
Question 11 : "Montrez-moi comment vous configureriez le next.config.js pour gérer les redirections d'une migration de 500 URLs."
Question pratique. Donnez un accès à un éditeur de code ou demandez au candidat de pseudo-coder.
// next.config.js — gestion de redirections à l'échelle
const redirects = require('./redirects.json');
// redirects.json contient un tableau de {source, destination}
// généré depuis un export Screaming Frog ou un mapping CSV
/** @type {import('next').NextConfig} */
const nextConfig = {
async redirects() {
return redirects.map(({ source, destination }) => ({
source,
destination,
permanent: true, // 301
}));
},
// Pour les volumes > 1000 redirections, préférer le middleware
// ou un reverse proxy (Nginx/Cloudflare Workers) pour éviter
// de charger la config Next.js
};
module.exports = nextConfig;
Un candidat senior précisera que pour des volumes supérieurs à 1 000 redirections, il vaut mieux utiliser un middleware Next.js ou déporter les redirections au niveau Nginx/Cloudflare pour des raisons de performance au démarrage de l'application.
Questions comportementales à valeur technique
Question 12 : "Racontez-moi une situation où vous avez dû convaincre un CTO de prioriser un fix SEO."
Cette question révèle la capacité du candidat à traduire un problème SEO en impact business. Un senior ne dit pas "il faut fixer les 404" — il dit "nous perdons 15 000€ de revenu mensuel estimé sur 340 pages produit qui retournent des 404 depuis la migration, et 47 de ces pages ont des backlinks de domaines avec un DR > 60".
Question 13 : "Quel est le dernier faux positif SEO que vous avez identifié ?"
Les outils de crawl génèrent des faux positifs en permanence. Un candidat qui n'en a jamais rencontré ne les utilise pas assez, ou ne remet pas en question leurs résultats. Exemples de faux positifs courants :
- Screaming Frog qui signale des "pages orphelines" alors qu'elles sont liées via du JavaScript que le crawler n'exécute pas.
- Search Console qui affiche des erreurs "Soft 404" sur des pages de résultats de recherche interne légitimement vides.
- Un outil d'audit qui remonte des "meta descriptions dupliquées" sur des pages paginées qui partagent intentionnellement la même description.
Question 14 : "Comment intégrez-vous les vérifications SEO dans un pipeline CI/CD ?"
Le candidat doit démontrer qu'il sait écrire ou spécifier des tests automatisés. Un profil purement marketing dira "je fais un audit après le déploiement". Un profil technique mettra les checks avant le déploiement.
Les vérifications pertinentes dans une CI :
- Présence et validité des meta tags sur les templates critiques (cf. le test Playwright plus haut).
- Vérification que le robots.txt de production n'est pas celui de staging (
Disallow: /). - Validation du sitemap XML (bien formé, URLs en 200, pas d'URLs en noindex).
- Check des redirections critiques (les 50 URLs les plus importantes répondent en 301 vers la bonne destination).
Question 15 : "Si vous aviez un budget de monitoring SEO limité, que surveilleriez-vous en priorité ?"
La réponse révèle la hiérarchie mentale du candidat.
Ce qu'un senior répond :
- Les pages à plus fort trafic organique (top 100 par sessions) — une régression ici a l'impact le plus immédiat.
- Le statut HTTP des pages avec le plus de backlinks entrants — une 404 sur une page avec 30 domaines référents est une hémorragie de link equity.
- La présence des meta tags sur les templates — un template cassé impacte des milliers de pages d'un coup.
- Les Core Web Vitals en production — un déploiement qui fait passer le LCP de 1.8s à 4.2s est une urgence.
Un outil de monitoring comme SEOGard automatise précisément cette surveillance continue : détection des meta disparues, alertes sur les changements de statut HTTP, monitoring du rendering. Le candidat qui mentionne spontanément le besoin d'alerting en temps réel (plutôt qu'un audit mensuel) démontre une maturité opérationnelle.
Grille d'évaluation : ce qui sépare les niveaux
| Critère | Junior | Mid | Senior |
|---|---|---|---|
| Rendering JS | Sait que Google exécute le JS | Connaît les différences SSR/CSR | Diagnostique un hydration mismatch, écrit un test Puppeteer |
| Crawl budget | Sait que ça existe | Sait vérifier les stats dans GSC | Corrèle les logs serveur avec les données GSC, identifie les pièges à crawl |
| Meta tags | Sait les écrire | Sait auditer avec Screaming Frog | Automatise la détection de régressions dans la CI |
| Priorisation | Traite les alertes dans l'ordre d'apparition | Priorise par volume de pages | Priorise par impact revenu × probabilité de fix × effort |
| Communication dev | Ouvre un ticket "fixez le SEO" | Décrit le problème technique | Fournit le code du fix ou un test reproductible |
Ce que ces questions révèlent au-delà du SEO
Les 15 questions ci-dessus ne testent pas seulement la connaissance SEO. Elles évaluent la capacité à raisonner sous incertitude, à prioriser avec des données incomplètes, et à collaborer avec des équipes techniques. En 2026, un digital marketer qui ne peut pas lire un view-source:, écrire un script de vérification basique, ou argumenter un trade-off d'architecture avec un développeur senior n'est pas un profil technique — c'est un profil éditorial qui a appris le vocabulaire.
Adaptez ces questions à votre stack. Si votre site tourne sur Nuxt, remplacez les exemples Next.js. Si vous êtes sur un CMS headless, ajoutez des questions sur la gestion du cache CDN et son impact sur le crawl. La grille n'est pas un dogme — c'est un framework que vous devez calibrer sur votre réalité technique. Et si vous voulez valider en continu que les recommandations de votre nouvelle recrue sont effectivement appliquées et maintenues en production, un monitoring SEO automatisé reste le seul filet de sécurité réaliste à l'échelle.