web-dev-qa-db-ja.com

実際にリクエストをコントローラに書き換えてからコンテンツを動的にページに出力しているときに、SEOが200ステータスを送信しても大丈夫ですか?

リダイレクトとベストプラクティスに関する無限のページを読んだ後、ここでやっていることが良いか、悪いか、SEOに関しては無関心かどうかはまだわかりません。

さまざまなURLを保持するデータベースにテーブルがあります-ページが移動した場所に直接リダイレクトされるものもあれば、使いやすいURLを変換するものもあります。

私のセットアップのロジック:

  • ファイルまたはディレクトリが存在しない場合は、controller.phpにリクエストを送信します
  • コントローラーは、要求URLがデータベースに存在するかどうかを確認します
  • 存在し、ユーザーフレンドリーなURLである場合、200ヘッダーを送信し、ページコンテンツを出力します(アドレスバーのユーザーフレンドリーなURLを変更せずに)
  • 単純なリダイレクトの場合、301リダイレクトヘッダーを新しいURLに送信します(ユーザーフレンドリーなURLになり、このプロセスを再度実行します)
  • データベースで見つからない場合は、404ヘッダーを送信し、404ページのコンテンツを出力します。

私の.htaccessは次のとおりです。

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule !^\/controller\.php$ /controller.php [L,NC]

私のcontroller.phpは次のとおりです。

$originalURI = $_SERVER['REQUEST_URI'];

$controller = new Controller($originalURI);

if($controller->GetRedirectAddress())
{
    // will output either 200 or 301 status code depending on type of link
    header($_SERVER["SERVER_PROTOCOL"] . " " . $controller->httpStatusText, true, $controller->httpStatusCode);
    echo $controller->OutputRequestToPage();
}
else
{
    header($_SERVER["SERVER_PROTOCOL"] . " 404 Page not found ({$originalURI})", true, 404);
    echo $controller->Output404Page();
}

更新中のサイトには多くのトラフィックがあり、最後にしたいことはページのランキングにマイナスの影響があるため、ここでのアドバイスは大歓迎です。

コメントでさらに情報が必要な場合はお知らせください。必要に応じて更新します。

2
Sam

...その後、200ヘッダーを送信し、ページコンテンツを出力します(アドレスバーのURLを変更せずに)

あなたがしていることは完璧に聞こえます。有効な応答を送信する場合、200 OKステータスが正しいことです。このインスタンスのサーバーからの応答は1つだけなので、ここに戻ることができる他のコードは何だと思いますか?

要求を実際にコントローラーにリダイレクトし、コンテンツを動的にページに出力するときに200ステータスを送信しても大丈夫ですか?

ここで実際に何が起こっているかについて少し混乱するかもしれません。 内部書き換えは実際には何ですか?プロセスを完全に説明しているように見えますが、問題ありません。 (ペニーがコメントで落ちたのかもしれない?)

  1. ユーザーは、ユーザーフレンドリーなURLの1つにリクエストを行います(厳密には、SEOフレンドリーなURLではなくserフレンドリーです。検索エンジンはそれほど気にしません。「SEO」ちょっとした包括的な用語です。) example.com/friendly-url

  2. このURLはファイルまたはディレクトリに直接マッピングされないため、リクエストは内部的に書き換えられます to /controller.php.htaccessコードで処理)になります。このデザインパターンは「フロントコントローラー」と呼ばれます。これは完全にサーバーの内部です。ユーザー(または検索エンジンボット)は、実際に何が行われているかを完全に認識していません。ページの生成に伴う複雑さは見えないように隠されています。

  3. 「コントローラー」は、これが有効なリクエストであると判断し、ページを構築して、200 OKステータスでクライアントに送り返します。これで完了です。 client/user/searchボットに関する限り、静的なHTMLページである可能性があります。 (実際、何らかの種類のサーバー側キャッシュからそのままプルした場合は、そうだったかもしれません。)

RewriteRule !^\/controller\.php$ /controller.php [L,NC]

ただし、RewriteRuleディレクティブにはいくつかの小さな問題があります。

  1. ディレクトリごとの/ .htaccessコンテキストでは、RewriteRuleパターン(つまり、!^\/controller\.php$)は常に成功します。 URLパスは/controller.phpと一致しません。URLパスが一致する前にディレクトリプレフィックスが最初に削除されるため、URLパスがスラッシュで始まることはありません。したがって、これは!^controller\.php$である必要があります。ただし、URLが変更されずにパススルーしたため、rewrite-loopはまだ防止されていました(少し後に停止します)。 (スラッシュ区切り記号がないため、正規表現でスラッシュをエスケープする必要もありません。)

  2. NCフラグを削除する必要があります。これにより、大文字と小文字を区別しない一致が可能になります。ただし、これは否定パターンに適用されます。 「controller.php」ではなく(正確に)、「CONTROLLER.PHP」や「CoNtRoLlEr.pHp」などではない場合に書き換えたいと考えます。問題を引き起こす可能性は低いですが、NCただの仕事です。

だから、私たちは...

RewriteRule !^controller\.php$ /controller.php [L]
1
MrWhite