refonte de site web et gestion des modifications

La redirection d’URL est la pratique consistant à résoudre une URL existante vers une autre, indiquant ainsi efficacement à vos visiteurs et à Google Search qu’une page a un nouvel emplacement. Les redirections sont particulièrement utiles dans les circonstances suivantes :

Vous avez déplacé votre site vers un nouveau domaine et vous souhaitez rendre la transition aussi fluide que possible.

Les utilisateurs accèdent à votre site via plusieurs URL différentes. Si, par exemple, votre page d’accueil est accessible de plusieurs manières (par exemple, http://example.com/home , http://home.example.com , ou http://www.example.com ), il est judicieux de choisir l’une de ces URL comme destination préférée ( canonique ) et d’utiliser des redirections pour envoyer le trafic des autres URL vers votre URL préférée.

Vous fusionnez deux sites Web et souhaitez vous assurer que les liens vers des URL obsolètes sont redirigés vers les bonnes pages.

Si vous utilisez une plateforme comme Blogger ou Shopify, celle-ci peut déjà disposer de solutions de redirection intégrées. Essayez de rechercher des articles d’aide (par exemple, recherchez « redirections blogger »).

Présentation des types de redirection

Bien que vos utilisateurs ne soient généralement pas en mesure de faire la différence entre les différents types de redirections, Google Search utilise les redirections comme un signal fort ou faible indiquant que la cible de la redirection doit être canonique. Le choix d’une redirection dépend de la durée pendant laquelle vous prévoyez de la maintenir en place et de la page que vous souhaitez que Google Search affiche dans les résultats de recherche :

Le tableau suivant explique les différentes méthodes que vous pouvez utiliser pour configurer des redirections permanentes et temporaires, classées selon la probabilité que Google puisse les interpréter correctement (par exemple, une redirection côté serveur a la plus grande chance d’être interprétée correctement par Google). Choisissez le type de redirection adapté à votre situation et à votre site :

Redirections côté serveur

La configuration de redirections côté serveur nécessite un accès aux fichiers de configuration du serveur (par exemple, le fichier .htaccess sur Apache) ou la définition des en-têtes de redirection avec des scripts côté serveur (par exemple, PHP). Vous pouvez créer des redirections permanentes et temporaires côté serveur.

Redirections permanentes côté serveur

Si vous devez modifier l’URL d’une page telle qu’elle apparaît dans les résultats des moteurs de recherche, nous vous recommandons d’utiliser une redirection permanente côté serveur dans la mesure du possible. C’est le meilleur moyen de garantir que Google Search et les utilisateurs sont dirigés vers la bonne page. Les codes d’état 301 et 308 signifient qu’une page a été déplacée de façon permanente vers un nouvel emplacement.

Redirections temporaires côté serveur

Si vous souhaitez simplement envoyer les utilisateurs vers une page différente temporairement, utilisez une redirection temporaire. Cela garantira également que Google conserve l’ancienne URL dans ses résultats plus longtemps. Par exemple, si un service proposé par votre site est temporairement indisponible, vous pouvez configurer une redirection temporaire pour envoyer les utilisateurs vers une page expliquant la situation, sans compromettre l’URL d’origine dans les résultats de recherche.

Implémenter des redirections côté serveur

L’implémentation des redirections côté serveur dépend de votre environnement d’hébergement et de serveur, ou du langage de script du backend de votre site.

Pour configurer une redirection permanente avec PHP, utilisez la fonction header(). Vous devez définir les en-têtes avant d’envoyer quoi que ce soit à l’écran :

Si vous avez accès aux fichiers de configuration de votre serveur Web, vous pourrez peut-être écrire vous-même les règles de redirection. Suivez les guides de votre serveur Web :

Apache : Consultez le tutoriel Apache .htaccess , le guide de réécriture d’URL Apache et la documentation Apache mod_alias . Par exemple, vous pouvez utiliser mod_alias pour configurer la forme la plus simple de redirections :# Redirection permanente : Redirect permanent “/old” “http://example.com/new” # Redirection temporaire : Redirect temp “/two-old” “http://example.com/two-new”Pour des redirections plus complexes, utilisez mod_rewrite . Par exemple :RewriteEngine on # rediriger la page de service vers une nouvelle page avec une redirection permanente RewriteRule “^/service$” “/about/service” [R=301] # rediriger la page de service vers une nouvelle page avec une redirection temporaire RewriteRule “^/service$” “/about/service” [R]

NGINX : Lisez l’article sur la création de règles de réécriture NGINX sur le blog NGINX. Comme pour Apache, vous avez plusieurs choix pour créer des redirections. Par exemple :location = /service { # pour une redirection permanente return 301 $scheme://example.com/about/service # pour une redirection temporaire return 302 $scheme://example.com/about/service }Pour des redirections plus complexes, utilisez la directive rewrite :location = /service { # pour une redirection permanente rewrite service?name=$1 ^service/offline/([a-z]+)/?$ permanent; # pour une redirection temporaire rewrite service?name=$1 ^service/offline/([a-z]+)/?$ redirect; }

Pour tous les autres serveurs Web, vérifiez auprès de votre gestionnaire de serveur ou de votre hébergeur, ou recherchez des guides sur votre moteur de recherche préféré (par exemple, recherchez « redirections LiteSpeed »).

meta refresh et son équivalent HTTP

Si les redirections côté serveur ne peuvent pas être implémentées sur votre plateforme, les redirections meta refresh peuvent être une alternative viable. Google différencie deux types de redirections meta refresh :

Redirection meta refresh instantanée : Se déclenche dès que la page est chargée dans un navigateur. Google Search interprète les redirections meta refresh instantanées comme des redirections permanentes.

Redirection meta refresh différée : Se déclenche uniquement après un nombre arbitraire de secondes défini par le propriétaire du site. Google Search interprète les redirections meta refresh différées comme des redirections temporaires.

Placez la redirection meta refresh soit dans la section head du HTML, soit dans l’en-tête HTTP avec du code côté serveur. Par exemple, voici une redirection meta refresh instantanée dans la section head du HTML :

Voici un exemple de l’équivalent dans l’en-tête HTTP, que vous pouvez injecter avec des scripts côté serveur :

Pour créer une redirection différée, interprétée comme une redirection temporaire par Google, définissez l’attribut content sur le nombre de secondes pendant lesquelles la redirection doit être différée :

Redirections d’emplacement JavaScript

Google Search interprète et exécute JavaScript à l’aide du service de rendu Web une fois que l’exploration de l’URL est terminée. N’utilisez les redirections JavaScript que si vous ne pouvez pas effectuer de redirections côté serveur ou meta refresh. Bien que Google tente de rendre chaque URL explorée par Googlebot, le rendu peut échouer pour diverses raisons. Cela signifie que si vous configurez une redirection JavaScript, Google pourrait ne jamais la voir si le rendu du contenu a échoué.

Pour configurer une redirection JavaScript, définissez la propriété location sur l’URL cible de la redirection dans un bloc de script dans le head HTML. Par exemple :

Crypto-redirections

Si vous ne pouvez implémenter aucune des méthodes de redirection traditionnelles, vous devriez tout de même faire un effort pour informer vos utilisateurs que la page ou son contenu a été déplacé. Le moyen le plus simple consiste à ajouter un lien pointant vers la nouvelle page accompagné d’une brève explication. Par exemple :

Cela aide les utilisateurs à trouver votre nouveau site et Google peut comprendre cela comme une crypto-redirection. Ne comptez pas sur les crypto-redirections pour informer les moteurs de recherche que votre contenu a été déplacé, sauf si vous n’avez pas d’autre choix. Contactez votre fournisseur d’hébergement pour obtenir de l’aide sur les redirections traditionnelles avant de recourir aux crypto-redirections.

Versions alternatives d’une URL

Lorsque vous redirigez une URL, Google garde une trace à la fois de la source de redirection (l’ancienne URL) et de la cible de redirection (la nouvelle URL). L’une des URL sera la canonique ; laquelle dépend de signaux tels que le fait que la redirection soit temporaire ou permanente. L’autre URL devient un nom alternatif de l’URL canonique. Les noms alternatifs sont des versions différentes d’une URL canonique que les utilisateurs pourraient reconnaître et auxquelles ils pourraient faire davantage confiance. Les noms alternatifs peuvent apparaître dans les résultats de recherche lorsqu’une requête d’utilisateur suggère qu’ils pourraient faire davantage confiance à l’ancienne URL.

Par exemple, si vous avez déménagé vers un nouveau nom de domaine , il est très probable que Google continue d’afficher occasionnellement les anciennes URL dans les résultats, même si les nouvelles URL sont déjà indexées. C’est normal et à mesure que les utilisateurs s’habituent au nouveau nom de domaine, les noms alternatifs disparaîtront sans que vous ayez à faire quoi que ce soit.

Recommandations pour tous les déplacements de site

Divisez votre déplacement en étapes plus petites, si cela a du sens pour votre site. Nous vous recommandons de ne déplacer initialement qu’une partie du site pour tester les effets sur le trafic et l’indexation de recherche. Après cela, vous pouvez déplacer le reste de votre site en une seule fois ou par morceaux. Lors du choix de la section de test initiale du site, choisissez une section qui change moins fréquemment et qui n’est pas significativement affectée par des événements fréquents ou imprévisibles. Gardez également à l’esprit que bien que déplacer une seule section soit un excellent moyen de tester votre déplacement, ce n’est pas nécessairement représentatif d’un déplacement de site complet en ce qui concerne la recherche. Plus vous déplacez de pages, plus vous risquez de rencontrer des problèmes supplémentaires à résoudre. Une planification minutieuse peut minimiser les problèmes.

Planifiez votre déplacement pour qu’il coïncide avec un trafic plus faible, si possible. Si votre trafic est saisonnier ou diminue certains jours de la semaine, il est logique de déplacer votre site pendant les baisses de trafic récurrentes. Cela signifie que moins de personnes seront affectées par les problèmes potentiels qui peuvent survenir pendant le déplacement du site, et davantage de ressources de votre serveur pourront être consacrées à l’exploration de votre site par Googlebot.

Attendez-vous à une fluctuation temporaire du classement du site pendant le déplacement. Avec tout changement significatif sur un site, vous pouvez rencontrer des fluctuations de classement pendant que Google réexplore et réindexe votre site. En règle générale, un site Web de taille moyenne peut prendre quelques semaines pour que la plupart des pages soient déplacées dans notre index ; les sites plus grands peuvent prendre plus de temps. La vitesse à laquelle Googlebot et nos systèmes découvrent et traitent les URL déplacées dépend en grande partie du nombre d’URL et de la vitesse de votre serveur. Soumettre un sitemap peut aider à accélérer le processus de découverte, et il est tout à fait acceptable de déplacer votre site par sections.

Posez des questions sur Google Search Central. Il existe de nombreux bons conseils sur notre page d’aide et des cas spécifiques répondus dans nos forums d’utilisateurs . Si vous ne trouvez pas de réponse, vous pouvez poser une question en direct à l’un de nos spécialistes Google Search pendant nos heures de bureau SEO .

S’il implique un changement d’URL, vous pourriez envisager un test A/B ou un essai. Prévoyez quelques semaines pour permettre à l’exploration et à l’indexation de prendre en compte les changements, ainsi que du temps pour surveiller le trafic.

Déplacer un site sans changement d’URL

Ce guide montre comment minimiser l’impact sur vos performances Google Search lors de la migration de l’infrastructure d’hébergement de votre site. Par exemple, lors du changement de fournisseur d’hébergement ou du passage à un réseau de distribution de contenu (CDN). Ce guide est uniquement destiné aux migrations qui n’affectent pas l’URL visible par l’utilisateur. Vous modifiez les URL ? Si vous effectuez des changements d’URL visibles, commencez par Déplacements de site avec changements d’URL .

Présentation

Consultez les FAQ et les informations de base sur les déplacements de site . Sachez à quoi vous attendre et comment cela pourrait affecter vos utilisateurs et vos classements.

Préparez la nouvelle infrastructure d’hébergement . Téléchargez votre contenu sur les nouveaux serveurs ou configurez votre CDN et vos serveurs d’origine, et testez-le.

Démarrez le déplacement du site . Modifiez les paramètres DNS de votre nom de domaine pour pointer vers la nouvelle infrastructure d’hébergement. Cette étape est l’étape réelle de déplacement du site qui lance le processus d’envoi de votre trafic vers la nouvelle infrastructure.

Arrêtez . Arrêtez l’ancienne infrastructure d’hébergement lorsque vous êtes certain que tous les utilisateurs reçoivent correctement le contenu de la nouvelle infrastructure et que personne n’utilise l’ancienne infrastructure.

Préparer la nouvelle infrastructure d’hébergement

Copiez et testez votre nouveau site

Tout d’abord, téléchargez une copie de votre site sur votre nouveau fournisseur d’hébergement. Une fois cela fait, vérifiez qu’il fonctionne comme prévu en testant minutieusement tous les aspects de la façon dont vos utilisateurs interagissent avec votre site. Voici quelques suggestions :

Ouvrez votre nouveau site dans un navigateur Web et examinez tous les éléments de votre site : pages Web, images, formulaires et téléchargements (tels que les fichiers PDF).

Créez un environnement de test , peut-être avec un accès restreint par IP, à travers lequel vous testez toutes les fonctionnalités avant que le site Web ne soit mis en ligne.

Autorisez les tests publics avec un nom d’hôte temporaire pour votre nouvelle infrastructure (comme beta.example.com) afin que vous puissiez tester l’accessibilité par les navigateurs. Un nom d’hôte temporaire peut vous aider à tester si Googlebot peut atteindre votre site ou non.

Vérifiez que Googlebot est capable d’accéder à la nouvelle infrastructure d’hébergement

Si vous n’avez pas encore de compte Search Console, créez un nouveau compte pour votre site afin de vous aider à surveiller l’accès et le trafic de Google. Si vous avez créé un nom d’hôte temporaire pour votre nouveau site, créez également un compte pour ce nom d’hôte. Vérifiez que Googlebot peut accéder à votre nouvelle infrastructure à l’aide de l’outil d’inspection d’URL dans Search Console. Attention : Vérifiez la configuration de votre pare-feu ou la protection contre le déni de service (DoS). Assurez-vous qu’elle ne bloque pas la capacité de Googlebot à atteindre le DNS ou les serveurs du fournisseur d’hébergement.

Réduisez la valeur TTL pour vos enregistrements DNS

Vous pouvez aider à accélérer le déplacement de votre site si vous réduisez la valeur TTL des enregistrements DNS de votre site, ce qui permettra aux nouveaux paramètres de se propager plus rapidement aux FAI. Les paramètres DNS sont généralement mis en cache par les FAI en fonction du paramètre Time to Live (TTL) spécifié . Envisagez de réduire le TTL à une valeur faible conservatrice (par exemple, quelques heures) au moins une semaine avant le déplacement du site pour rafraîchir les caches DNS plus rapidement.

Vérifiez la vérification Search Console

Si vous utilisez la méthode du fichier HTML pour vérifier la propriété de votre site dans Search Console, assurez-vous de ne pas oublier d’inclure votre fichier de vérification actuel dans votre nouvelle copie du site.

De même, si vous incluez dans les modèles de votre système de gestion de contenu une balise meta ou Google Analytics pour vérifier la propriété, assurez-vous que la nouvelle copie CMS les inclut également.

Démarrez le déplacement du site

Supprimez tous les blocages temporaires à l’exploration . Lors de la création de la nouvelle copie d’un site, certains propriétaires de site utilisent un fichier robots.txt pour interdire toute exploration par Googlebot et d’autres robots d’exploration, ou utilisent des balises meta noindex ou des en-têtes HTTP pour bloquer l’indexation du contenu. Assurez-vous de supprimer tous ces blocages de la nouvelle copie du site lorsque vous êtes prêt à commencer le déplacement.

Mettez à jour les paramètres DNS . Vous démarrez le déplacement du site en mettant à jour les enregistrements DNS pour pointer vers le nouveau fournisseur d’hébergement. Vérifiez auprès de votre fournisseur DNS comment faire cela. Parce que le paramètre de cache DNS est mis en cache, les enregistrements prennent un certain temps à se propager complètement à tous les utilisateurs sur Internet.

Surveillez le trafic

Gardez un œil sur les journaux du serveur sur les nouveaux et les anciens serveurs. À mesure que le paramètre DNS se propage et que le trafic du site se déplace, vous remarquerez une baisse du trafic enregistré sur les anciens serveurs et une augmentation correspondante du trafic sur les nouveaux serveurs.

Utilisez différents outils de vérification DNS publics. Vérifiez que différents FAI dans le monde mettent à jour correctement vos nouveaux paramètres DNS.

Surveillez l’exploration. Surveillez les graphiques de couverture de l’index dans Search Console. Laissez Googlebot décider. Plutôt que de définir manuellement un taux d’exploration maximal dans Search Console , gardez le paramètre sur Laisser Googlebot décider . De cette façon, les paramètres conçus uniquement pour l’ancien système n’interféreront pas avec les exigences de votre nouveau système.

Une note sur le taux d’exploration de Googlebot

Il est normal de constater une baisse temporaire du taux d’exploration de Googlebot immédiatement après le lancement, suivie d’une augmentation constante au cours des semaines suivantes, potentiellement à des taux qui peuvent être plus élevés qu’avant le déplacement.

Cette fluctuation se produit parce que nous déterminons le taux d’exploration d’un site en fonction de nombreux signaux, et ces signaux changent lorsque votre hébergement change. Tant que Googlebot ne rencontre aucun problème grave ou ralentissement lors de l’accès à votre nouvelle infrastructure de service, il essaiera d’explorer votre site aussi rapidement que nécessaire et possible.

Arrêtez l’ancien hébergement

Vérifiez les journaux du serveur sur l’ancien fournisseur et, une fois que le trafic vers l’ancien fournisseur atteint zéro, vous pouvez arrêter votre ancienne infrastructure d’hébergement. Cela termine le déplacement du site.

Déplacer un site avec changement d’URL

Cet article décrit comment modifier les URL des pages existantes sur votre site avec un impact minimal sur vos résultats Google Search. Les exemples de ce type de déplacement de site incluent :

Vous ne modifiez pas les URL ? Si vous effectuez des changements de site sans changements d’URL visibles, commencez ici à la place .

Présentation

Consultez les informations de base sur les déplacements de site . Sachez à quoi vous attendre et comment cela pourrait affecter vos utilisateurs et vos classements. Si vous passez de HTTP à HTTPS, consultez les meilleures pratiques pour HTTPS .

Démarrez le déplacement du site en configurant le serveur pour rediriger des anciennes URL vers les nouvelles.

FAQ pour tous les déplacements de site avec changement d’URL

Google recommande-t-il de tout déplacer ensemble, ou est-il acceptable de déplacer par sections ? Déplacer par sections est acceptable.

Comment puis-je tester combien de pages ont été indexées ? Vérifiez les données pour chaque propriété séparément dans Search Console. Utilisez le rapport d’état de l’index pour une vue d’ensemble. Utilisez le rapport Sitemaps pour voir combien d’URL soumises dans un sitemap ont été indexées.

Combien de temps faudra-t-il à Google pour reconnaître les changements d’URL ? Il n’y a pas de fréquences d’exploration fixes ; cela dépend de la taille de votre site et de la vitesse d’exploration possible. Le déplacement se fait par URL.

Perdez-vous le crédit pour les liens lorsque vous redirigez vers de nouvelles URL ? Non, les redirections 301 ou 302 ne causent pas de perte de PageRank .

Migration de HTTP vers HTTPS

Assurez-vous d’ajouter la propriété HTTPS à Search Console. Search Console traite HTTP et HTTPS séparément ; les données pour ces propriétés ne sont pas partagées dans Search Console. Donc, si vous avez des pages dans les deux protocoles, vous devez avoir une propriété Search Console distincte pour chacune.

FAQ sur la migration HTTP vers HTTPS

Comme pour toutes les migrations, vous pouvez rencontrer une certaine fluctuation de classement pendant une migration. Cependant, pour éviter les pièges spécifiques au HTTPS, consultez les informations sur les meilleures pratiques pour les pages HTTPS .

Les sites HTTPS bénéficient d’un léger coup de pouce au classement, mais ne vous attendez pas à un changement visible. Google utilise HTTPS comme un signal de classement positif. Ce signal est l’un parmi beaucoup d’autres, et porte actuellement moins de poids qu’un contenu de site de haute qualité ; vous ne devriez pas vous attendre à un avantage SEO majeur pour le passage au HTTPS à court terme. À plus long terme, Google pourrait augmenter la force du coup de pouce HTTPS.

Oui, c’est acceptable. Commencez par une partie, testez-la, puis déplacez-en davantage à votre rythme.

Si vous migrez de HTTP vers HTTPS par morceaux, et que vous souhaitez éviter l’indexation précoce des URL mises en scène, nous vous recommandons d’utiliser rel=canonical plutôt que des redirections. Si vous utilisez des redirections, vous ne pourrez pas tester les pages redirigées.

Vérifiez HTTP et HTTPS séparément dans Search Console, et utilisez le rapport de couverture de l’index pour voir quelles pages ont été indexées.

Il n’y a pas de fréquences d’exploration fixes ; cela dépend de la taille de votre site et de la vitesse d’exploration possible. Le déplacement se fait par URL.

Nous vous recommandons de mettre à jour votre fichier robots.txt pour pointer vers la version HTTPS de vos fichiers sitemap. Nous vous recommandons également de ne lister que les URL HTTPS dans votre sitemap.

Gardez à l’esprit que si vous redirigez chaque URL de votre site de HTTP vers HTTPS, vous n’aurez toujours qu’un seul fichier robots.txt accessible aux robots d’exploration. Par exemple, si http://example.com/robots.txt redirige vers https://example.com/robots.txt , le contenu de la version HTTP ne sera pas visible pour Google et les autres moteurs de recherche.

Vous pouvez créer un sitemap séparé juste pour la section mise à jour de votre site. Cela vous permettra de suivre l’indexation de la section d’essai plus précisément. Assurez-vous de ne pas dupliquer ces URL dans d’autres sitemaps, cependant.

Listez toutes les nouvelles URL HTTPS dans votre sitemap, et supprimez les anciennes URL HTTP. Si vous préférez créer un nouveau sitemap, listez uniquement les nouvelles URL HTTPS dedans.

HSTS augmente la sécurité, mais ajoute de la complexité à votre stratégie de restauration. Voir les meilleures pratiques HTTPS pour plus d’informations.

Si vous souhaitez utiliser un sitemap Google News pour la nouvelle section HTTPS, vous devrez contacter l’équipe News pour les informer du changement de protocole, puis dans votre propriété HTTPS dans Search Console, vous pourrez soumettre un nouveau sitemap Google News à mesure que vous migrez chaque section de votre site vers HTTPS.

Le centre des éditeurs Google News gère les déplacements HTTP vers HTTPS de manière transparente. En général, vous n’avez rien à faire du point de vue de Google News, sauf si vous utilisez également des sitemaps News. Dans ce cas, contactez l’équipe News et informez-les du changement. Vous pouvez également informer l’équipe du changement de sections, par exemple si vous passez au HTTPS, vous pouvez spécifier que vous déplacez http://example.com/section vers https://example.com/section .

Préparer le nouveau site

Les détails de la préparation du site varient pour chaque déplacement de site, mais généralement vous effectuerez une ou plusieurs des opérations suivantes :

Transférez les images et les téléchargements (tels que les documents PDF) que vous hébergez actuellement. Ceux-ci pourraient déjà recevoir du trafic de Google Search ou de liens, et il est utile d’informer les utilisateurs et Googlebot de leur nouvel emplacement.

Pour un déplacement vers HTTPS , obtenez et configurez les certificats TLS requis sur votre serveur.

Configurez un robots.txt pour votre nouveau site

Le fichier robots.txt pour un site contrôle quelles zones Googlebot peut explorer. Assurez-vous que les directives dans le fichier robots.txt du nouveau site reflètent correctement les parties que vous souhaitez bloquer de l’exploration.

Notez que certains propriétaires de site bloquent toute exploration pendant le développement. Si vous suivez cette stratégie, assurez-vous de préparer à quoi le fichier robots.txt devrait ressembler une fois que le déplacement du site commence. De même, si vous utilisez des directives noindex pendant le développement, préparez une liste d’URL à partir desquelles vous supprimerez les directives noindex lorsque vous commencerez le déplacement du site.

Fournissez des erreurs pour le contenu supprimé ou fusionné

Pour le contenu sur l’ancien site qui ne sera pas transféré vers le nouveau site, assurez-vous que ces URL orphelines renvoient correctement un code d’état de réponse HTTP 404 ou 410. Vous pouvez renvoyer le code d’état d’erreur à l’ancienne URL dans le panneau de configuration de votre nouveau site, ou vous pouvez créer une redirection pour une nouvelle URL et faire en sorte qu’elle renvoie le code d’erreur HTTP. Évitez les redirections non pertinentes

Ne redirigez pas de nombreuses anciennes URL vers une destination non pertinente, telle que la page d’accueil du nouveau site. Cela peut confondre les utilisateurs et pourrait être traité comme une erreur 404 logicielle . Cependant, si vous avez consolidé du contenu précédemment hébergé sur plusieurs pages vers une nouvelle page unique, il est acceptable de rediriger les anciennes URL vers cette nouvelle page consolidée.

Assurez des paramètres Search Console corrects

Si vous ne l’avez pas déjà fait, vérifiez que vous possédez à la fois les anciens et les nouveaux sites dans Search Console. Assurez-vous de vérifier toutes les variantes des anciens et nouveaux sites. Par exemple, vérifiez www.example.com et example.com , et incluez à la fois les variantes de site HTTPS et HTTP si vous utilisez des URL HTTPS. Faites cela pour les anciens et les nouveaux sites.

Assurez-vous que votre vérification Search Console continuera de fonctionner après le déplacement du site. Si vous utilisez une méthode de vérification différente, gardez à l’esprit que les jetons de vérification peuvent être différents lorsque l’URL change.

Si vous utilisez la méthode du fichier HTML pour vérifier la propriété de votre site dans Search Console, assurez-vous de ne pas oublier d’inclure votre fichier de vérification actuel dans votre nouvelle copie du site.

De même, si vous vérifiez la propriété avec un fichier include qui référence une balise meta ou Google Analytics pour vérifier la propriété, assurez-vous que la nouvelle copie CMS les inclut également.

Si vous aviez modifié certains des paramètres de configuration dans Search Console pour votre ancien site, assurez-vous que les paramètres du nouveau site sont mis à jour pour refléter ces changements également. Par exemple :

Paramètres d’URL : Si vous avez configuré des paramètres d’URL pour contrôler l’exploration ou l’indexation de vos anciennes URL, assurez-vous que les paramètres sont également appliqués au nouveau site si nécessaire.

Géociblage : Votre ancien site pourrait avoir un géociblage explicite, tel qu’un domaine géociblable ou un domaine de premier niveau de code pays (tel que .co.uk ). Appliquez le même paramètre au nouveau site si vous souhaitez continuer à cibler la même région. Cependant, si votre déplacement de site est destiné à aider votre entreprise à se développer mondialement et que vous ne souhaitez pas que votre site soit associé à un pays ou une région, sélectionnez Non répertorié dans la liste déroulante de la page Paramètres du site.

Taux d’exploration : Nous recommandons de ne pas limiter le taux d’exploration de Googlebot dans Search Console pour les anciennes et les nouvelles URL. Nous vous conseillons de ne pas configurer de paramètre de taux d’exploration non plus. Ne faites cela que si vous savez que votre site ne peut pas gérer le volume d’exploration de Googlebot. Si vous avez déjà limité le taux d’exploration de Googlebot pour votre ancien site, envisagez de le supprimer. Google dispose d’algorithmes qui détectent automatiquement qu’un déplacement de site a été implémenté et nous modifions le comportement d’exploration de Googlebot afin que notre indexation reflète rapidement le déplacement du site.

Backlinks désavoués : Si vous avez téléchargé un fichier pour désavouer des liens sur votre ancien site, nous vous recommandons de le retélécharger à nouveau en utilisant le compte Search Console du nouveau site.

Si votre nouveau site est pour un domaine récemment acheté, vous voudrez vous assurer qu’il est exempt de tout problème en suspens de l’ancien propriétaire. Vérifiez les paramètres suivants :

Action manuelle pour spam précédent. Pour les sites qui ne sont pas conformes à nos politiques de spam , Google est disposé à prendre des mesures manuelles, telles que les rétrograder ou même les supprimer complètement de nos résultats de recherche. Vérifiez la page Actions manuelles dans Search Console pour voir si des actions manuelles ont été appliquées au nouveau site, et résolvez tous les problèmes listés là avant de déposer une demande de réexamen .

URL supprimées . Assurez-vous qu’il ne reste aucune suppression d’URL de l’ancien propriétaire, en particulier une suppression d’URL à l’échelle du site. De plus, avant de soumettre des demandes de suppression d’URL pour votre contenu, assurez-vous de comprendre quand ne pas utiliser l’outil de suppression d’URL .

Utilisez l’analyse Web

Pendant un déplacement de site, il est important d’analyser l’utilisation sur les anciens et les nouveaux sites. Les logiciels d’analyse Web peuvent aider avec cela. Généralement, la configuration de l’analyse Web consiste en un morceau de JavaScript intégré dans vos pages. Les détails pour le suivi de différents sites varient en fonction de votre logiciel d’analyse et de ses paramètres de journalisation, de traitement ou de filtrage. Vérifiez auprès de votre fournisseur de logiciel d’analyse pour obtenir de l’aide. De plus, si vous aviez prévu d’apporter des modifications de configuration à votre logiciel d’analyse, c’est le bon moment. Si vous utilisez Google Analytics, envisagez de créer un nouveau profil pour votre nouveau site si vous souhaitez une séparation propre dans vos rapports de contenu.

Assurez-vous que votre serveur dispose de suffisamment de ressources informatiques

Après une migration, Google explorera votre nouveau site plus intensément que d’habitude. C’est parce que votre site redirige le trafic de l’ancien vers le nouveau site, et toute exploration de l’ancien site sera redirigée vers le nouveau site, en plus de toute autre exploration. Assurez-vous que votre nouveau site a une capacité suffisante pour gérer l’augmentation du trafic de Google.

Mettez à jour le surligneur de données

Si vous avez utilisé le surligneur de données pour mapper vos anciennes pages, assurez-vous de refaire le mappage pour votre nouveau site.

Mettez à jour les liens d’application

Dès que vos pages HTTPS sont prêtes, mettez à jour tous les liens d’application destinés à ouvrir vos pages Web dans une application lorsqu’ils sont affichés dans les résultats de recherche Google. Mettez à jour ces liens pour pointer vers les nouvelles URL HTTPS. Les redirections ne fonctionneront pas pour ces liens ; les clics sur navigateur mobile ouvriront la page dans le navigateur au lieu de l’application, sauf si vous mettez à jour votre gestion des liens d’application.

Il est important de mapper les URL de votre ancien site vers les URL du nouveau site. Cette section décrit un certain nombre d’approches générales que vous pouvez adopter pour évaluer correctement les URL sur vos deux sites et faciliter le mappage. Les détails exacts de la façon dont vous générez ce mappage varieront en fonction de votre infrastructure de site Web actuelle et des détails du déplacement du site.

Préparer le mappage d’URL

Il est important de mapper les URL de votre ancien site vers les URL du nouveau site. Cette section décrit un certain nombre d’approches générales que vous pouvez adopter pour évaluer correctement les URL sur vos deux sites et faciliter le mappage. Les détails exacts de la façon dont vous générez ce mappage varieront en fonction de votre infrastructure de site Web actuelle et des détails du déplacement du site.

Déterminez vos anciennes URL

Dans les déplacements de site les plus simples, vous n’aurez peut-être pas besoin de générer une liste de vos anciennes URL. Par exemple, vous pourriez utiliser une redirection côté serveur générique si vous modifiez le domaine de votre site (par exemple, passer de example.com à example.net ).

Dans les déplacements de site plus complexes, vous devrez générer une liste d’anciennes URL et les mapper vers leurs nouvelles destinations. La façon dont vous obtenez une liste d’anciennes URL dépend de la configuration actuelle de votre site Web, mais voici quelques conseils pratiques :

Commencez par vos URL importantes . Pour les trouver : Regardez dans vos sitemaps car il est probable que vos URL les plus importantes aient été soumises dans Search Console de cette façon

Vérifiez la fonctionnalité Liens vers votre site dans Search Console pour les pages qui ont des liens internes et externes

Utilisez votre système de gestion de contenu, qui peut généralement fournir un moyen facile d’obtenir une liste de toutes les URL qui hébergent du contenu.

Vérifiez les journaux de votre serveur pour les URL qui ont été visitées au moins une fois récemment. Choisissez une période qui a du sens pour votre site, en gardant à l’esprit la variation saisonnière du trafic.

Incluez les images et les vidéos —Assurez-vous d’inclure les URL du contenu intégré dans vos plans de déplacement de site : vidéos, images, JavaScript et fichiers CSS. Ces URL doivent être déplacées de la même manière que tout autre contenu sur votre site Web.

Créez un mappage des anciennes vers les nouvelles URL

Une fois que vous avez la liste des anciennes URL, décidez vers où chacune doit rediriger. La façon dont vous stockez ce mappage dépend de vos serveurs et du déplacement du site. Vous pourriez utiliser une base de données, ou configurer certaines règles de réécriture d’URL sur votre système pour les modèles de redirection courants.

Mettez à jour tous les détails d’URL

Une fois que votre mappage d’URL est défini, vous voudrez faire trois choses pour préparer les pages pour le déplacement.

Mettez à jour les annotations pour pointer vers les nouvelles URL dans le HTML ou l’entrée sitemaps pour chaque page : Chaque URL de destination doit avoir une balise rel=”canonical” auto-référencée.

Si le site que vous avez déplacé a des pages multilingues ou multinationales annotées à l’aide d’annotations rel-alternate-hreflang , assurez-vous de mettre à jour les annotations pour utiliser les nouvelles URL.

Si le site que vous avez déplacé a un homologue mobile, assurez-vous de mettre à jour les annotations rel-alternate-media pour utiliser les nouvelles URL. En savoir plus dans nos directives pour les sites Web sur smartphone .

Mettez à jour les liens internes. Modifiez les liens internes sur le nouveau site des anciennes URL vers les nouvelles URL. Vous pouvez utiliser le mappage généré précédemment pour aider à trouver et mettre à jour les liens si nécessaire.

Enregistrez les listes suivantes pour votre déplacement final : Un fichier sitemap contenant les nouvelles URL dans le mappage. Voir notre documentation sur la création d’un sitemap .

Une liste de sites pointant vers vos anciennes URL. Vous pouvez trouver les liens vers votre site dans Search Console.

Préparez les redirections 301

Une fois que vous avez un mappage et que votre nouveau site est prêt, l’étape suivante consiste à configurer des redirections HTTP 301 sur votre serveur des anciennes URL vers les nouvelles URL comme vous l’avez indiqué dans votre mappage.

Utilisez des redirections HTTP 301. Bien que Googlebot prenne en charge plusieurs types de redirections , nous vous recommandons d’utiliser des redirections HTTP 301 si possible.

Évitez d’enchaîner les redirections. Bien que Googlebot puisse suivre jusqu’à 10 sauts dans une « chaîne » de redirections multiples (par exemple, Page 1 > Page 2 > Page 3), nous conseillons de rediriger vers la destination finale. Si cela n’est pas possible, gardez le nombre de redirections dans la chaîne faible, idéalement pas plus de 3 et moins de 5. L’enchaînement des redirections ajoute de la latence pour les utilisateurs, et tous les agents utilisateurs et navigateurs ne prennent pas en charge les longues chaînes de redirection.

Testez les redirections. Vous pouvez utiliser l’outil d’inspection d’URL pour tester des URL individuelles, ou des outils de ligne de commande ou des scripts pour tester un grand nombre d’URL.

Démarrez le déplacement du site

Décidez comment vous allez déplacer votre site — tout à la fois, ou par sections : Petits ou moyens sites : Nous recommandons de déplacer toutes les URL de votre site simultanément au lieu de déplacer une section à la fois. Cela aide les utilisateurs à mieux interagir avec le site sous sa nouvelle forme, et aide nos algorithmes à détecter le déplacement du site et à mettre à jour notre index plus rapidement.

Grands sites : Vous pouvez choisir de déplacer les grands sites une section à la fois. Cela peut faciliter la surveillance, la détection et la correction des problèmes plus rapidement.

Mettez à jour vos fichiers robots.txt : Sur l’ancien site , supprimez toutes les directives robots.txt. Cela permet à Googlebot de découvrir toutes les redirections vers le nouveau site et de mettre à jour notre index. Gardez à l’esprit que les robots d’exploration ne verront pas le contenu de l’ancien fichier robots.txt une fois que vous aurez activé les redirections.

Sur le nouveau site , assurez-vous que le fichier robots.txt autorise toute exploration. Cela inclut l’exploration des images, CSS, JavaScript et autres ressources de page, en dehors des URL dont vous êtes certain que vous ne voulez pas qu’elles soient explorées.

Configurez l’ancien site Web pour rediriger les utilisateurs et Googlebot vers le nouveau site en fonction du mappage d’URL.

Soumettez un changement d’adresse dans Search Console pour l’ancien site .Si vous déplacez votre site de HTTP vers HTTPS, vous n’avez pas besoin d’utiliser l’outil de changement d’adresse.

Gardez les redirections aussi longtemps que possible , généralement au moins 1 an. Ce délai permet à Google de transférer tous les signaux vers les nouvelles URL, y compris la réexploration et la réaffectation des liens sur d’autres sites qui pointent vers vos anciennes URL.Du point de vue des utilisateurs, envisagez de garder les redirections indéfiniment. Cependant, les redirections sont lentes pour les utilisateurs, alors essayez de mettre à jour vos propres liens et tous les liens à fort volume provenant d’autres sites Web pour pointer vers les nouvelles URL.

Soumettez le nouveau sitemap dans Search Console . Cela aidera Google à en savoir plus sur les nouvelles URL. À ce stade, vous pouvez supprimer votre ancien sitemap, car Google utilisera le nouveau sitemap à l’avenir.

Le temps qu’il faut à Googlebot et à nos systèmes pour découvrir et traiter toutes les URL dans le déplacement du site dépend de la vitesse de vos serveurs et du nombre d’URL impliquées. En règle générale, un site Web de taille moyenne peut prendre quelques semaines pour que la plupart des pages soient déplacées, et les sites plus grands prennent plus de temps. La vitesse à laquelle Googlebot et nos systèmes découvrent et traitent les URL déplacées dépend du nombre d’URL et de la vitesse du serveur.Notez que la visibilité de votre contenu dans la recherche Web peut fluctuer temporairement pendant le déplacement. C’est normal et le classement d’un site se stabilisera avec le temps.

Mettez à jour les liens entrants

Immédiatement après le début du déplacement du site, essayez de mettre à jour autant de liens entrants que possible pour améliorer l’expérience utilisateur et réduire la charge de votre serveur. Ceux-ci incluent :

Liens externes : Essayez de contacter les sites dans la liste enregistrée des sites pointant vers votre contenu actuel, en leur demandant de mettre à jour leurs liens vers votre nouveau site. Envisagez de prioriser vos efforts par le nombre de visites entrantes pour chaque lien.

Surveillez le trafic

Une fois que vous avez commencé le déplacement du site, surveillez comment le trafic des utilisateurs et des robots d’exploration change sur le nouveau site ainsi que sur l’ancien site. Idéalement, le trafic sur l’ancien site diminuera, tandis que sur le nouveau site, le trafic augmentera. Vous pouvez surveiller l’activité des utilisateurs et des robots d’exploration sur les sites avec Search Console et d’autres outils.

Utilisez Search Console pour surveiller le trafic

Sitemaps : Soumettez les deux sitemaps que vous avez enregistrés précédemment à partir du mappage. Initialement, le sitemap contenant les nouvelles URL aurait zéro page indexée, tandis que le sitemap des anciennes URL aurait de nombreuses pages indexées. Avec le temps, le nombre de pages indexées à partir du sitemap des anciennes URL tomberait à zéro avec une augmentation correspondante de l’indexation des nouvelles URL.

Rapport de couverture de l’index : Les graphiques refléteraient le déplacement du site, montrant une baisse du nombre d’URL indexées sur l’ancien site et une augmentation de l’indexation sur le nouveau site. Vérifiez régulièrement toute erreur d’exploration inattendue.

Requêtes de recherche : À mesure que davantage de pages du nouveau site sont indexées et commencent à se classer, les rapports de requêtes de recherche commenceraient à montrer les URL sur le nouveau site obtenant des impressions et des clics de recherche.

Utilisez d’autres outils pour surveiller le trafic

Gardez un œil sur vos journaux d’accès et d’erreur du serveur. En particulier, vérifiez l’exploration par Googlebot, toutes les URL qui renvoient de manière inattendue des codes d’état d’erreur HTTP, et le trafic utilisateur normal.

Si vous avez installé un logiciel d’analyse Web sur votre site, ou si votre CMS fournit des analyses, il est également recommandé de revoir le trafic de cette façon afin que vous puissiez voir la progression du trafic de votre ancien vers votre nouveau site. En particulier, Google Analytics offre des rapports en temps réel, et c’est une fonctionnalité pratique à utiliser pendant la phase initiale de déplacement du site. Vous devriez vous attendre à voir le trafic baisser sur l’ancien site et augmenter sur le nouveau site.

Dépannage de votre déplacement de site

Voici quelques erreurs courantes lors de la migration d’un site avec changement d’URL (y compris HTTP vers HTTPS). Ces erreurs peuvent empêcher votre nouveau site d’être indexé complètement.

Minimisez l’impact des tests A/B dans Google Search

Cette page couvre comment s’assurer que les tests de variations dans le contenu de la page ou les URL de la page ont un impact minimal sur vos performances Google Search. Elle ne donne pas d’instructions sur la façon de construire ou de concevoir des tests, mais vous pouvez trouver plus de ressources sur les tests à la fin de cette page.

Présentation des tests

Les tests de site Web consistent à essayer différentes versions de votre site Web (ou une partie de votre site Web) et à collecter des données sur la façon dont les utilisateurs réagissent à chaque version.

Les tests A/B consistent à tester deux (ou plusieurs) variations d’un changement. Par exemple, vous pouvez tester différentes polices sur un bouton pour voir si vous pouvez augmenter les clics sur le bouton.

Les tests multivariés consistent à tester plus d’un type de changement à la fois, en recherchant l’impact de chaque changement ainsi que les synergies potentielles entre les changements. Par exemple, vous pourriez essayer plusieurs polices pour un bouton, mais aussi essayer de changer (et de ne pas changer) la police du reste de la page en même temps. Une nouvelle police est-elle plus facile à lire et devrait-elle donc être utilisée partout ? Ou l’avantage est-il que la police du bouton semble différente du reste de la page, l’aidant à attirer l’attention ?

Vous pouvez utiliser un logiciel pour comparer le comportement avec différentes variations de vos pages (parties d’une page, pages entières ou flux multi-pages entiers), et suivre quelle version est la plus efficace avec vos utilisateurs.

Vous pouvez exécuter des tests en créant plusieurs versions d’une page, chacune avec sa propre URL. Lorsque les utilisateurs essaient d’accéder à l’URL d’origine, vous en redirigez certains vers chacune des URL de variation, puis vous comparez le comportement des utilisateurs pour voir quelle page est la plus efficace.

Vous pouvez également exécuter des tests sans changer l’URL en insérant des variations dynamiquement sur la page. Vous pouvez utiliser JavaScript pour décider quelle variation afficher.

Selon les types de contenu que vous testez, il peut même ne pas importer beaucoup si Google explore ou indexe certaines de vos variations de contenu pendant que vous testez. De petits changements, tels que la taille, la couleur ou le placement d’un bouton ou d’une image, ou le texte de votre « appel à l’action » (« Ajouter au panier » vs « Acheter maintenant ! »), peuvent avoir un impact surprenant sur les interactions des utilisateurs avec votre page, mais ont souvent peu ou pas d’impact sur l’extrait de résultat de recherche ou le classement de cette page.

De plus, si nous explorons votre site assez souvent pour détecter et indexer votre expérience, nous indexerons probablement les mises à jour éventuelles que vous apportez à votre site assez rapidement après avoir conclu l’expérience.

Meilleures pratiques lors des tests

Voici une liste des meilleures pratiques pour éviter tout effet néfaste sur votre comportement Google Search lors du test de variations de site :

Ne dissimulez pas vos pages de test

Ne montrez pas un ensemble d’URL à Googlebot, et un ensemble différent aux humains. C’est ce qu’on appelle le Cloaking , et c’est contraire à nos politiques de spam , que vous exécutiez un test ou non. N’oubliez pas que l’infraction à nos politiques de spam peut entraîner la rétrogradation ou la suppression de votre site des résultats de recherche Google—probablement pas le résultat souhaité de votre test.

Le cloaking compte que vous le fassiez par logique de serveur ou par robots.txt, ou toute autre méthode. Au lieu de cela, utilisez des liens ou des redirections comme décrit ensuite.

Si vous utilisez des cookies pour contrôler le test, gardez à l’esprit que Googlebot ne prend généralement pas en charge les cookies. Cela signifie qu’il ne verra que la version de contenu accessible aux utilisateurs avec des navigateurs qui n’acceptent pas les cookies.

Utilisez des liens rel=”canonical”

Si vous exécutez un test avec plusieurs URL, vous pouvez utiliser l’attribut de lien rel=”canonical” sur toutes vos URL alternatives pour indiquer que l’URL d’origine est la version préférée. Nous recommandons d’utiliser rel=”canonical” plutôt qu’une balise meta noindex car cela correspond plus étroitement à votre intention dans cette situation. Par exemple, si vous testez des variations de votre page d’accueil, vous ne voulez pas que les moteurs de recherche n’indexent pas votre page d’accueil ; vous voulez juste qu’ils comprennent que toutes les URL de test sont des doublons proches ou des variations sur l’URL d’origine et doivent être regroupées, avec l’URL d’origine comme canonique. L’utilisation de noindex plutôt que rel=”canonical” dans une telle situation peut parfois avoir des effets néfastes inattendus.

Utilisez des redirections 302, pas des redirections 301

Si vous exécutez un test qui redirige les utilisateurs de l’URL d’origine vers une URL de variation, utilisez une redirection 302 (temporaire) , pas une redirection 301 (permanente) . Cela indique aux moteurs de recherche que cette redirection est temporaire—elle ne sera en place que tant que vous exécutez l’expérience — et qu’ils doivent conserver l’URL d’origine dans leur index plutôt que de la remplacer par la cible de la redirection (la page de test). Les redirections basées sur JavaScript sont également acceptables.

Exécutez l’expérience uniquement aussi longtemps que nécessaire

La durée requise pour un test fiable variera en fonction de facteurs tels que vos taux de conversion, et le trafic que reçoit votre site Web ; un bon outil de test vous indique quand vous avez rassemblé suffisamment de données pour tirer une conclusion fiable. Une fois que vous avez conclu le test, mettez à jour votre site avec la ou les variations de contenu souhaitées et supprimez tous les éléments du test dès que possible, tels que les URL alternatives ou les scripts et balisages de test. Si nous découvrons un site exécutant une expérience pendant une durée inutilement longue, nous pouvons interpréter cela comme une tentative de tromper les moteurs de recherche et prendre des mesures en conséquence. C’est particulièrement vrai si vous servez une variante de contenu à un grand pourcentage de vos utilisateurs.

Plus d’informations sur les tests

Mettre temporairement en pause ou désactiver un site Web

Si vous êtes incapable de traiter les commandes ou si beaucoup de vos produits sont en rupture de stock, vous pourriez envisager de fermer temporairement votre entreprise en ligne. Si la situation est temporaire, ce qui signifie que vous prévoyez de pouvoir vendre des produits dans les semaines ou mois à venir, nous vous recommandons de prendre des mesures qui préservent autant que possible la position de votre site dans la recherche. Ce guide explique comment vous pouvez mettre en pause votre entreprise en ligne en toute sécurité.

Limitez les fonctionnalités de votre site (recommandé)

Si votre situation est temporaire et que vous prévoyez de rouvrir votre entreprise en ligne, nous vous recommandons de garder votre site en ligne et de limiter les fonctionnalités. C’est l’approche recommandée car elle minimise tout effet négatif sur la présence de votre site dans la recherche. Les gens peuvent toujours trouver vos produits, lire des avis ou ajouter des listes de souhaits afin de pouvoir acheter à un moment ultérieur. Nous vous recommandons de faire ce qui suit :

Désactivez la fonctionnalité de panier : Désactiver la fonctionnalité de panier est l’approche la plus simple, et ne change rien à la visibilité de votre site dans la recherche.

Affichez une bannière ou une fenêtre contextuelle : Une bannière ou un div contextuel sur toutes les pages, y compris la page de destination, rend rapidement le statut clair pour les utilisateurs. Mentionnez tout retard connu et inhabituel, les délais d’expédition, les options de retrait ou de livraison, afin que les utilisateurs continuent avec les bonnes attentes. Pour empêcher le contenu de la bannière ou de la fenêtre contextuelle d’être affiché dans un extrait dans les résultats de recherche, utilisez l’attribut HTML data-nosnippet . Assurez-vous de suivre nos directives sur les fenêtres contextuelles et les bannières .

Mettez à jour vos données structurées : Si votre site utilise des données structurées (par exemple, Produit , Livre , Événement ), assurez-vous de les ajuster de manière appropriée (reflétant la disponibilité actuelle du produit, ou changeant les événements en annulés). Si votre entreprise a une vitrine physique, mettez à jour les données structurées d’entreprise locale pour refléter les heures d’ouverture actuelles.

Vérifiez votre flux Merchant Center : Si vous utilisez Merchant Center, suivez les meilleures pratiques pour l’attribut de disponibilité .

Informez Google de vos mises à jour : Pour demander à Google de réexplorer un nombre limité de pages (par exemple, la page d’accueil), utilisez Search Console . Pour un plus grand nombre de pages (par exemple, toutes vos pages de produits), utilisez des sitemaps .

Non recommandé : Désactiver tout le site Web

Avertissement : Les systèmes de Google sont conçus pour être robustes et pour aider les sites Web à se remettre de problèmes temporaires. Cependant, supprimer complètement un site de l’index de Google est un changement significatif qui peut prendre un certain temps à récupérer. Il n’y a pas de temps fixe pour une récupération après une suppression complète, et il n’y a pas de mécanisme pour accélérer cela. C’est pourquoi nous recommandons fortement de limiter les fonctionnalités au lieu de supprimer le site de la recherche.

Vous pouvez décider de désactiver tout le site Web. C’est une mesure extrême qui ne devrait être prise que pour une très courte période de temps (quelques jours au maximum), car elle aura autrement des effets significatifs sur le site Web dans la recherche, même lorsqu’elle est implémentée correctement.

Vos clients ne sauront pas ce qui se passe avec votre entreprise s’ils ne peuvent pas trouver votre entreprise en ligne du tout.

Vos clients ne peuvent pas trouver ou lire des informations de première main sur votre entreprise et ses exemples, avis, spécifications, guides de réparation ou manuels ne seront pas trouvables. Les informations tierces peuvent ne pas être aussi correctes ou complètes que ce que vous pouvez fournir. Cela affecte souvent aussi les décisions d’achat futures.

La vérification Search Console échouera, et vous perdrez tout accès aux informations sur votre entreprise dans la recherche. Les rapports agrégés dans Search Console perdront des données à mesure que les pages seront supprimées de l’index.

La remontée en puissance après une période prolongée sera nettement plus difficile si votre site Web doit d’abord être réindexé. De plus, il est incertain combien de temps cela prendrait, et si le site apparaîtrait de la même manière dans la recherche par la suite.

Si vous décidez que vous devez faire cela (encore une fois, non recommandé ), voici quelques options :

Si vous devez désactiver le site de toute urgence pendant 1 à 2 jours, renvoyez alors une page d’erreur informative avec un code d’état de réponse HTTP 503 au lieu de tout le contenu. Assurez-vous de suivre les meilleures pratiques pour désactiver un site .

Si vous devez désactiver le site pendant une période plus longue, fournissez alors une page d’accueil indexable comme espace réservé pour que les utilisateurs puissent la trouver dans la recherche en utilisant le code d’état HTTP 200.

Si vous avez rapidement besoin de masquer votre site dans la recherche pendant que vous considérez les options, vous pouvez supprimer temporairement un site Web de la recherche .

Meilleures pratiques pour désactiver un site

Avertissement : Gardez à l’esprit qu’il n’est pas possible pour les systèmes de Google de rafraîchir les titres, descriptions, métadonnées ou données structurées inclus sur un site Web si une page renvoie un code d’état de réponse HTTP 503.

Bien que nous ne recommandions pas de désactiver votre site, voici quelques meilleures pratiques si vous décidez de le faire :

Continuez à autoriser l’exploration via le fichier robots.txt. Ne renvoyez pas de code d’état de réponse HTTP 503 pour le fichier robots.txt car cela bloque toute exploration .

Confirmez un code d’état de réponse HTTP 503 localement en utilisant curl ou un outil similaire. Par exemple :curl -I -X GET “https://www.example.com/” HTTP/1.1 503 Service Unavailable Mime-Version: 1.0 Content-Type: text/html (…)

Pour minimiser la charge côté serveur et côté client d’une page d’erreur 503, suivez ces meilleures pratiques : Utilisez l’en-tête HTTP retry-after avec une date ou une durée au mieux.

Donnez à vos utilisateurs des conseils clairs sur les étapes futures dans le contenu de la page d’erreur. Cela pourrait inclure : Des liens vers plus d’informations

La date à laquelle vous prévoyez que le site Web sera à nouveau en ligne, ou lorsque les informations seront mises à jour

N’interdisez pas toute exploration dans le fichier robots.txt. Renvoyer un fichier robots.txt valide qui interdit toute exploration peut supprimer le contenu du site Web, et potentiellement ses URL, de Google Search.

Ne bloquez pas le site Web en renvoyant des codes d’état HTTP 403 , 404 , 410 , ou avec une balise meta robots noindex ou un en-tête HTTP x-robots-tag. Cela supprimera les URL du site Web de Google Search.

N’utilisez pas l’outil de suppression temporaire de site Web dans Search Console pour les fermetures. Faire cela rendra impossible pour les utilisateurs de trouver votre site Web afin qu’ils puissent connaître son statut. De plus, les revendeurs ou affiliés potentiels des produits de votre entreprise pourraient continuer à être affichés dans la recherche.

FAQ

Et si je ne ferme le site que pendant quelques semaines ? Et si je veux exclure tous les produits non essentiels ? Puis-je demander à Google d’explorer moins pendant que mon site est temporairement fermé ? Comment puis-je faire indexer ou mettre à jour une page rapidement ? Et si je bloque une région spécifique d’accéder à mon site ?

Service associé: Agence marketing IA