SEO le socle
Référencement naturel technique, sémantique, autorité. Le fondement durable de votre visibilité Google.
GEO le différenciant
Optimisation pour les moteurs génératifs (ChatGPT, Perplexity, AI Overviews). Pratique structurée chez Getknown depuis 2022.
Netlinking l'autorité
Liens de qualité issus de médias reconnus. Éthique, durable, mesurable. Aucun PBN, aucune ferme de liens.
Content & Vidéo le carburant
Contenus qui plaisent à Google, aux LLMs et aux internautes. Format pensé pour l'extraction et la citation par les IA.
Web & Data la mesure
Création de sites SEO-native, refonte technique, tracking, dashboarding. Ce qui ne se mesure pas ne se pilote pas.
Une refonte SEO protège la visibilité d’un site pendant qu’il change de design, de structure, d’adresses ou de CMS. Google le documente : un déplacement de site fait fluctuer les positions pendant un temps. Nous préparons ce moment en quatre étapes, du relevé de l’existant au contrôle après la mise en ligne.
Diagnostic gratuitUne refonte SEO est le volet d’un projet de refonte qui préserve le référencement naturel. Elle couvre le relevé des pages qui portent le trafic et le plan de redirection des adresses qui changent. Viennent ensuite la recette du nouveau site, puis le contrôle des positions et de l’indexation après la bascule.
Une refonte touche le design, l’arborescence, les gabarits ou le CMS. On parle de migration SEO dès que les adresses changent : nouveau domaine, nouvelle structure d’URL ou passage en HTTPS. Google appelle ce cas un « déplacement de site avec changement d’URL » et lui consacre une page de documentation entière.
Les deux chantiers se mènent ensemble. Un nouveau design sans changement d’URL peut déjà casser le maillage interne, alléger le contenu d’une page ou faire disparaître une balise. Un changement d’URL sans nouveau design reste une migration complète, avec son plan de redirection.
Pour un site e-commerce, la refonte touche aussi les catégories, les facettes et les fiches produits. Pour un site multilingue, elle touche les annotations hreflang de chaque version linguistique.
Une refonte fait perdre du trafic quand Google ne retrouve plus les signaux de l’ancien site sur le nouveau. En cause : adresses sans redirection, chaînes trop longues, noindex de pré-production, contenu allégé ou maillage cassé. Google classe ces cas dans les « erreurs fréquentes » d’un déplacement de site.
Des anciennes adresses qui répondent en 404, des redirections vers la page d’accueil par défaut ou des 302 temporaires posées à la place d’une redirection permanente. Google range les « redirections incorrectes » parmi les erreurs fréquentes d’une migration.
Une adresse renvoie vers une deuxième, qui renvoie vers une troisième. Googlebot peut suivre jusqu’à 10 sauts, mais Google conseille d’en rester à 3 au plus. Notre règle de recette va plus loin : une seule redirection, directe, entre l’ancienne adresse et sa cible.
Le nouveau gabarit n’embarque pas les données structurées de l’ancien : fil d’Ariane, produit ou article. Google demande que ce balisage corresponde au texte visible. On le relève gabarit par gabarit avant la bascule, puis on le recontrôle en pré-production.
Adresses refaites par souci de cohérence, profondeur de navigation modifiée, menus et pieds de page allégés. Les pages profondes reçoivent moins de liens internes, et les pages stratégiques perdent une partie de leur exposition.
Sur un site multilingue, les annotations hreflang pointent encore vers les anciennes adresses. Google demande de les mettre à jour avec les nouvelles URL lors d’un déplacement de site, version par version, x-default compris.
Des pages de catégorie ou de service, autrefois riches en contenu utile, se réduisent à quelques lignes sous un gabarit épuré. La page répond moins bien à la requête qu’elle visait, ce qui peut faire reculer ses positions.
La balise noindex de l’environnement de test part en production, ou le robots.txt bloque encore tout le site. Google cite ces blocages en tête de ses erreurs fréquentes. Nous les vérifions ligne par ligne le jour de la bascule.
Le SEO intervient dès le cadrage, avant les maquettes et le choix des adresses. Google l’écrit : le remaniement d’un site est « le moment idéal » pour recruter un référenceur, « le plus tôt sera le mieux ». Arrivé la veille de la bascule, le SEO ne peut plus que corriger des décisions déjà prises.
Trois décisions engagent le référencement bien avant la mise en ligne : la structure des adresses, le mode de rendu des gabarits et le sort des pages qui portent le trafic. Chacune coûte peu à changer sur une maquette et cher à corriger sur un site en production.
Avant d’engager la refonte, un audit SEO établit l’état de départ : pages qui reçoivent des visites, requêtes positionnées, liens entrants et balisage. Sans ce relevé, personne ne peut mesurer après la bascule ce que la migration a gagné ou perdu.
Un plan de redirection associe chaque adresse de l’ancien site à sa cible sur le nouveau, en redirection permanente 301 ou 308. Construit à partir du crawl et de la Search Console, il priorise les pages qui portent le trafic. Il évite les chaînes et met à jour les liens internes.
On photographie le site avant qu’il bouge : crawl complet et export de tout l’historique disponible dans la Search Console. Chaque adresse est listée avec ses visites, ses requêtes et ses liens entrants.
Chaque ancienne adresse reçoit une cible équivalente, validée à la main pour les pages stratégiques et par règles pour la longue traîne. Les redirections sont permanentes et directes. Le moins d’adresses possible change : chaque URL modifiée devient une redirection à tenir pendant au moins un an.
Le nouveau site est crawlé comme s’il était en ligne. On vérifie que chaque redirection répond en un saut, que le balisage est présent, que chaque hreflang pointe au bon endroit et que le contenu figure dans le HTML servi. La bascule attend une checklist validée.
La mise en ligne ouvre le suivi. Redirections, erreurs de la Search Console, pages indexées, positions : chaque écart repéré est attribué à sa cause et corrigé avant qu’il ne s’installe.
Pas forcément. Google recommande de migrer d’abord une partie du site pour tester l’effet sur le trafic et l’indexation. Le reste suit « en une seule fois, ou section par section ». Le découpage dépend du volume d’adresses et de la capacité de l’équipe à tenir plusieurs bascules.
Une migration progressive bascule par exemple le blog, puis le catalogue, puis les pages de conversion. Chaque étape a son propre plan de redirection et son propre contrôle. Le risque se répartit, mais l’ancien et le nouveau site cohabitent : routage, canonical et hreflang doivent rester cohérents pendant toute la transition.
Une bascule unique demande une recette plus serrée, car tout change le même jour. Dans les deux cas, Google rappelle que la capacité du serveur doit suivre : le nouveau site reçoit un pic d’exploration au moment où Googlebot découvre les redirections.
Avant la mise en ligne, on vérifie sur le site de production : noindex hérité, robots.txt, canonical, sitemaps, redirections en un saut, hreflang et balisage de chaque gabarit. Un seul point manquant suffit à repousser la bascule. Le contrôle technique qui alimente cette liste se prépare pendant la recette.
La DSI et le CTO vérifient quatre points avant la bascule. Le mode de rendu de chaque gabarit, le contenu présent dans le HTML initial, l’écart entre pré-production et production, et le retour arrière. Google recommande le rendu côté serveur ou le pré-affichage pour les contenus à indexer.
Cette partie s’adresse aux équipes qui pilotent la refonte côté technique : DSI, CTO et lead dev. Le SEO leur remet une spécification cible avant le premier sprint : convention d’adresses, mode de rendu par gabarit, balisage attendu et règles hreflang si le site est multilingue.
Google traite une page JavaScript en trois phases : exploration, affichage et indexation. Entre les deux premières, la page attend dans une file d’attente « pendant quelques secondes ou pendant plus de temps ». Google ajoute que le rendu côté serveur ou le pré-affichage reste recommandé, car « tous les robots n’utilisent pas forcément JavaScript ».
Une idée reçue veut que Google coupe le rendu au bout de cinq secondes. Les tests publiés par Dave Smart en juillet 2026 la contredisent : l’horloge du moteur de rendu se fige pendant les requêtes réseau. Le rendu se termine quand la page devient inactive.
Rendu côté serveur ou génération statique : le HTML reçu contient déjà le texte. Rendu côté client seul : le HTML initial est presque vide et le contenu n’existe qu’après l’exécution du JavaScript. Une pile headless, Next.js ou Nuxt devant WordPress, se juge gabarit par gabarit.
Title, meta description, canonical, hreflang, H1, texte principal, liens internes et JSON-LD figurent dans le HTML servi, sans attendre un script. Aucun contenu ne doit attendre un défilement : selon Google, « la recherche Google n’interagit pas avec votre page ». On le vérifie sur le code source.
Un fichier JavaScript ou CSS interdit par le robots.txt n’est pas récupéré par Googlebot, donc pas exécuté au rendu. Google indique aussi garder ces fichiers en cache jusqu’à 30 jours : un nom de fichier qui change à chaque version évite de rendre le nouveau HTML avec l’ancien script.
Robots.txt, balises noindex, en-têtes X-Robots-Tag, canonical et protection par mot de passe diffèrent volontairement entre les deux environnements. La recette compare les deux configurations ligne par ligne, puis la production est relue le jour de la bascule.
Avant la bascule, l’équipe sait comment revenir à l’ancien site : sauvegarde de la base, durée de vie DNS réduite si le domaine ou l’hébergement change, redirections désactivables d’un bloc. Le scénario se teste avant la mise en ligne.
OpenAI, Perplexity et Anthropic publient leurs propres robots, que le robots.txt règle un par un. OpenAI précise pour les siens que chaque réglage est indépendant des autres (« Each setting is independent of the others »). OAI-SearchBot sert la recherche de ChatGPT, PerplexityBot celle de Perplexity et Claude-SearchBot celle de Claude.
Une refonte qui remplace le robots.txt peut donc couper ces robots sans toucher à Googlebot, ou l’inverse. Pour les fonctionnalités d’IA de la recherche Google, il n’y a, selon Google, « aucune exigence technique supplémentaire » : le SEO classique suffit. Pour aller plus loin sur le rendu : SEO JavaScript et Core Web Vitals.
Après la mise en ligne, on surveille les redirections, les erreurs « introuvable » de la Search Console, les sitemaps et la part de pages indexées. Google prévient qu’il peut s’écouler quelques semaines ou plus avant qu’il affiche les nouvelles adresses. Une baisse durable au-delà de cette période signale un défaut à corriger.
getknown.fr a quitté un site statique pour WordPress à partir de mai 2026, avec 92 pages migrées le 19 mai. Le 18 septembre 2026, un contrôle complet des redirections et des sitemaps a relevé des défauts que la recette de mai n’avait pas vus.
22 chaînes de redirection, dont une qui finissait sur une erreur 404. 35 des 194 adresses de nos sitemaps répondaient aussi sur l’hôte www., sans redirection vers le domaine principal. Tout a été ramené à un seul saut le jour même.
La leçon tient en une phrase : un plan de redirection se recontrôle après la bascule, sur toutes les adresses sans exception. C’est désormais une étape de notre protocole, y compris pour une migration vers WordPress.
Getknown entre dans le projet au cadrage. Nous relevons l’existant, écrivons le plan de redirection et la spécification technique, recettons la pré-production avec les développeurs, puis contrôlons redirections et indexation après la bascule. Les développements restent chez l’équipe interne ou le studio : nous spécifions et nous vérifions.
Chez Hager, la mission a commencé par un audit SEO ; nous avons ensuite travaillé les mots-clés locaux, les attributs hreflang et l’arborescence.
Programme international · secteur industrie
Lire le cas Hager completAucune migration sans plan de redirection validé URL par URL pour les pages stratégiques et figé avant la bascule. Le document est partagé avec l’équipe technique et tranche les doutes après la mise en ligne.
Le nouveau site passe une recette complète avant la mise en ligne : crawl avec un agent Googlebot, rendu, balisage et hreflang. La bascule attend une checklist validée, jamais un simple accord oral.
La mise en ligne ouvre le suivi. Toutes les anciennes adresses sont recontrôlées une à une : c’est la leçon de notre propre migration.
Le bon moment pour faire entrer le SEO dans une refonte est celui où le brief design commence à circuler. Nous regardons votre projet ensemble et vous disons franchement si nous sommes utiles ou si vos équipes peuvent le mener seules.
Diagnostic gratuitPage mise à jour le