関数

redirect_guess_404_permalink() の解説：WordPressで404エラー時に正しいURLを推測する仕組み

2025-02-19更新日: 2025-02-19

redirect_guess_404_permalink() は、WordPressで404エラーが発生した際にリクエストURLから正しい投稿やページのURLを推測し、ユーザーを適切なコンテンツへ誘導する仕組みです。

クエリ変数(スラッグ、日付、投稿タイプなど)を元に候補を探索し、redirect_canonical() と連携してSEO対策にも効果を発揮します。

目次から探す

404エラー時のリダイレクト処理の動作
- redirect_canonical() との連携
- URL正規化とリダイレクトの切り替え
リダイレクト先推測のプロセス
フィルターを用いたカスタマイズ
セキュリティ対策と動作検証
- エスケープ処理と $wpdb->prepare() の利用
- 開発環境での検証手法
まとめ

404エラー時のリダイレクト処理の動作

404エラーが発生した場合、WordPressはユーザーを正しいページへ誘導するためのリダイレクト処理を開始します。

この仕組みは、存在する可能性のある投稿や固定ページをデータベースから検索し、リダイレクト先を推測する形で動作します。

以下では、404エラー時のリダイレクト処理の動作と、WordPress内の他のリダイレクト機構との関係について説明します。

redirect_canonical() との連携

WordPressでは、redirect_canonical()関数がリクエストされたURLを正規化する役割を担っています。

通常のアクセス時には、パーマリンク構造に沿った形にURLを統一する処理を行います。

しかし、404エラーが発生した際は、正規のURLが見つからないため、redirect_guess_404_permalink() が呼び出され、存在する可能性のあるコンテンツへの誘導を試みます。

例えば、ユーザーが入力ミスをしてしまったURLの場合でも、投稿のスラッグや公開日の情報をもとに正しいURLを推測し、redirect_canonical() を補完する形でリダイレクトが実現されます。

これにより、ユーザーは不必要なエラーページに留まることなく、目的のコンテンツにアクセスできる可能性が高まります。

URL正規化とリダイレクトの切り替え

404エラー発生時のリダイレクトでは、URLの正規化とリダイレクト先の決定が連携して動作します。

まず、リクエストされたURLが正規化処理を経て、標準のURL形式に変換されます。

その後、リダイレクト処理が実行され、推測された正しいURLに誘導される仕組みです。

この処理では、クエリ変数などから得られる情報に基づき、正確なURLが特定されます。

URLの正規形にすることで、検索エンジンへの評価基準も統一され、SEO最適化に役立つ効果が期待できる仕組みとなっています。

リダイレクト先推測のプロセス

リダイレクト処理では、404エラー時にユーザーがアクセスすべき正しいページを特定するため、段階的なプロセスが組み込まれています。

各段階でクエリ変数やSQLクエリを利用し、条件に合致するコンテンツを絞り込む工夫がされています。

クエリ変数による候補抽出

404エラー時に、リクエストURLに含まれるクエリ変数を元に、リダイレクト候補が抽出されます。

これにより、部分的に正しい情報が含まれている場合でも、候補の絞り込みが可能となります。

name パラメータの役割と重要性

name パラメータは投稿のスラッグとして利用され、リダイレクト候補の中でも最も基本的な検索キーとなります。

例えば、ユーザーが間違ったURLを入力しても、name パラメータが正しければ、正しい投稿を特定する助けとなります。

以下は、name パラメータを利用した候補抽出のサンプルコードです。

// クエリ変数 'name' を取得
$post_name = get_query_var( 'name' );
// クエリ変数を元に、部分一致検索用の条件を生成
$where = $wpdb->prepare( 'post_name LIKE %s', $wpdb->esc_like( $post_name ) . '%' );
// データベースから該当する投稿IDを取得
$query = "SELECT ID FROM $wpdb->posts WHERE $where AND post_status IN ('publish','inherit')";
$post_id = $wpdb->get_var( $query );

// $post_id には、条件に合致する投稿のIDが格納される

投稿タイプ・日付による絞り込み処理

さらに、404エラー時には post_type や year、monthnum、day といったクエリ変数を組み合わせ、投稿候補をより正確に絞り込みます。

たとえば、同じ name を持つ複数の投稿が存在する場合、投稿タイプや公開日情報を利用することで、正確な候補を特定しやすくなります。

SQLクエリによる投稿検索

抽出されたクエリ変数をもとに、実際の投稿が存在するかどうかをSQLクエリで確認します。

ここでは、ユーザーが入力した情報に応じて厳密検索やあいまい検索が切り替えられる仕組みになっています。

厳密検索とあいまい検索の選択基準

厳密検索モードでは、post_name が入力と完全一致する投稿のみを対象とします。

一方、あいまい検索モードでは、入力に近い候補を抽出するために LIKE 条件が利用されます。

具体的な挙動は、以下のようなコードで実装されることが多いです。

if ( $strict_mode ) {
    // 厳密検索：完全一致の投稿を検索
    $where = $wpdb->prepare( 'post_name = %s', $name );
} else {
    // あいまい検索：先頭一致で検索
    $where = $wpdb->prepare( 'post_name LIKE %s', $wpdb->esc_like( $name ) . '%' );
}

// $where 変数に条件が適切に設定される

これにより、ユーザーの入力ミスや部分一致に柔軟に対応できる設計になっています。

効率的なクエリ最適化の工夫

パフォーマンスを確保するため、SQLクエリは必要最小限のデータ取得に絞られています。

たとえば、$wpdb->get_var() を用いることで単一の値のみを取得し、オーバーヘッドを低減します。

また、適切なエスケープ処理やインデックスの活用により、効率的なクエリ実行が実現されています。

リダイレクト先の決定処理

SQLクエリで候補となる投稿が特定された後、最終的なリダイレクト先が決定されます。

この決定処理では、リクエストに合わせた詳細な条件が考慮されます。

フィード対応とページ分割の調整

リダイレクト先が投稿である場合、feed や page といったクエリ変数によって、投稿のコメントフィードやページ分割が適用される場合があります。

たとえば、feed パラメータが含まれている場合、コメントフィードのURLを生成して返す処理が行われます。

また、ページ分割が必要な場合は、正しいページ番号を付加してリダイレクトされます。

以下は、フィード対応とページ分割の処理例です。

if ( get_query_var( 'feed' ) ) {
    // コメントフィードURLを返す
    $redirect = get_post_comments_feed_link( $post_id, get_query_var( 'feed' ) );
} elseif ( get_query_var( 'page' ) > 1 ) {
    // ページ分割された場合のURL生成
    $redirect = trailingslashit( get_permalink( $post_id ) ) . user_trailingslashit( get_query_var( 'page' ), 'single_paged' );
} else {
    // 通常の投稿URLを返す
    $redirect = get_permalink( $post_id );
}

// $redirect には、リダイレクト先の正しいURLが設定される

フィルターを用いたカスタマイズ

WordPressでは、404エラー時のリダイレクト処理に対してフィルターを適用することで、挙動の変更やカスタマイズが可能です。

目的に合わせてリダイレクト処理を柔軟に制御できるため、特定の条件下での処理を独自に上書きすることができます。

do_redirect_guess_404_permalink の挙動

do_redirect_guess_404_permalink フィルターは、リダイレクトURLの推測処理を有効にするかどうかの判定で利用されます。

このフィルターで false を返すと、通常のリダイレクト処理が無効化され、手動でのリダイレクト設定など、別の処理に切り替えることが可能です。

以下は、リダイレクト処理を無効化するサンプルコードです。

// do_redirect_guess_404_permalink フィルターにて処理を無効化する例
add_filter( 'do_redirect_guess_404_permalink', '__return_false' );

// この設定により、404時のリダイレクト候補推測が行われなくなる

pre_redirect_guess_404_permalink による短絡処理

pre_redirect_guess_404_permalink フィルターは、リダイレクト処理を途中で短絡し、独自のURLを返すために利用されます。

条件に合致した場合、通常の処理をバイパスして、カスタムなリダイレクト先URLを指定できるため、柔軟なカスタマイズが実現可能です。

以下は、特定の条件下で独自のURLに短絡する例です。

// pre_redirect_guess_404_permalink フィルターでカスタムリダイレクトURLを設定する例
add_filter( 'pre_redirect_guess_404_permalink', function( $pre ) {
    if ( is_404() && some_custom_condition() ) {
        // 条件を満たす場合、カスタムURLに切り替え
        return 'https://example.com/custom-redirect/';
    }
    return $pre;
} );

// 条件が成立した場合、404エラー時に 'https://example.com/custom-redirect/' にリダイレクトされる

strict_redirect_guess_404_permalink での一致判定

strict_redirect_guess_404_permalink フィルターは、入力された name パラメータに対し、厳密な一致を求めるかどうかの判定を行います。

このフィルターを有効にすることで、部分一致ではなく完全一致した投稿のみをリダイレクト対象とし、誤ったリダイレクトを防ぐ仕組みが強化されます。

以下に、厳密検索モードを有効にする例を示します。

// strict_redirect_guess_404_permalink フィルターを有効にして、厳密一致を求める設定にする例
add_filter( 'strict_redirect_guess_404_permalink', '__return_true' );

// この設定で、リダイレクト処理は 'name' パラメータの完全一致のみを対象とする

セキュリティ対策と動作検証

404エラー時のリダイレクト処理においても、セキュリティ対策と動作検証は重要なポイントとなります。

特に、SQLクエリを利用する際には、動的な入力値に対して適切なエスケープ処理が必要です。

エスケープ処理と $wpdb->prepare() の利用

データベースに直接アクセスし、投稿の検索を行う場合、SQLインジェクションなどのリスクを回避するために、$wpdb->prepare() と $wpdb->esc_like() を用いて安全にクエリを構築することが推奨されています。

以下のサンプルコードは、安全にクエリを実行する例です。

// 404エラー時のリダイレクト候補を抽出する際の安全なSQLクエリ例
$post_name = get_query_var( 'name' );
$where = $wpdb->prepare( 'post_name LIKE %s', $wpdb->esc_like( $post_name ) . '%' );
$query = "SELECT ID FROM $wpdb->posts WHERE $where AND post_status IN ('publish','inherit')";
$post_id = $wpdb->get_var( $query );

// $post_id には、安全に取得された投稿IDが格納される

このように、入力値をエスケープしてから利用することで、SQLインジェクションリスクを低減し、安全なリダイレクト処理を実現しています。

開発環境での検証手法

リダイレクト処理の動作確認や不具合の検証には、ローカル開発環境やステージング環境でのテストが重要です。

デバッグツールやログ出力を利用することで、404エラー発生時にどのようなURLが推測され、リダイレクトが実行されるかを詳細に確認することができます。

以下は、開発環境での検証コードの例です。

// 404エラー時のリダイレクトURLをエラーログに出力するデバッグコード例
add_action( 'template_redirect', function() {
    if ( is_404() ) {
        $redirect_url = redirect_guess_404_permalink();
        error_log( '推測されたリダイレクトURL: ' . var_export( $redirect_url, true ) );
    }
} );

// エラーログに '推測されたリダイレクトURL: https://example.com/sample-post/' のような情報が出力される

このような検証手法を用いることで、実際のリダイレクト挙動を確認しながら、必要な調整や改善を行うことが可能です。

まとめ

この記事では、404エラー発生時に正しいコンテンツへリダイレクトする仕組みについて説明しています。

リダイレクト候補の抽出には、name パラメータやその他のクエリ変数を活用し、SQLによる厳密・あいまい検索で投稿を特定します。

さらに、redirect_canonical() との連携、フィルターによるカスタマイズ、セキュリティ対策および開発環境での検証手法を具体例とともに解説しています。