Un site e-commerce de 22 000 pages qui perd 34 % de son trafic organique en 11 jours. Un média de niche qui en gagne 45 %. Le dernier Core Update de Google ne s'est pas contenté de reclasser quelques requêtes — il a redessiné la carte de la visibilité organique pendant que, en parallèle, AI Search élargit discrètement le nombre de liens affichés dans ses réponses. Ces deux mouvements simultanés créent un changement de paradigme que la plupart des équipes SEO n'ont pas encore pleinement cartographié.
Anatomie du Core Update : ce que les données Amsive révèlent vraiment
L'analyse publiée par Amsive Digital sur les gagnants et perdants du Core Update de mars-mai 2025 confirme une tendance amorcée lors des updates précédents : Google continue de pénaliser les sites qui agrègent du contenu sans apport éditorial propre, et récompense les sources primaires disposant de signaux d'expertise vérifiables.
Le pattern est plus granulaire qu'un simple « content quality check ». Les sites qui ont progressé partagent trois caractéristiques techniques mesurables :
- Profondeur d'entités : des pages qui couvrent un sujet avec un maillage sémantique dense entre entités liées, plutôt qu'un survol keyword-centric.
- Fraîcheur structurée : des dates de mise à jour cohérentes entre le contenu visible, le
dateModifieden structured data et leLast-Modifiedheader HTTP. - Signaux d'autorité thématique : des backlinks provenant de domaines topiquement proches, pas de link profiles « flat » accumulant des liens de domaines sans rapport.
Les perdants, eux, présentent un schéma récurrent : des pages à faible valeur ajoutée qui rankaient grâce à l'autorité de domaine seule. Google a visiblement recalibré le poids du domain authority par rapport aux signaux page-level et entité-level.
Ce déplacement de visibilité loin des agrégateurs n'est pas nouveau, mais l'amplitude de ce Core Update est significative.
Mesurer l'impact avec précision : au-delà de la Search Console
La Search Console reste l'outil de base, mais ses données sont agrégées et retardées de 48-72h. Pour un diagnostic en temps réel lors d'un Core Update, vous devez croiser plusieurs sources.
Voici un script Python qui interroge l'API Search Console pour extraire les variations de position query par query sur une fenêtre de 14 jours avant/après le début du rollout :
from google.oauth2 import service_account
from googleapiclient.discovery import build
import pandas as pd
SCOPES = ['https://www.googleapis.com/auth/webmasters.readonly']
SERVICE_ACCOUNT_FILE = 'credentials.json'
SITE_URL = 'https://www.votresite.fr/'
credentials = service_account.Credentials.from_service_account_file(
SERVICE_ACCOUNT_FILE, scopes=SCOPES)
service = build('searchconsole', 'v1', credentials=credentials)
def get_query_data(start_date, end_date):
request = {
'startDate': start_date,
'endDate': end_date,
'dimensions': ['query', 'page'],
'rowLimit': 25000,
'dimensionFilterGroups': [{
'filters': [{
'dimension': 'country',
'expression': 'fra'
}]
}]
}
response = service.searchanalytics().query(
siteUrl=SITE_URL, body=request).execute()
return pd.DataFrame(response.get('rows', []))
# 14 jours avant le rollout vs 14 jours après
df_before = get_query_data('2025-04-20', '2025-05-03')
df_after = get_query_data('2025-05-04', '2025-05-17')
# Extraction des métriques par query
for df in [df_before, df_after]:
df['query'] = df['keys'].apply(lambda x: x[0])
df['page'] = df['keys'].apply(lambda x: x[1])
merged = df_before.merge(df_after, on=['query', 'page'],
suffixes=('_before', '_after'))
merged['position_delta'] = merged['position_after'] - merged['position_before']
merged['clicks_delta_pct'] = (
(merged['clicks_after'] - merged['clicks_before'])
/ merged['clicks_before'].replace(0, 1) * 100
)
# Top losers : pages qui ont perdu le plus de positions
losers = merged.nlargest(50, 'position_delta')
losers.to_csv('core_update_losers.csv', index=False)
# Top winners
winners = merged.nsmallest(50, 'position_delta')
winners.to_csv('core_update_winners.csv', index=False)Ce script vous donne un fichier CSV exploitable en 5 minutes. L'étape suivante consiste à regrouper les losers par template de page (catégorie, fiche produit, blog, etc.) pour identifier si le Core Update cible un type de contenu spécifique plutôt que le site dans son ensemble.
Le piège classique : conclure que « tout le site a été pénalisé » alors que seules les pages de listing sans contenu éditorial ont reculé. Cette granularité change radicalement le plan d'action.
AI Search étend ses liens : les implications techniques
Google a ajouté des subscription labels et des inline links dans AI Search (AI Overviews et AI Mode). Concrètement, les réponses générées par l'IA affichent désormais davantage de liens vers des sources, y compris des indications sur le contenu paywall.
Ce changement a deux implications majeures que la plupart des analyses superficielles ignorent.
Plus de liens, pas plus de click data
Premier problème : Google étend les liens dans AI Search sans fournir de nouvelles données de clic dans la Search Console. Vous pouvez apparaître comme source citée dans une AI Overview sans que cette impression ou ce clic apparaisse dans vos rapports.
Cela crée un angle mort analytique considérable. Si votre site est cité dans 30 % des AI Overviews de votre verticale mais que vous ne voyez aucune donnée correspondante, votre perception de la performance SEO est biaisée.
Pour commencer à tracer ces interactions côté serveur, vous pouvez identifier les referrers spécifiques aux clics provenant d'AI Overviews. Google utilise des paramètres UTM et des referrer paths distincts. Voici une configuration Nginx pour logger ces hits séparément :
# /etc/nginx/conf.d/ai-search-tracking.conf
# Map pour identifier les referrers AI Search de Google
map $http_referer $is_ai_search_referrer {
default 0;
"~*google\.com/search.*udm=14" 1; # AI Mode
"~*google\.com/search.*sourceid=ai" 1;
"~*google\.com.*ai-overview" 1;
}
# Map pour identifier l'user-agent Google Extended (AI features)
map $http_user_agent $is_google_extended {
default 0;
"~*Google-Extended" 1;
}
# Log format dédié avec le flag AI search
log_format ai_search_log '$remote_addr - $time_iso8601 '
'"$request_uri" $status '
'"$http_referer" '
'"$http_user_agent" '
'ai_ref=$is_ai_search_referrer '
'g_ext=$is_google_extended';
server {
# ... votre config existante ...
# Log séparé pour le trafic AI search
access_log /var/log/nginx/ai_search_access.log ai_search_log
if=$is_ai_search_referrer;
# Log séparé pour les crawls Google Extended
access_log /var/log/nginx/google_extended.log ai_search_log
if=$is_google_extended;
}Ce n'est pas parfait — Google ne documente pas publiquement tous les patterns de referrer pour AI Search, et ils changent régulièrement. Mais c'est mieux que l'angle mort total. Croisez ces logs serveur avec vos données Search Console pour estimer le delta.
Les subscription labels changent la donne pour les sites paywall
L'ajout de labels « subscription » dans AI Search est un signal fort : Google indique explicitement aux utilisateurs que le contenu source est payant. Pour les éditeurs qui dépendent d'un modèle freemium/paywall, cela change l'équation.
Le risque : l'utilisateur obtient la réponse via l'AI Overview et ne clique jamais sur la source payante, le label « subscription » agissant comme un repoussoir supplémentaire.
L'opportunité : si Google labellise votre contenu comme « subscription », c'est une reconnaissance implicite de sa valeur en tant que source primaire. Et les signaux qui définissent la visibilité en AI Search montrent que les sources perçues comme autoritaires et originales sont davantage citées.
Pour les sites avec paywall, la config structured data des articles doit être irréprochable :
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "NewsArticle",
"headline": "Analyse exclusive du marché des semi-conducteurs Q2 2025",
"datePublished": "2025-05-08T09:00:00+02:00",
"dateModified": "2025-05-09T14:30:00+02:00",
"author": {
"@type": "Person",
"name": "Marie Dupont",
"url": "https://www.votremedia.fr/auteurs/marie-dupont",
"jobTitle": "Analyste senior semi-conducteurs",
"sameAs": [
"https://www.linkedin.com/in/mariedupont-analyst",
"https://twitter.com/mdupont_semicon"
]
},
"publisher": {
"@type": "Organization",
"name": "Votre Média Tech",
"logo": {
"@type": "ImageObject",
"url": "https://www.votremedia.fr/logo.png"
}
},
"isAccessibleForFree": false,
"hasPart": {
"@type": "WebPageElement",
"isAccessibleForFree": false,
"cssSelector": ".article-body-premium"
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://www.votremedia.fr/analyse-semiconducteurs-q2-2025"
}
}
</script>Le champ isAccessibleForFree: false couplé au hasPart avec cssSelector permet à Google de comprendre précisément quelle portion du contenu est derrière le paywall. Sans cette déclaration, Google peut mal interpréter votre modèle et soit ignorer votre contenu, soit le traiter comme du cloaking si le markup ne correspond pas à la réalité visible par Googlebot.
Référence : la documentation officielle de Google sur les contenus paywall et le structured data détaille les exigences techniques.
Mueller sur le « vibe coding » : signal faible, impact structurel
John Mueller a commenté le phénomène du « vibe coding » — la pratique de générer du code entier via des LLM sans le relire en détail. Sa position est mesurée mais le message est clair : Google ne pénalise pas le code généré par IA en soi, mais les conséquences techniques d'un code mal maîtrisé impactent le SEO indirectement.
Le lien avec le Core Update est direct. Voici un scénario réel que nous observons de plus en plus.
Scénario : un SaaS de 8 000 pages génère son frontend avec un LLM
Un SaaS B2B a migré son marketing site de Gatsby vers Next.js en utilisant massivement Cursor + Claude pour générer les composants. Le résultat visuel était correct. Le résultat SEO, catastrophique :
Avant la migration : 8 200 pages indexées, position moyenne 12.4, 45 000 clics/mois.
3 semaines après : 3 100 pages indexées, position moyenne 28.7, 11 000 clics/mois.
Les causes identifiées via un crawl Screaming Frog + analyse des logs serveur :
-
Le LLM a généré du client-side rendering par défaut pour 60 % des pages. Les composants utilisaient
useEffectpour fetcher les données, rendant le contenu invisible au crawl initial. Le SSR était configuré dansnext.config.jsmais le code généré court-circuitait le mécanisme. -
Les balises canonical auto-générées pointaient vers des URLs avec des paramètres de session. Le template généré par l'IA incluait un
useRouterqui ajoutait des query params au canonical. -
Les liens internes utilisaient un composant custom
<Link>qui effectuait une navigation client-side sans<a href>, rendant le maillage interne invisible pour Googlebot.
Le problème n'est pas que le code est généré par IA. Le problème est que personne n'a audité les outputs avec un regard SEO technique. C'est exactement le type de régression que le quality threshold de Google cible — pas une pénalité manuelle, mais une dégradation technique qui fait naturellement sortir les pages de l'index.
Pour détecter ce type de régression avant que Google ne la sanctionne, un monitoring continu des meta tags, du statut SSR et des canonicals est indispensable. Un outil comme Seogard détecte ces cassures dès qu'elles apparaissent en production, avant que l'impact ne se propage dans les SERPs.
Commande Screaming Frog pour valider le rendu JavaScript de vos pages critiques :
# Crawl en mode JavaScript rendering avec Screaming Frog CLI
# Vérifie que le contenu est bien rendu server-side
screaming-frog-cli \
--crawl "https://www.votresaas.com/features" \
--headless \
--config js-rendering-config.seospiderconfig \
--export-tabs "Internal:All,Response Codes:All" \
--output-folder /tmp/sf-audit/ \
--max-crawl-depth 4 \
--limit-crawl-total 5000 \
--render-js true \
--js-rendering-wait 8000
# Puis comparer le HTML initial vs le HTML rendu
# pour identifier les pages où le contenu n'apparaît qu'après JS execution
diff <(curl -s "https://www.votresaas.com/features" | htmlq 'h1,h2,p' --text) \
<(node -e "
const puppeteer = require('puppeteer');
(async () => {
const browser = await puppeteer.launch({headless: 'new'});
const page = await browser.newPage();
await page.goto('https://www.votresaas.com/features', {waitUntil: 'networkidle0'});
const text = await page.evaluate(() => {
return [...document.querySelectorAll('h1,h2,p')].map(el => el.textContent).join('\n');
});
console.log(text);
await browser.close();
})();
")Si le diff montre du contenu manquant dans le curl (HTML statique) mais présent dans le rendu Puppeteer, vos pages ont un problème de SSR. Google peut éventuellement exécuter le JavaScript, mais le délai de rendering et le crawl budget consommé jouent contre vous, surtout lors d'un Core Update où Google réévalue massivement la qualité.
Preferred Sources : Google officialise la hiérarchie des sources
La feature Preferred Sources, mentionnée par Mueller et observable dans les résultats récents, permet à Google de prioriser certaines sources pour des types de requêtes spécifiques. Ce n'est pas un programme opt-in — c'est un signal algorithmique basé sur l'historique de fiabilité, la cohérence thématique et l'autorité perçue d'un domaine sur un topic cluster donné.
Les implications techniques sont profondes. Google ne regarde plus uniquement la pertinence page-level pour une requête donnée. Il évalue si votre domaine est une « source préférée » pour une thématique entière.
Comment auditer votre statut de source sur un topic
L'approche la plus fiable consiste à analyser votre couverture thématique dans la Search Console et la comparer à celle de vos concurrents qui gagnent en visibilité.
Étape 1 : exportez toutes vos requêtes sur 3 mois et clusterisez-les par entité principale (outil : Python + un modèle d'embeddings, ou plus simplement, un clustering par n-grams partagés).
Étape 2 : pour chaque cluster, calculez votre « taux de couverture » — le ratio entre le nombre de requêtes pour lesquelles vous avez au moins une page en top 20 et le nombre total de requêtes dans le cluster.
Étape 3 : identifiez les clusters où votre couverture est inférieure à 40 %. Ce sont vos « trous topiques » — les zones où Google ne vous considère pas comme une source préférée.
Ce travail rejoint directement l'approche de SEO programmatique sémantique : combler les trous topiques avec du contenu structuré qui couvre les entités manquantes dans votre maillage.
L'erreur serait de publier 200 articles thin pour couvrir ces gaps. Le quality threshold de Google élimine précisément ce type d'approche. Il faut moins de pages, mais plus denses, avec des données propriétaires ou un angle éditorial que vos concurrents ne couvrent pas.
Le lien entre Core Update et AI Search : convergence des signaux
La simultanéité du Core Update et de l'expansion des liens AI Search n'est pas une coïncidence. Google aligne progressivement les critères de ranking organique classique avec les critères de citation dans AI Overviews.
Les sites qui gagnent dans le Core Update sont souvent les mêmes qui voient leur citation rate augmenter dans AI Search. Pourquoi ? Parce que les signaux convergent :
- Source primaire vs agrégateur : AI Search cite prioritairement la source originale d'une information. Le Core Update déclasse les agrégateurs qui reformulent sans ajouter de valeur. Même logique.
- Structured data cohérent : les AI Overviews s'appuient sur le knowledge graph et le structured data pour sélectionner les sources. Les sites dont le markup est cassé ou incohérent sont invisibles dans les deux canaux.
- Autorité thématique : le concept de Preferred Sources dans le ranking classique et la sélection de sources dans AI Search reposent sur le même graphe d'autorité topique.
Si vous travaillez votre visibilité en AI Search, vous travaillez aussi votre résilience aux Core Updates. Et inversement.
L'observation de comment les modèles IA comprennent votre marque éclaire un point souvent négligé : la représentation de votre site dans les embeddings des LLM influence à la fois votre citation dans AI Search et la perception de votre autorité par les systèmes de ranking de Google, qui intègrent de plus en plus de composants basés sur des modèles de langage.
Plan d'action post-Core Update : checklist technique
Plutôt qu'une liste générique, voici un workflow séquentiel adapté à un site de 5 000 à 50 000 pages qui vient de subir un Core Update.
Phase 1 — Diagnostic (J+0 à J+3)
Identifiez le type de pages impactées. Utilisez le script Search Console ci-dessus. Regroupez les résultats par template. Si 80 % des pertes viennent de vos pages de listing, le problème n'est pas votre blog.
Phase 2 — Audit technique ciblé (J+3 à J+7)
Crawlez uniquement les templates impactés avec Screaming Frog. Vérifiez :
- Cohérence canonical (self-referencing, pas de chaînes)
- Présence et validité du structured data sur chaque page
- Ratio contenu unique vs contenu dupliqué (surtout pour les pages de catégorie e-commerce qui n'affichent que des extraits produits)
- Headers HTTP :
Last-Modifiedcohérent avecdateModifieddu structured data
Phase 3 — Correction et consolidation (J+7 à J+30)
Priorisez les corrections par impact potentiel. Les pages qui étaient en position 5-15 avant l'update et qui sont tombées en 20-40 sont les plus récupérables. Les pages qui étaient en position 30+ et qui sont tombées en 50+ ne valent probablement pas l'effort — considérez leur suppression ou leur consolidation.
Pour la consolidation, vérifiez que vos redirections ne créent pas de chaînes. Un classique post-Core Update : fusionner 3 pages thin en 1 page dense, mais oublier de mettre à jour les liens internes qui pointent encore vers les anciennes URLs, créant des chaînes de redirects 301 qui diluent le link equity.
Phase 4 — Monitoring continu (J+30+)
Le prochain Core Update arrivera. La question n'est pas si, mais quand. La capacité à détecter une régression technique le jour où elle apparaît — une meta title qui disparaît après un déploiement, un canonical qui se casse, un SSR qui tombe — fait la différence entre un site qui oscille d'update en update et un site qui progresse régulièrement. C'est exactement ce que Seogard automatise : un monitoring continu qui vous alerte avant que Googlebot ne constate les dégâts.
Ce qu'il faut retenir
Ce Core Update confirme la direction prise par Google depuis deux ans : les sources primaires, thématiquement cohérentes et techniquement irréprochables gagnent du terrain. Les agrégateurs et les sites qui comptent sur leur autorité de domaine pour ranker du contenu superficiel reculent. En parallèle, l'expansion des liens dans AI Search crée un nouveau canal de visibilité — mais aussi un nouvel angle mort analytique que vous devez combler côté serveur. L'alignement de votre stratégie SEO classique avec votre visibilité en AI Search n'est plus optionnel : c'est le même jeu, joué sur deux tableaux.