Comment supprimer une URL de fragment / hash des résultats de recherche Google?
Mon ancien site écrivait les URL sans !.
Par exemple: www.example.com/#/products
Mais cela fait plus de 6 mois que je l’ai modifiée pour inclure ! dans l’URL de la manière suivante:
www.example.com/#!/products
Mais malheureusement, les résultats de recherche Google affichent toujours mon ancien schéma d'URL.
Il m'est impossible d'entrer dans l'outil de suppression de Google (via leurs outils pour les webmasters) afin de supprimer www.example.com/#/products, car Google se plaindre d'une URL non valide.
Tout ce que je veux, c'est supprimer www.example.com/#/products et permettre à Google d'afficher celui avec /#!/products dans les résultats.
Tout d'abord, vous n'avez pas à vous soucier de supprimer les anciennes URL avec le hachage. Si votre contenu est analysé et indexé correctement sous la nouvelle URL hash-bang, il sera bientôt remplacé.
Il n’est pas tout à fait clair quel est le problème sans résoudre le problème avec le site actif, mais espérons que ces étapes vous aideront à découvrir une solution.
Vous voudrez commencer par éliminer les problèmes courants.
Vérifiez si Googlebot accède à vos instantanés HTML
L’idée même de l’exploration AJAX est d’obtenir l’indexation des images, descriptions et spécifications de vos produits. Je suppose que vous avez suivi les instructions appropriées de spécifications de Google AJAX relatives à la capacité d’exploration , afin de vous assurer que Googlebot est en mesure de voir vos instantanés HTML. Si Google ne voit pas les instantanés HTML corrects, c'est probablement la raison pour laquelle Google n'a pas mis à jour son index afin de refléter les nouvelles URL hashbang que vous avez créées.
À l'aide de Google Webmaster Tools (GWT), accédez à la section "Explorer" Récupérer en tant que Google ". Ensuite, demandez à Goolgebot de récupérer et de restituer l’URL _escaped_fragment_ complète => www.example.com/?_escaped_fragment_=products. Si tout va bien, vous devriez voir le statut "Complet". Vous devriez également pouvoir cliquer sur le statut pour voir l'instantané HTML du produit en question.
Si vous voyez un "Non trouvé" pour le statut ou "Bloqué", c'est probablement la raison pour laquelle Google n'a pas mis à jour les URL de l'index.
Si c'est "bloqué" , cela signifie que votre fichier robots.txt contient une règle qui empêche Googlebot d'accéder à l'instantané HTML.
Si c'est "Introuvable" , cela signifie que vous n'avez probablement pas configuré nginx pour les demandes de routage appropriées avec? _Escaped_fragment_ = vers le rendu du code HTML côté serveur. instantané.
Si vous voyez un "partiel" , vous devez cliquer sur le statut et voir les différentes ressources bloquées par Googlebot. Mais fondamentalement, si vous ne voyez pas le contenu approprié dans la vignette du rendu de Google de la page, il est probable que vous bloquez une ressource dont Google a besoin pour restituer le contenu.
Vérifie si Angular rend les URL HashBang dans les HREF
Si la vignette rendue de la page est correcte, nous avons constaté que Googlebot pouvait afficher le code HTML restitué côté serveur et que le routage était correct pour les requêtes _escaped_fragment_. Ceci pointe alors au début car Googlebot ne semble pas être découverte les nouvelles URL de hashbang.
Une vérification rapide de vos journaux d’accès devrait vous aider à confirmer ce problème. Si vous avez Splunk, LogStash ou un bon vieux logiciel à portée de main, vous devrez rechercher les demandes qui répondent aux critères suivants:
- l'agent utilisateur contient "googlebot"
- l'URL de la requête contient "? _escaped_fragment_ = products"
- demander une adresse IP commence par "66.249"
En gros, vous voulez rechercher tout requêtes Googlebot vérifiées . Googlebot vient principalement de 66.249.*.* ces jours-ci.
Si vous ne voyez pas beaucoup de demandes comparées au nombre de pages explorées par jour répertoriées sous "Analyse" Statistiques d'exploration dans GWT, il est probable que Googlebot ne puisse pas voir les URL de hashbang dans les attributs href des balises d'ancrage. .
Si vous accédez à www.example.com/#!/products et Inspect Element dans Chrome ou Firefox, vous voudrez vous assurer que le code HTML rendu contient des balises d'ancrage claires avec des hrefs incluant les versions hashbang. des URL. Si ce n'est pas le cas, vous devrez reconfigurer Angular pour le faire.
Si vous les voyez là-bas, vous voudrez alors extraire et rendre www.example.com/#!/products ou une autre page telle que votre page d'accueil qui aurait des balises d'ancrage avec des attributs href liant des URL hashbang.
Lorsque vous cliquez sur le statut pour afficher la version "rendue" de la page, vous pouvez cliquer sur l'onglet "Récupération" qui se trouve à côté de l'onglet "Rendu" par défaut, pour afficher les en-têtes de réponse HTTP et le code HTML résultant.
Si vous ne trouvez pas les références hashbang dans les emplacements appropriés de l'onglet "Récupération", vous devrez parcourir votre pile Angular pour voir où la déconnexion se produit. Vous effectuez probablement une redirection javascript dans un fichier d'actif bloqué par Googlebot, et les références mises à jour ne sont probablement pas affichées.
Quand tout le reste échoue
Si ce n'est pas ce qui est mentionné ci-dessus, alors c'est probablement un bug avec Google lui-même. Cela se produit de temps en temps, et bien que les Googlers soient des gens intelligents, ils se trompent parfois.
Vous aurez envie de sauter dans Google Webmaster Forums: exploration, index et classement , et espérons que l'un des nombreux Googlers qui fréquentent les forums enquêtera pour vous.
Une solution alternative
Donc, après tout ce qui a été dit et fait, je recommande fortement de ne pas utiliser le standard _escaped_fragment_. Bien que Google l'ait publié et que Bing l'ait adopté, les sites sont rarement implémentés correctement et les URL hashbang apparaissent rarement dans les premiers résultats de recherche pour les pages indexées.
Ma suggestion, si vous avez le temps et les ressources en ingénierie nécessaires, consiste à utiliser pushState (). Avec pushState, vous devez ajouter plus de logique à vos itinéraires pour traiter les demandes côté client et côté serveur, mais vous pouvez ensuite tirer parti de l'utilisation de balises canoniques sans avoir à vous soucier de la surcharge? _Escaped_fragment_.
Je sais que Angular + pushState n'est pas la chose la mieux documentée, mais il y a de bonnes publications qui dépendent du reste de votre pile.
Enfin, je ne veux pas être trop auto-promotionnel, mais comme ces choses-là, la conversation mène finalement à un rendu "pré-rendu" ou "côté serveur". J'ai fait une conversation à SMX Advanced couvrant certains problèmes courants AJAX de l'exploitabilité. Si vous passez à la diapositive 34, vous pourrez voir certains des avantages et des inconvénients. Les diapositives 49 et 50 contiennent également des références à quelques autres bons Angular + posts.
Cela fait longtemps que je ne suis pas dans les outils de Google Webmaster, mais je me souviens qu'il existe un outil permettant de supprimer les pages indexées de tout site Web.
** Pour ce faire, vous devrez associer le site Web au compte d'outil du webmaster en question ...
https://www.google.com/webmasters/tools/dashboard
se connecter ou créer un nouveau compte (lier le site comme mentionné ci-dessus)
cliquez sur google index & selectionnez remove urls
sur la page d'ouverture, insérez toutes les URL à supprimer ..... **
Si vous avez modifié vos URL, vous devez rediriger les anciennes URL vers des nouvelles. Dès lors, Google mettra automatiquement à jour son statut d'indexation dans un mois environ, en fonction de la vitesse d'exploration de votre site Web.
Voici un guide complet sur la redirection 301