Création et développement de sites web

Pourquoi votre trafic Google s'est-il effondré après une refonte de site ?

Partagez !
Linkysoft · Blog: Pourquoi votre trafic Google s'est-il effondré après une refonte de site ?

Si le trafic Google plonge après une refonte de site, ce n'est presque jamais la faute à pas de chance ni au nouveau design, mais à une mécanique précise qui a lâché. Les causes que toutes les sources citent sont les mêmes : des anciennes adresses sans redirection permanente (301), un réglage « ne pas indexer » oublié après les tests, des textes coupés pour faire plus joli, ou un site devenu trop lourd et lent. Des blogs d'agences anglophones répètent qu'un lancement bâclé coûte entre 40 et 80 % du trafic en quelques semaines, un chiffre de bouche-à-oreille qui donne tout de même une idée du danger.

Toute baisse ne veut pas dire panne, car Google doit repasser sur chaque page que vous avez changée. Un léger recul pendant les premiers jours est donc prévu. Par contre, une chute brutale en quelques jours, des erreurs plein Search Console ou une descente qui continue après deux semaines prouvent que quelque chose est vraiment cassé.

Commencez par deux contrôles rapides : le petit code qui compte vos visiteurs est-il bien là, et avez-vous interdit par erreur à Google de lire votre site ? Dès que vous réparez le souci, le trafic revient progressivement : des sources hispanophones parlent de 2 à 6 mois pour un grand site.

Avez-vous vraiment perdu du trafic, ou est-ce le compteur qui est cassé ?

Beaucoup de nouveaux sites partent en ligne sans le petit code qui envoie les visites à Google Analytics, ou avec un bandeau de cookies mal réglé. Votre graphique tombe alors à zéro du jour au lendemain, mais vos clients sont toujours là.

Pour en avoir le cœur net, ouvrez Google Search Console, le rapport gratuit de Google dont les chiffres ne dépendent d'aucun code sur votre site. Et si les visites tiennent mais que les appels chutent, le problème est ailleurs, comme l'explique notre article sur les sites qui ont des visiteurs mais aucune vente.

Un test de deux minutes dans Search Console

Dans le rapport Performances, comparez les quatre semaines avant et après la mise en ligne, en cochant les clics et les impressions, qui comptent vos apparitions dans Google même sans clic.

Les impressions bougent avant les clics, ce qui en fait un excellent radar. Si les deux lignes restent au niveau d'avant alors que vos statistiques s'effondrent, c'est le compteur qui est en panne, pas votre place sur Google.

Les signes qui trahissent votre outil de mesure

Le premier indice est la forme de la courbe : quand le compteur casse, elle plonge droit vers le bas le jour du lancement, alors qu'une vraie perte sur Google s'étale sur plusieurs jours.

Le second, c'est que toutes vos sources de visites plongent ensemble, y compris les clics dans vos e-mails, ce qu'aucun souci de classement ne peut provoquer. Dans ce cas, faites vérifier votre compteur tout de suite.

Après deux semaines, on fait très bien la différence entre une petite baisse et un gros crash

Google a besoin de temps pour relire chaque page changée, et l'agence Huemor juge donc normale une petite baisse après le lancement. Le souci, c'est que cette phrase rassurante sert souvent d'excuse quand le site est vraiment cassé.

Des blogs d'agences françaises parlent de chutes de 30, 50, voire 70 % après une refonte ratée, et des sources hispanophones de cas à plus de 80 %. Entre une petite secousse et un crash total, la différence saute aux yeux dès la deuxième semaine.

À quoi ressemble un retour au calme normal

Pendant quelques jours, vos pages dansent : l'une gagne deux places, en perd trois, puis remonte, pendant que Google ajuste le tir. Votre total de clics reste à peu près stable, avec au plus un léger creux réparti sur toutes les pages.

Si la perte est faible et commence à remonter avant la fin de la deuxième semaine, tout va bien. Le mieux est de garder un œil ouvert, sans rien toucher.

Les feux rouges qui annoncent une vraie panne

Cinq critères font la différence entre une petite secousse et un vrai problème. Pas besoin d'être un pro de l'informatique, il suffit de lire l'écran de Search Console et de vos statistiques. Le tableau suivant les compare pour vous aider à situer votre cas en une minute.

Baisse normale ou vraie panne ?
Jugez à deux semaines, pas à deux jours

Si votre cas ressemble surtout à la colonne de droite, n'attendez pas de miracle. Les trois signaux ci-dessous sont les plus faciles à voir.

Votre trafic plonge à pic en quelques jours

Dans vos Performances, la courbe des clics tombe dans le vide en trois ou quatre jours et ne remonte plus, contrairement au léger creux d'une baisse normale.

Une chute aussi rapide cache souvent un blocage global, comme un réglage qui interdit à Google de vous lire, ou un gros paquet d'anciennes adresses qui renvoient des erreurs en même temps. Ce trafic ne reviendra pas par magie.

Vous perdez des visites sur un seul type de page

Triez votre rapport Performances par page. Si toutes vos fiches produits, tous vos articles de blog ou toute votre rubrique de services s'effondrent pendant que le reste tient, c'est ce type de page qui a un défaut.

Souvent, un dossier entier a été oublié dans les redirections, ou le modèle de page a perdu son texte ou son balisage. Bonne nouvelle, une seule retouche du modèle répare alors toutes ses pages.

Vous avez de plus en plus d'erreurs dans Search Console

Dans le rapport Pages, la liste des exclusions grandit de semaine en semaine : « Introuvable (404) », « Soft 404 », « Exclue par la balise noindex », « Bloquée par le fichier robots.txt ». Une 404 est une page introuvable, une soft 404 une page qui s'ouvre mais reste vide, et noindex ou robots.txt sont des réglages qui interdisent à Google de lire ou de montrer une page. Chaque ligne veut dire que Google a arrêté de montrer certaines pages.

Si ces chiffres grimpent encore après deux semaines, notez-les chaque jour : ce sera votre preuve face à l'équipe qui a fait le site.

Tout le site s'est envolé de Google en quelques jours

Pendant les travaux, le nouveau site tourne sur une adresse d'essai que l'on interdit à Google d'explorer, pour que le chantier reste caché. Si ce réglage reste actif après le lancement, Google retire vos pages. L'agence WebFX cite ce souci parmi les causes de chute les plus courantes.

Le blocage passe par la balise noindex, un code qui dit à Google de cacher une page, ou par le fichier robots.txt, qui dit aux moteurs où ils ont le droit d'aller. Le retirer prend deux minutes, mais chaque jour perdu vous coûte des pages.

Comment ce réglage atterrit sur votre vrai site

Ce réglage se cache dans votre CMS (l'outil qui sert à modifier le site) ou dans un petit fichier, et il voyage avec le site d'essai quand on le copie vers la vraie adresse.

Sur WordPress, c'est une simple case des réglages de lecture, « Demander aux moteurs de recherche de ne pas indexer ce site », que tout le monde oublie de décocher dans le rush du lancement. Cet oubli d'une seconde coûte des semaines de visites.

Comment vérifier tout seul, sans technicien

Tapez site:votredomaine.fr dans Google, avec votre vraie adresse : si presque rien ne sort, le signal est clair. Dans Search Console, l'Inspection de l'URL vous dit si votre page d'accueil est indexée, et le rapport Pages liste les pages exclues par noindex ou bloquées par robots.txt.

Retenez une nuance : l'exploration, c'est Google qui lit la page, et l'indexation, c'est Google qui l'enregistre pour la montrer. Notre glossaire explique ces mots, et nos articles sur l'indexation creusent le sujet.

Vos vieux liens renvoient vers une erreur ou vers l'accueil

Les favoris de vos clients, vos places sur Google et les liens venus d'autres sites visent tous des adresses précises. Chaque ancienne page utile a donc besoin d'une redirection 301, un renvoi permanent vers la nouvelle page équivalente. Selon l'agence Sixth City Marketing, plus de 95 % des sites ont au moins un problème de redirection.

D'après Google, via le site français Reqst, une redirection 301 bien faite ne vous fait pas perdre votre autorité. Faire le plan de ces adresses fait partie de l'audit à mener avant une refonte.

Repérer les pages qui bloquent

Les cas « Introuvable (404) » et « Soft 404 » du rapport Pages sont presque toujours vos anciennes adresses.

Faites le test vous-même : prenez les 20 pages qui ramenaient le plus de monde avant la refonte, tapez chaque ancienne adresse et regardez où vous arrivez. Nouvelle page, erreur ou accueil, en vingt minutes vous saurez si le problème est ponctuel ou général.

Pourquoi dévier tout le monde vers l'accueil est une mauvaise idée

Imaginez un magasin qui déménage et colle le même panneau sur toutes ses anciennes portes, « Allez au magasin central » : le client qui cherchait un produit précis se perd, et Google réagit pareil. HubSpot conseille donc des redirections faites page par page, vers l'équivalent direct.

Si une page n'a plus lieu d'être, parce qu'un service est arrêté, affichez une vraie « page supprimée » (le code 410). C'est franc pour le client, et limpide pour Google.

301 ou 302, pourquoi le dernier chiffre est capital

La 302 est une redirection provisoire. Utilisée par erreur pour un vrai déménagement, elle fait croire à Google que l'ancienne page va revenir, et il ne transfère pas sa valeur à la nouvelle.

Beaucoup d'outils mettent la 302 par défaut, alors demandez à votre développeur de confirmer la 301 par écrit, ou vérifiez-la avec un vérificateur d'en-têtes HTTP gratuit. Nos articles sur la redirection détaillent la méthode.

Vous êtes toujours sur Google, mais vous avez reculé

Ici, pas de crash brutal : vos pages restent indexées, mais elles perdent des places chaque semaine, souvent à cause de choix de design comme des textes raccourcis, des titres changés ou des liens effacés.

Prenez une page qui chute et comparez l'onglet Requêtes de vos Performances avant et après le lancement. Si la version raccourcie marche moins bien, notre avis est net : remettez de la profondeur, quitte à placer le texte plus bas ou dans des blocs dépliables.

Des pages trop courtes qui laissent le client sur sa faim

Les designers coupent les longs textes pour faire respirer la page, alors que ce texte répondait aux questions des visiteurs et faisait classer la page. Un menu de restaurant avec le seul nom des plats est chic, mais on ne sait pas ce qu'on mange.

Huemor conseille de garder au moins 300 mots utiles par page. Remettez les anciens textes depuis vos sauvegardes, en commençant par les pages qui ont perdu le plus de clics.

Les gros titres effacés par le nouveau look

Certains gabarits remplacent tous les titres bleus affichés par Google par le nom de la marque, ou collent les mêmes sous-titres partout, sans regarder les mots-clés qui portaient les anciens.

HubSpot conseille de viser un ou deux mots-clés par page et de traiter cinq à dix pages par semaine. Pour 40 pages clés, cela fait quatre à huit semaines de travail régulier, en commençant par les pages qui vous amenaient des demandes.

Des menus qui cachent vos meilleures pages

Pour Google, chaque lien interne est un petit vote : une page souvent citée par le reste du site est jugée forte. Si la refonte simplifie trop le menu et le pied de page, ces votes disparaissent en silence.

Une page qui était à un clic et en demande aujourd'hui quatre sera moins bien classée. Remettez des liens vers elle depuis le menu ou vos textes, un correctif rapide qui ne gâche pas le design.

Ce que Google voit quand votre site est fait avec du JavaScript

Certains outils de développement modernes envoient une page presque vide, qu'un programme remplit ensuite. Le client voit tout en une seconde, mais Google peut ne voir que du vide, ou mettre des jours avant de lire le texte.

Des pages sortent donc de Google même si toutes vos redirections sont bonnes, et on cherche au mauvais endroit. Chez Linkysoft, nos sites envoient toujours le texte déjà prêt dans la page, ce que Google lit sans attendre.

L'indice qui prouve que l'affichage est en cause

Dans le rapport Pages, beaucoup d'adresses sont marquées « Explorée, actuellement non indexée », ou le texte sous votre lien dans Google affiche « Chargement... ». Autre test : une phrase de votre site, cherchée entre guillemets, reste introuvable.

Pour trancher, lancez « Tester l'URL en ligne » dans l'Inspection de l'URL et comparez la capture avec ce que montre votre navigateur. Si elle est vide ou incomplète, vous tenez la cause.

Les questions à poser à votre informaticien

Ce souci vient de la construction du site, donc du développeur. Demandez-lui si le contenu principal est envoyé par le serveur, ou si le navigateur doit exécuter des scripts pour le voir, et s'il peut passer les pages clés en rendu côté serveur ou en pré-rendu.

Une réponse floue à la première question veut tout dire. Exigez alors un planning de réparation qui commence par l'accueil, les services et les fiches produits.

Plus c'est lent sur téléphone, moins c'est vu sur Google

Une refonte ajoute souvent du poids : grandes photos, animations, nouveaux outils. Google le mesure avec les Core Web Vitals, trois indicateurs qui disent si la page s'affiche vite, si elle réagit vite au doigt et si elle reste stable au chargement. Huemor vise un contenu principal visible en moins de 2,5 secondes, une réaction en moins de 100 millisecondes et aucune mise en page qui se décale.

Vos visiteurs sont encore plus pressés, puisque d'après HubSpot, 47 % des gens attendent une page prête en deux secondes ou moins. Testez donc PageSpeed Insights en mode mobile, et lisez nos articles sur la vitesse pour les réglages possibles.

Tout ce poids que la refonte vous a mis sur le dos

Les coupables habituels se repèrent vite : vidéo en fond d'accueil, photos non compressées, carrousels, polices en plus et fenêtres de discussion qui masquent le contenu. Ensemble, ils pèsent lourd sur un téléphone en 4G.

L'hébergement compte aussi, car un petit contrat taillé pour l'ancien site léger s'essouffle avec le nouveau. Chez Linkysoft, nous hébergeons nos sites sur Hostrena pour cette raison. Quel que soit votre hébergeur, demandez-lui si son offre est taillée pour le nouveau site.

Vos étoiles et vos questions-réponses ont disparu de Google

Les données structurées, aussi appelées balisage schema, sont un code invisible pour le visiteur qui explique à Google ce que contient la page : une FAQ, l'adresse de l'entreprise, un produit et sa note. Le nouveau site les perd si personne ne les remet exprès.

Le symptôme est trompeur : les clics baissent alors que votre position tient, car votre résultat a perdu ses étoiles ou sa FAQ et paraît plus terne. Et comme ce code aide Google à comprendre vos pages, le perdre ne fait jamais gagner de visibilité.

Comment repérer une perte de balisage

Dans vos Performances, affichez ensemble la position moyenne et le taux de clics. Une position plate avec des clics en recul, c'est la signature d'un beau résultat redevenu ordinaire.

Vérifiez aussi la section Améliorations de Search Console, où les rapports FAQ, Produits ou Avis sont vides ou absents. Pour une preuve nette, passez la nouvelle adresse dans le test des résultats enrichis de Google et comparez avec l'ancien site.

Remettre le balisage en place

Listez les balisages de l'ancien site et exigez les mêmes sur les nouvelles pages : une FAQ sur les pages de services, le nom de l'entreprise sur l'accueil, les avis sur les fiches produits.

Une règle à ne jamais oublier : ne balisez que ce qui est vraiment visible sur la page. Un code pour un texte absent est ignoré par Google et peut même valoir une sanction manuelle, alors mieux vaut trois types bien faits que dix codes collés dans le vide.

Une seule langue est tombée en panne

Sur un site en plusieurs langues, la refonte peut casser une langue sans toucher aux autres. Le coupable est souvent hreflang, une balise qui dit à Google quelle version montrer à quel internaute. Oubliée, pointée vers de vieilles adresses ou sans renvoi entre les langues, elle pousse Google à montrer l'anglais à un francophone, ou à cacher votre traduction.

Nos articles sur le hreflang creusent le sujet. Ici, on s'en tient au diagnostic.

Comment le voir dans vos chiffres

Le symptôme est net : un pays ou une langue chute pendant que les autres tiennent. Dans Performances, filtrez par dossier, par exemple /fr/ ou /ar/, puis par pays : si la France et la Belgique plongent pendant que l'anglais tient, la piste multilingue est la bonne.

L'Inspection de l'URL affiche aussi l'URL canonique, la version que Google juge principale. S'il choisit votre page anglaise à la place de la française, votre traduction est invisible à ses yeux.

Trois choses à vérifier langue par langue

Chez Linkysoft, nous construisons des sites en six langues, et les refontes multilingues cassent presque toujours sur ces trois points. Chacun tient en une phrase que vous pouvez envoyer à votre développeur, sans maîtriser son jargon.

Faites un test rapide sur l'accueil et deux pages importantes par langue. Si c'est propre, le reste l'est souvent aussi, car toutes les pages sortent du même moule.

Chaque traduction a sa propre redirection

Les anciennes adresses en français, arabe ou allemand doivent renvoyer vers leur traduction directe, pas vers l'anglais ni vers l'accueil. Par exemple, /fr/nos-services doit mener à /fr/services, pas à /en/services, sinon le client belge tombe sur une page en anglais. C'est l'oubli le plus fréquent, car on prépare souvent les redirections pour la seule langue principale.

La phrase à envoyer : « Merci de confirmer que chaque ancienne URL traduite redirige en 301 vers la nouvelle page dans la même langue. »

Ce code de langue doit viser une adresse qui marche

Une balise hreflang qui vise une ancienne adresse ou une erreur ne sert à rien. Si la balise vise une page qui redirige, Google doit faire un détour et finit souvent par ignorer toute la liste de langues. Votre développeur dispose d'outils d'exploration qui contrôlent ça sur tout le site d'un coup, sans vérifier page par page.

La phrase à envoyer : « Merci de vérifier que toutes les balises hreflang pointent vers les nouvelles adresses, et qu'elles répondent sans redirection. »

Chaque langue doit citer les autres

Les balises hreflang marchent par paires : si le français cite l'anglais, l'anglais doit citer le français, sinon Google ignore le lien. Pensez à deux magasins partenaires : si l'un affiche l'adresse de l'autre mais pas l'inverse, le client doute que le partenariat existe. Ce renvoi mutuel saute souvent quand on refait une seule langue à part.

La phrase à envoyer : « Merci de confirmer que chaque version linguistique liste toutes les autres, y compris elle-même. »

Ce que vous devez vérifier, et dans quel ordre

Toutes ces pannes se traitent dans le même ordre, en commençant par ce qui se vérifie vite et fait le plus de dégâts.

Dans quel ordre vérifier après le lancement
Les causes rapides et graves d'abord

Le calendrier compte autant que l'ordre. Nous conseillons de faire les contrôles rapides dans les 48 premières heures, et Huemor conseille de suivre les indicateurs chaque jour pendant au moins deux semaines. Notez chaque réparation avec sa date, pour comprendre vos graphiques plus tard.

Dans les premières 48 heures

Vérifiez la balise de mesure, le noindex, le fichier robots.txt et vos 20 anciennes adresses les plus visitées. Soumettez ensuite votre sitemap XML, la liste de vos pages, dans Search Console et Bing Webmaster Tools pour que les moteurs trouvent plus vite vos nouvelles adresses.

C'est la priorité numéro un, car un seul de ces réglages peut retirer tout le site des résultats, et il suffit de Search Console et d'une heure de votre temps.

De trois à quatorze jours

Chaque jour, cherchez les nouvelles 404 et soft 404 dans le rapport Pages, car une liste qui grandit trahit un dossier entier sans redirection. Testez aussi le rendu de chaque modèle avec l'Inspection de l'URL : accueil, page de service, fiche produit, article.

Comparez enfin les clics par page avec vos chiffres d'avant le lancement. Une page qui perd la moitié de ses clics mérite une enquête, même si le total semble bon.

Après quinze jours

Place aux chantiers plus lourds : contenus raccourcis, titres changés, liens effacés, vitesse et données structurées. Ces corrections se font page par page, et leurs effets mettent souvent des semaines à se voir.

Vous pouvez alors passer d'un contrôle quotidien à un suivi plus espacé, et notre article sur les chiffres à regarder chaque mois prendra le relais une fois la crise passée.

Quand est-ce que vos visites vont revenir ?

Une fois la panne réparée, l'accueil et les pages populaires, que Google visite souvent, reviennent en premier, et les pages profondes en dernier. Des sources hispanophones parlent de 2 à 6 mois pour un grand site, des blogs SEO arabophones de 60 à 90 jours pour stabiliser les classements, et l'agence allemande Verdure prévient qu'une reprise peut prendre des mois.

Mieux vaut donc corriger en quelques jours qu'attendre un trimestre, car une redirection cassée ne se répare jamais toute seule. À l'inverse, une refonte bien menée peut faire gagner du trafic : l'agence Sixth City Marketing annonce 48 % de trafic en plus pour son client M/I Homes, selon ses propres chiffres.

Ce qui va accélérer votre retour

Corrigez la cause, soumettez à nouveau le sitemap, puis utilisez le bouton « Demander une indexation » sur vos pages clés dans l'Inspection de l'URL. Ça ne force pas Google, mais ça l'incite à repasser plus tôt.

Gardez aussi vos redirections pour toujours, car les liens venus d'autres sites continuent de vous aider à travers elles. Les effacer dans un an pour « faire le ménage » relancerait la panne.

Qui va payer la note de réparation, vous ou l'agence ?

Lisez d'abord votre devis ou contrat. S'il mentionne un plan de redirection, une migration SEO ou la continuité du trafic, réparer les pannes fait partie du travail de l'agence. S'il ne dit rien, la plupart des agences factureront un supplément. Notre article sur les lignes essentielles d'un devis vous aidera pour vos prochains contrats.

Le prix des réparations dépend du nombre de pages touchées, de la durée de la panne, d'un éventuel changement de plateforme (quitter Wix change toute la technique) et du nombre de langues. Posez tout de suite ces quatre questions à votre agence :

  • Quelle est la liste des redirections ?
  • Les blocages du site de test ont-ils été retirés ?
  • Comment les pages sont-elles affichées pour Google ?
  • Les données structurées ont-elles été reprises ?

Ce qui est en général de la faute de l'agence

Des redirections oubliées, un noindex ou un robots.txt encore actif, une page vide pour Google, ou un balisage perdu malgré un cahier des charges clair : ce sont des défauts de construction, qu'un pro sérieux corrige sans discuter.

Demandez la correction par écrit, avec une date limite, et joignez les captures de Search Console qui prouvent la panne. Vous discutez ainsi sur des faits, pas sur des impressions.

Les décisions qui étaient de votre responsabilité

Certaines pertes viennent de vos propres choix : des textes coupés parce que la page vous paraissait plus belle, des pages supprimées, ou un nom de domaine changé en pleine refonte. Si vous avez validé des maquettes aux textes plus courts, la responsabilité est partagée.

Assumez-le franchement. L'agence discutera mieux avec vous, et fera plus facilement un geste sur ce qui relève vraiment de son travail.

Ce qu'il faudra écrire sur votre prochain cahier des charges

Pour le prochain projet, écrivez noir sur blanc ce qui doit être livré : un plan de redirection pour chaque adresse qui a du trafic, une vérification au lancement que les blocages de test ont disparu, et deux semaines de suivi Search Console.

À inscrire dans votre prochain cahier des charges
Des livrables nommés, pas des évidences

Avec ces lignes dans le cahier des charges, vous savez qui paie avant même de lancer le site. Notre blog détaille aussi les contrôles à faire avant la mise en ligne.

Vos questions les plus fréquentes

Voici les questions des dirigeants qui nous appellent après une refonte difficile. Les réponses sont courtes, les sections plus haut donnent tous les détails.

Certains détails ont l'air secondaires, mais ce sont eux qui sauvent vos visites en quelques jours au lieu d'attendre des mois.

Faut-il une redirection 301 pour chaque vieille page, ou juste les plus grosses ?

Toute page qui ramenait des visites, des liens ou des clients mérite sa redirection vers la nouvelle page la plus proche. Pour les pages mortes, sans aucun lien ni équivalent, une réponse franche « page supprimée » suffit. Dans le doute, redirigez : une ligne de redirection demande peu de travail, alors qu'une page oubliée perd tout le classement qu'elle avait gagné. Commencez par les 20 pages qui avaient le plus de trafic.

Ces redirections gardent-elles mon bon classement, ou je repars à zéro ?

Selon Google (via Reqst), une bonne redirection 301 permanente ne fait pas perdre de PageRank, la note de réputation qu'une page gagne grâce aux liens. La nouvelle page hérite donc de la réputation de l'ancienne. Il faut juste que Google repasse sur l'ancienne adresse pour voir le renvoi, d'où l'importance de garder vos redirections pour toujours. Une 302 provisoire, elle, ne transmet pas cette valeur.

Un nouveau site fait-il toujours baisser mes vues, même sans panne ?

Attendez-vous à un petit remous, le temps que Google relise vos pages, mais pas à une perte durable. Si la baisse continue après deux semaines, quelque chose a cassé. Une refonte menée avec les données de recherche peut même améliorer vos positions. Pendant ces deux semaines, suivez chaque jour vos clics dans Search Console pour repérer tout de suite une courbe qui ne remonte pas.

C'est quoi cette soft 404, et pourquoi c'est dangereux ?

C'est une page qui s'ouvre avec un code technique qui dit « tout va bien », mais dont le texte dit « introuvable » ou reste vide. Pour vous, tout a l'air normal, mais pour Google, c'est du vide : il la retire en douceur de ses résultats, et vos visites chutent en silence. Elle naît souvent quand une ancienne adresse mène vers un modèle de page resté sans contenu.

Faut-il garder les mêmes adresses pour ne prendre aucun risque ?

Si vos anciennes adresses sont propres et faciles à lire, gardez-les ! C'est le moyen le plus sûr d'éviter les risques, puisqu'il n'y a alors aucune redirection à faire. Ne les changez que si c'est vraiment nécessaire, par exemple si elles sont pleines de numéros illisibles. Dans ce cas, prévoyez une redirection 301 page par page et testez-la le jour du lancement sur vos 20 pages les plus visitées.

Que faut-il vérifier en premier si on s'effondre le jour de la mise en ligne ?

Regardez d'abord si votre balise de mesure est bien là, car son absence imite un crash. Comparez ensuite avec les clics de Search Console, qui ne dépendent pas de ce code. Ouvrez enfin le rapport Pages et cherchez les pages exclues par un noindex ou bloquées par le robots.txt. Ces contrôles prennent quelques minutes et expliquent les pires catastrophes, avant même de regarder les redirections.

Ce que vous pouvez faire dès cette semaine

Aujourd'hui, comparez Search Console et votre outil de statistiques pour vérifier si la baisse est réelle, puis lancez l'Inspection de l'URL sur l'accueil et vos cinq plus grosses anciennes pages. D'ici deux jours, envoyez à votre agence les quatre questions sur la responsabilité et exigez la liste de ses redirections. Cette semaine, réparez en priorité le noindex, les 404 et vos redirections, renvoyez votre sitemap et notez chaque correction avec sa date.

Si vous êtes seul dans l'équipe, ou si votre agence fait la morte, Linkysoft peut mener l'enquête et tout réparer. Nous travaillons au quotidien la conception et développement web ainsi que le marketing digital. Laissez-nous un message sur notre page de contact pour recevoir un devis adapté à votre entreprise.

Mots-clés: refonte de sitechute de trafic après refonteperte de positionnement Googleredirection 301Search Console après mise en ligneSEO refonte de sitecréation de site webnoindex après mise en ligne

Découvrez d'autres excellents articles sur ce même sujet.

Combien de temps faut-il pour créer un site web ? Le calendrier réel, et pourquoi les projets glissent

Une date de livraison ne tient que si l'on sait ce qui la fait bouger. Nous mettons donc un poids sur chaque étape, du cadrage aux tests, puis un coût en jours sur les retards les plus courants : 2 à 5 semaines d'attente pour les contenus, 1 à 3 semaines par tour de validation, 3 à 10 jours ouvrés pour chaque ajout demandé en cours de route. Vous repartez avec les cinq questions à poser avant de signer.

1 minutes de lecture

Que préparer avant de lancer un projet de site web, pour qu'il ne s'arrête pas en chemin

Sur un projet qui s'enlise, la fabrication demande 6 à 8 semaines de travail mais le calendrier affiche 4 ou 5 mois, et toute la différence est de l'attente. Nous mettons un prix en jours ouvrés sur chaque élément manquant, du texte qui ne vient pas à l'accès au domaine introuvable, nous détaillons l'arithmétique qui transforme dix semaines en cinq mois, et nous disons franchement quand la version plus petite du site est la bonne.

1 minutes de lecture

Combien coûte un site web ? Les prix réels et ce qui les fait varier

Une page unique de présentation coûte 600 à 1 500 dollars, un site vitrine 1 800 à 4 500 et une boutique en ligne 8 000 à 25 000, mais ces fourchettes ne servent à rien tant que l'on ignore ce qui pousse un devis vers le haut. Nous ouvrons donc un budget ligne par ligne, nous chiffrons chaque option, nous ajoutons la facture annuelle que personne n'annonce avant la signature, et nous disons franchement quand il vaut mieux dépenser moins.

1 minutes de lecture