web-dev-qa-db-ja.com

wwwからnon-wwwへのキャッシュ不可のCanonicalリダイレクト

この質問は永遠に議論の余地があり、この問題の本当の哲学を誰も知らないでしょう。しかし、標準のURLを非wwwからwwwに正しくリダイレ​​クトし、それを行うために、301および302応答ヘッダーに関する問題を解決しようとしていますSEO-efficient

現時点では、次の方法を使用して、正規URLを非wwwからwwwにリダイレクトしています

#RewriteCond %{HTTP_Host} !^(www\.shangri\.us)?$
#RewriteRule (.*) http://www.shangri.us/$1 [R=301,L]

しかし、このコードを使用すると、PageSpeedレポートに次のメッセージが表示されます。

サイトの訪問者のページ読み込み時間を短縮するには、できるだけ多くのランディングページリダイレクトを削除し、必要に応じて必要なリダイレクトをキャッシュ可能にします。

  • http://shangri.us/ is a non-cacheable redirect to http://www.shangri.us/

したがって、キャッシュ可能なリダイレクトに関するPageSpeedのアドバイスを修正しようとしています( http://goo.gl/AWI0g4

この場合、302応答ヘッダーを使用する必要があることを読みました。私は永続的なリダイレクトと一時的なリダイレクト(301/302)の違いを知っていますが、これを自分のサイトに実装する方法について大きなジレンマを抱えています。

ルートドメインをまったく使用したくありませんが、302時間リダイレクトを使用するのが怖いです。一部の人々は、SEOの問題には最適な方法ではないと言うからですaaaaaah私は非常識になります:(

4
Frondor

使用しているリダイレクトの種類は問題ではありません。 301リダイレクトはキャッシュ可能です。実際、これらは バストをキャッシュするのが非常に難しい です。 301は「永続的」を意味し、ブラウザは301リダイレクトをキャッシュする可能性が非常に高く、サーバーで既にキャッシュされているリダイレクトを元に戻す方法はありません。

302リダイレクトは通常、他のヘッダーがキャッシュ可能であることを示していない限り、デフォルトでnotキャッシュされません。

問題は、送信している他のHTTPヘッダーに関連している必要があります。 キャッシュヘッダーのガイド です。要約すると、リダイレクトをキャッシュ可能にするには、これらのヘッダーに注意する必要があります。

  • cache-control-「パブリック」または存在しない
  • expires-将来の日付、または301リダイレクトを使用する場合は存在しない日付
  • etag-存在しない
  • vary-存在しない
  • プラグマ-存在しない

ヘッダーを表示する場合は、コマンドラインツール curl を使用することをお勧めします。

curl --head http://shangri.us/

実際、cache-controlヘッダーをprivate:Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0に設定し、expiresヘッダーを過去の日付Expires: Thu, 01 Jan 1970 00:00:01 GMTに設定したことがわかります。そのリダイレクトのヘッダーを削除する必要があります。

3

リダイレクトの目的は何ですか?

301 Canonical

リダイレクトの目的は、正規のドメイン名を保証することです。そのため、適切なHTTP応答は301です。デフォルトでは、Cache-Controlヘッダーを指定しない限り、多くのブラウザーは これを無期限にキャッシュします になります。

302混乱

あなたが提供するGoogleのリファレンスでは、彼らはモバイルサイトに固有のランディングページについて話している。ここでは、Expiresヘッダーと302ヘッダーの両方でCache-Controlを使用することを推奨しています。また、Vary: User-Agentを追加して、ユーザーエージェントごとに異なるキャッシュを許可することをお勧めします。

その他のドキュメント では、301302の両方に言及しています。幸いなことに、 SEO Rountable はこれをクリアしました:

GoogleのMaile OhyeとMatt Cuttsに、これが本当に意図的なものであるかどうかを尋ねたところ、Maileは100%が意図的なものであり、間違いではないと述べました。マット・カッツ氏は、その理由は将来あなたがそれを変えたいかもしれないし、彼らがそれを永続的なものにしたくないからだと言った。

したがって、明らかに、モバイルリダイレクトに302を使用することの推奨事項は、ある程度のキャッシュを保持しながら将来の変更を許可することです。

多くのモバイルプロバイダーは、Webコンテンツに透過的なキャッシュプロキシを使用します。したがって、将来の変更を許可する場合、この戦略は理にかなっています。

これは、ポジティブなユーザーエクスペリエンスを提供するというGoogleの目標と一致しています。特に多くのサイトがレスポンシブデザインに切り替わり、すべてのコンテンツを提供するために単一のドメインを使用しているため、検索結果が無効なモバイル固有のドメインにリダイレクトされることを望んでいません。

PageSpeed

@Stephenが指摘しているように、301のデフォルトのキャッシュ期間をオーバーライドするキャッシュコントロールを送信しています。 CMSがこれらのヘッダーを送信している可能性が高いため、簡単に修正できない可能性があります。

正規のURLはwww.domain.comであるため、アクセスログに多くのリダイレクトが表示されない限り、これについてあまり心配する必要はありません。 PageSpeedのすべての推奨事項に過度に焦点を合わせないでください。それらをあなたのサイトのコンテキストに入れて、それに取り組むことの費用対効果を評価してください。

実際、PageSpeedの推奨事項によって、実際のサイトのパフォーマンスが低下したり、ユーザーエクスペリエンスが損なわれたりするのを見てきました。目標がSEOの場合、魅力的なサイトを持つことは、100ミリ秒高速になるサイトよりもはるかに重要です。

1
jeffatrackaid