Paramètres d'URL «inventés»
Cette question concerne la meilleure action à prendre lorsque Google indexe des pages qui n'existent pas vraiment.
J'ai un système de pagination assez simple sur un ensemble de pages de nouvelles où le fichier est référencé news.php?page=X.
Dans mon sitemap Google, je spécifie le nombre total de pages valides de ce type (jusqu'à news.php?page=13 actuellement).
La pagination à l'écran est une mise en page standard "1,2,3 ... Suivant/Précédent".
Cependant, Google Search Console révèle qu’il surveille 14 846 pages dans ce format. Par exemple, news.php?page=7556 et d'autres de ce type apparaissent dans les résultats de la recherche.
De la manière dont la pagination fonctionne, news.php?page=7556 affichera le même contenu que news.php?page=13. En d'autres termes, les plus anciennes quelques nouvelles. Inutile de dire qu’il n’ya pas de liens vers d’autres pages d’actualité que les pages 1-13.
Je ne sais pas avec certitude si cela a un impact négatif sur les recherches, mais je ne voudrais pas que le contenu légitime en pâtisse.
Ma question est donc la suivante: quel est le meilleur moyen d’empêcher Google d’indexer des milliers de non-pages? Devrais-je simplement créer une redirection 404 ou 301 pour toute page ne contenant pas de contenu légitime? Si une redirection 301, à quoi doit-elle être redirigée?
MISE À JOUR lundi 13 novembre:
Comme conseillé par Ilmari Karonen, j'ai ajouté rel = canonical dans les en-têtes de page, de sorte qu'une demande de news.php? Page = 7556 indique que l'URL canonique est news.php? Page = 13. Je n'ai pas ajouté les redirections 301 ou les redirections vers 404 pages d'erreur pour l'instant. Je surveillerai les résultats sur la console de recherche et ferai un rapport sur tout ce qui est utile.
S'il n'y a pas de contenu légitime sur ces URL, renvoyez simplement le statut 404. C'est pour ça.
Vous pouvez également vouloir inclure un rel = lien canonique dans la sortie HTML de votre script, pour vous assurer que toute autre manipulation d'URL inattendue (comme, par exemple, l'ajout de paramètres d'URL supplémentaires) n'introduira pas accidentellement du contenu en double. dans les index des moteurs de recherche.
Vous pouvez également éventuellement effectuer une redirection 301 vers l'URL canonique, si vous détectez que votre script a été accédé via une autre URL, mais cela ne présente aucun avantage réel en termes de référencement. Toutefois, si ( vous attendez que, pour une raison quelconque, vos utilisateurs risquent de se retrouver régulièrement sur la même page via plusieurs URL différentes, la configuration de redirections 301 peut Assurez-vous que vos utilisateurs utiliseront toujours ces URL canoniques dans les signets et les liens.
(Par exemple, Stack Exchange utilise les deux méthodes: l'URL pour votre question et les URL pour ma réponse sont différentes, mais il existe un lien rel = canonique à partir de cette dernière. Par contre, si SE détecte que le slug de l’URL ne correspond pas au titre de la question , il effectue une redirection 301).
Ps. D'après votre description, il semblerait que votre pagination soit configurée pour que chaque fois qu'un nouvel élément soit ajouté, il apparaisse en haut de la page 1 et le dernier élément de chaque page soit déplacé vers la page suivante. Le problème avec un tel schéma est que, pour maintenir leur index à jour, Google doit redéfinir toutes vos pages chaque fois qu'un nouvel élément est ajoutée. S'ils ne le font pas assez rapidement, il se peut que certains éléments ne figurent pas dans l'index de Google et que deux paraissent deux fois, ou que des résultats obsolètes de Google pointent vers des pages qui ne contiennent plus réellement l'élément recherché par l'utilisateur.
Tant que chacun de vos articles a sa propre URL canonique stable, la liste paginée servant uniquement de répertoire et de lien vers les URL d'articles stables, le problème n'est pas vraiment grave. (Par exemple, liste de questions de Stack Exchange fonctionne comme ça, et Google le fait très bien.) En fait, dans ce cas, vous pourriez même envisager d’ajouter un "noindex" méta-tag robots aux pages de la liste (ou au moins à toutes les pages sauf la première page) pour encourager Google à envoyer les visiteurs directement aux pages des articles.
Cependant, si vos nouvelles uniquement apparaissent sur les pages de liste numérotées, vous devriez vraiment envisager de redéfinir votre site afin que chaque article ait une seule URL stable. . Il sera donc beaucoup plus probable que Google indexera correctement vos articles d'actualité et que les visiteurs accédant à votre site à partir des résultats de Google trouveront ce qu'ils recherchent.
Vous devez exécuter un type de script qui génère des données en fonction du numéro de page qui lui est attribué. La triste vérité est que celui qui a conçu le script n'a pas pris les erreurs en considération.
Le script doit être modifié de sorte que, si le nombre de pages spécifié dépasse le nombre total de pages que vous avez effectuées pour votre site (13?), La sortie doit idéalement être une erreur HTTP 404 indiquant qu'une page n'a pas été trouvée, mais depuis Google essayé d’indexer de telles pages fictives, le code d’erreur HTTP doit être remplacé par l’erreur 410 pour indiquer à Google que la page n’est pas trouvée et pour arrêter la recherche de cette page spécifique.
Si vous avez une expérience de base en programmation, vous pourrez alors résoudre ce problème vous-même. Sinon, vous devrez contacter les développeurs du script que vous utilisez pour résoudre leur problème et obtenir un nouveau script qui remplacera celui que vous avez et qui fonctionnera correctement avec la tâche de votre site Web.
Je ne recommanderais pas une redirection (301 ou 302) pour les pages fictives, car aucune valeur n'est proposée et cela ralentit également le serveur du fait que les robots de recherche numérisent les numéros de page fictifs ainsi que les nouvelles URL vers lesquelles ils sont redirigés. Toutefois, si vous pensez qu'un invité peut essayer d'accéder à un numéro fictif, vous pouvez inclure un lien vers une page valide sur la page d'erreur.