redirection Canonical non cacheable de www à non-www
Je sais que cette question est discutable pour toute l'éternité, et très probablement personne ne connaît la véritable philosophie de ce problème. Mais j'essaie de résoudre le problème des en-têtes de réponse 301 et 302 afin de rediriger correctement une URL canonique de non-www vers www et de le faire et optimisé pour les moteurs de recherche .
Pour le moment, j'utilise la méthode suivante pour rediriger mon URL canonique de non-www vers www
#RewriteCond %{HTTP_Host} !^(www\.shangri\.us)?$
#RewriteRule (.*) http://www.shangri.us/$1 [R=301,L]
Mais en utilisant ce code, je reçois le message suivant dans mon rapport PageSpeed:
Pour accélérer les temps de chargement des pages pour les visiteurs de votre site, supprimez autant de redirections de page de destination que possible et mettez en cache les redirections requises, si possible.
http://shangri.us/ is a non-cacheable redirect to http://www.shangri.us/
J'essaie donc de corriger le conseil de PageSpeed concernant les redirections pouvant être mises en cache ( http://goo.gl/AWI0g4 )
J'ai lu que je devais utiliser l'en-tête de réponse 302 dans ce cas. Je connais la différence entre les redirections permanentes et temporelles (301/302), mais j'ai un gros dilemme quant à la façon de la mettre en œuvre sur mon site.
Bien que je ne veuille pas du tout utiliser mon domaine racine, j'ai peur d'utiliser une redirection temporelle 302, car certaines personnes disent que ce n'est pas la meilleure solution pour le référencement . , mais ... aaaaaah je vais devenir fou :(
Le type de redirection que vous utilisez n’est pas le problème. 301 redirections peuvent être mises en mémoire cache. En fait, ils sont extrêmement difficile à mettre en cache . 301 signifie "permanent" et les navigateurs sont très susceptibles de mettre en cache les redirections 301 sans que le serveur puisse annuler une redirection déjà mise en cache.
Les redirections 302 sont généralement not mises en cache par défaut, sauf si d'autres en-têtes indiquent qu'ils peuvent être mis en cache.
Le problème doit être lié aux autres en-têtes HTTP que vous envoyez. Voici guide pour les en-têtes de cache . En résumé, vous devriez prêter attention à ces en-têtes pour rendre les redirections en cache:
- cache-control - "public" ou non présent
- expire - Date future ou non présente lors de l'utilisation de redirections 301
- etag - Non présent
- varie - Non présent
- pragma - Pas présent
Si vous voulez voir vos en-têtes, je vous suggère d'utiliser l'outil de ligne de commande curl :
curl --head http://shangri.us/
En effet, je vois que vous avez défini l'en-tête de contrôle du cache sur private: Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0 et l'en-tête Expires à une date antérieure: Expires: Thu, 01 Jan 1970 00:00:01 GMT. Vous devez supprimer ces en-têtes pour cette redirection.
Quel est le but de la redirection?
Le 301 Canonical
Le but de votre redirection est d’assurer un nom de domaine canonique. En tant que tel, la réponse HTTP appropriée est un 301. Par défaut, de nombreux navigateurs vont mettre cela en cache indéfiniment sauf si vous spécifiez un en-tête Cache-Control.
Le 302 Confusion
Dans la référence Google que vous fournissez, il est question de pages de destination spécifiques aux sites pour mobiles. Ici, ils encouragent l'utilisation d'un 302 avec les deux en-têtes Expires et Cache-Control. Ils recommandent également d'ajouter Vary: User-Agent pour autoriser différents caches pour différents agents utilisateurs.
Dans autres documents , ils mentionnent à la fois 301 et 302. Heureusement, SEO Rountable éclairci ceci:
J'ai demandé à Maile Ohye et à Matt Cutts de Google si cela était fait exprès et Maile a répondu que c'était à 100% exprès et non une erreur. Matt Cutts a expliqué que la raison en était que vous souhaitiez peut-être le changer à l'avenir et qu'ils ne voulaient pas que ce soit permanent.
Donc, apparemment, la recommandation d'utiliser 302 pour les redirections mobiles est de permettre les modifications futures tout en conservant un certain niveau de mise en cache.
De nombreux fournisseurs de services mobiles utilisent des proxys de mise en cache transparents pour le contenu Web. Cette stratégie est donc logique si vous souhaitez autoriser des modifications futures.
Ceci est conforme à l'objectif de Google d'offrir une expérience utilisateur positive. Ils ne veulent pas que les résultats de recherche soient redirigés vers des domaines spécifiques de téléphones mobiles obsolètes, en particulier du fait que de nombreux sites basculent vers une conception réactive et utilisent un seul domaine pour servir tout le contenu.
PageSpeed
Comme @Stephen le fait remarquer, vous envoyez des contrôles de cache qui remplacent les périodes de cache par défaut pour un 301. Il est probable que votre CMS envoie ces en-têtes et ce n’est peut-être pas une solution facile, car.
Étant donné que votre URL canonique est www.domain.com, je ne suis pas sûre de trop m'en inquiéter à moins que vous ne voyiez beaucoup de redirections dans vos journaux d'accès. Ne vous concentrez pas trop sur chaque recommandation de PageSpeed. Placez-les dans le contexte de votre site et évaluez les coûts-avantages liés à la résolution du problème.
En fait, j'ai constaté que certaines recommandations de PageSpeed nuisaient aux performances des sites réels ou à l'expérience utilisateur. Si votre objectif est le référencement, il est bien plus important d’avoir un site attrayant qu’un site 100 ms plus rapide.