カテゴリベースなしWPML完全ガイド：クリーンな多言語URLを実現

はじめに：「カテゴリーベースなしWPML」とはどういう意味か

「カテゴリベースなし WPML」とは、WordPress のデフォルトのカテゴリ接頭辞を削除しつつ、すべての WPML 言語でカテゴリ アーカイブ URL を正しく維持することを意味します。英語のアーカイブの代わりに、example.com/category/news/使用することもできますexample.com/news/スペイン語版はexample.com/es/noticias/それよりもexample.com/es/category/noticias/。

結果は単純に見えるが、その設定は必ずしも単純ではない。

WordPressはリライトルールを使用して、読みやすいURLを分類クエリにマッピングします。WPMLは、言語ディレクトリ、ドメイン、またはURLパラメータのためのレイヤーを追加します。また、翻訳されたカテゴリ用語とスラッグも接続します。最終的なルートについては、ベース削除方法、パーマリンク設定、テーマ、SEOプラグイン、キャッシュ、およびサーバールールが一致している必要があります。

重要：WPMLは多言語コンテンツと分類データを翻訳しますが、それ自体は汎用的なカテゴリベース削除スイッチではありません。ベースを削除するには、メンテナンスが行き届いた互換性のあるWordPressの方法を使用し、その後WPMLでテストしてください。

QueueLingoは、チームがWPMLの翻訳ジョブをホスト型キューと接続された翻訳エンジンを通して処理できるように支援し、カテゴリ名、関連コンテンツ、多言語更新をより大規模に管理できるようにします。

無料のQueueLingoアカウントを作成しましょうまたはデモを見るサイト全体の多言語展開を計画する前に。

多言語SEOにおいてカテゴリベースが重要な理由

標準的なWordPressのカテゴリアーカイブでは、多くの場合、次のようなパターンが用いられます。

• https://example.com/category/news/
• https://example.com/category/tutorials/

その言葉categoryはカテゴリのベースです。サイトはこれを別のベースに置き換えることができます。topicsただし、カテゴリベースフィールドを空のままにしておくと設定 → パーマリンク通常とは、WordPressがデフォルトの動作を使用することを意味します。ベースを完全に削除するには、通常、互換性のあるプラグイン、テーマ機能、または慎重に管理されたカスタム書き換えロジックが必要です。

多言語環境では、URLに言語シグナルを含めることもできます。

• ディレクトリ：example.com/es/category/noticias/
• 言語領域:example.es/category/noticias/
• パラメータ:example.com/category/noticias/?lang=es

WPMLは、言語ディレクトリ、異なるドメインまたはサブドメイン、および言語パラメータをサポートしています。したがって、カテゴリURLは、言語形式、カテゴリベース、および翻訳された用語スラッグという3つの要素によって構成されます。

クロールパスと翻訳済みアーカイブ

検索エンジンは、メニュー、パンくずリスト、投稿メタデータ、サイトマップ、内部リンクなどを通じてカテゴリアーカイブを検出します。パスの一部を省略することで、URLが読みやすく、コピーしやすく、認識しやすくなる場合があります。ただし、ランキングの上昇を保証するものではありません。SEO上の最大のメリットは、有用なアーカイブごとに、安定したクロール可能なURLを1つ用意することです。

翻訳されたカテゴリアーカイブは通常、以下の情報を提供する必要があります。

• 成功した200応答。
• 目的の言語でのコンテンツ。
• 自己参照型の正規URL。
• 正しい代替言語hreflang参考文献。
• 最終的なクリーンURLを使用する内部リンク。
• アーカイブがインデックス可能な場合、適切なXMLサイトマップに含める。

Google は、正規化を重複ページや類似ページから代表的な URL を選択するプロセスと説明しています。リダイレクト、正規化注釈、サイトマップ URL、内部リンクはすべてその選択に影響を与える可能性があります。多言語ページの場合、通常、正規化は同じ言語の正規 URL を指す必要がありますが、hreflang同等の言語バージョンを接続します。

削除することでユーザーエクスペリエンスが向上する場合

カテゴリベースを削除することは、カテゴリが重要なナビゲーションレイヤーであり、そのスラッグが一意である場合に最も役立ちます。出版物では、/en/insights/、/de/einblicke/、 そして/fr/analyses/これらのパスは簡潔です。ただし、目に見えるベースは曖昧さを防ぐことができます。次のような URL/topics/security/読者にそのページがトピックアーカイブであることをすぐに伝えるようにしましょう。「SEOに優しい」という理由だけで、ベースとなる部分を削除してはいけません。最も分かりやすく、メンテナンスしやすい構造を選びましょう。

言語ターゲティングのより広範なレビューについては、以下を参照してください。多言語SEOガイド。

WPMLがカテゴリURLを処理する方法

WPMLは、言語URL形式と分類用語の翻訳を分離しています。この分離を理解しておくことで、トラブルシューティングがはるかに迅速になります。

言語URL形式

In WPML → 言語 → 言語URL形式WPMLは、以下の3つの一般的なモデルをサポートしています。

1. ディレクトリ: example.com/es/noticias/
2. ドメインまたはサブドメイン: example.es/noticias/またはes.example.com/noticias/
3. 言語パラメータ： example.com/noticias/?lang=es

ディレクトリは、すべての言語が単一のドメインに収まるため一般的です。異なるドメインでは、適切なDNSとサーバーマッピングが必要です。パラメータは通常、サーバーの変更が少なくて済みますが、多くのサイト所有者は、公開ナビゲーションにはパスベースのURLを好みます。

WPML言語ディレクトリは仮想的なものです。物理的なディレクトリは作成しないでください。/es/ or /de/フォルダを使用するか、リクエストを強制的にフォルダに送り込む。

翻訳された用語とスラッグ

カテゴリには表示名とスラッグがあります。例：

• 英語名: ニュース; スラッグ:news
• スペイン語名: Noticias; スラッグ:noticias
• ドイツ名: Nachrichten;ナメクジ:nachrichten

WPML は WordPress のカテゴリ、タグ、カスタムタクソノミーを翻訳できます。タクソノミーは翻訳可能として設定する必要があります。WPML → 設定 → 分類の翻訳用語の翻訳は以下で確認できます。WPML → 分類体系の翻訳また、親子関係の構造が変更された際には、階層構造の変更を同期させる。

カスタム分類体系には、言語固有の翻訳を含めることもできます。これは、標準のWordPressカテゴリベースの削除とは別のものです。サイトにカテゴリベースがない場合、翻訳された用語スラッグが可視パスセグメントとなるため、固有のスラッグを計画することがさらに重要になります。

パーマリンクと書き換えルール

WordPressは、すべての整形済みURLを物理ファイルとして保存するわけではありません。各リクエストを書き換えルールと比較し、一致するパスをクエリに変換します。ベース削除メソッドはこれらのルールを変更します。その後、WPMLはアクティブな言語に基づいてURLとクエリをフィルタリングします。

別のコンポーネントもルーティングを変更すると、競合が発生する可能性があります。一般的な原因としては、以下のようなものがあります。

• SEOプラグインまたはパーマリンクプラグイン。
• マネージャーをリダイレクトします。
• 重複するリライトスラッグを持つカスタム投稿タイプ。
• 分類体系や経路を登録するテーマ。
• サーバーレベルのNGINXまたはApacheのルール。
• CDNエッジリダイレクトまたはキャッシュされたエラー応答。

WordPressの設定画面だけでなく、システム全体をテストしてください。管理画面では正しく見えるURLでも、ページ遷移時に誤った言語やステータスが返される場合があります。

WPMLでカテゴリベースを使用しない場合のメリットとデメリット

これは「クリーンなURLは良いが、ベースURLは悪い」という単純な話ではなく、ルーティング上のトレードオフの問題です。

重複するルート

塩基除去ソリューションの中にはリダイレクトするものもあります/category/news/に/news/その他は両方のバージョンをロードします。両方が返した場合200検索エンジンや分析システムでは、重複したルートが表示される可能性があります。優先するバージョンを1つ選択し、非推奨のURLをリダイレクトし、最終ページでは自己参照型の正規URLを使用し、内部リンクとサイトマップを更新してください。

ナメクジの衝突

名前空間がない場合、/category/、カテゴリスラッグがルートパスで競合します。これらすべてが/guides/:

• 「ガイド」という名前のページ。
• 「ガイド」という名前のカテゴリ。
• カスタム投稿タイプ「アーカイブ」。
• 翻訳された用語がguides.

WordPressは、あるルートを解決して別のルートを非表示にしたり、プラグインによってリダイレクトを強制したりする場合があります。公開前に多言語スラッグレジストリを作成してください。ページ、投稿、カテゴリ、タグ、カスタムタクソノミー、著者ベース、カスタム投稿タイプアーカイブを含めてください。

WPMLでカテゴリベースなしを設定する方法

まずはステージング環境のコピーを使用してください。URLの変更は、すべてのカテゴリアーカイブ、内部リンク、サイトマップエントリ、正規URL、およびキャッシュされたリダイレクトに影響を与える可能性があります。

1. サイトをバックアップする

データベースとファイルの復元可能なバックアップを作成します。WordPress、WPML、テーマ、ルーティングプラグイン、キャッシュ、サーバーのバージョンを記録します。既存のリダイレクトをエクスポートします。

2. 既存のURLを一覧する

すべてのカテゴリアーカイブをすべての言語でエクスポートします。各URLについて、以下を記録します。

• 言語。
• カテゴリ名と用語ID。
• 現在のスラッグ。
• 親カテゴリ（存在する場合）。
• 現在の正典。
• 意図されたクリーンなURL。
• リダイレクト先として必須です。

また、ページ、投稿、カスタム投稿タイプ、タクソノミーアーカイブをクロールして、競合箇所を検出してください。書き換え動作を変更する前に、必ずこの作業を行ってください。

3. WordPressのパーマリンクを確認する

開ける設定 → パーマリンクサイトがプレーンなクエリ URL ではなく、適切なパーマリンク構造を使用していることを確認してください。オプションのカテゴリベースフィールドを確認してください。ただし、このフィールドが空だからといって必ずしも「ベースを削除する」という意味ではないことに注意してください。単に WordPress のデフォルトのカテゴリルートが使用されている場合もあります。

ベースを削除するには、保守的な方法を1つ選択してください。互換性のあるパーマリンク機能でも、開発チームが所有するカスタムコードでも構いません。ベースを削除するツールを2つ併用することは避けてください。

4. WPMLの言語設定を確認する

開けるWPML → 言語アクティブな URL 形式を確認してください。続行する前に、デフォルト言語とセカンダリ言語をテストしてください。ディレクトリを使用している場合は、サーバーが仮想言語パスを処理できることを確認してください。別々のドメインを使用している場合は、DNS、TLS 証明書、および同じ WordPress インストールマッピングを確認してください。

5. カテゴリ用語をマッピングして翻訳する

In WPML → 設定カテゴリを翻訳可能にします。次に開きます。WPML → 分類体系の翻訳そして、それぞれの翻訳をレビューしてください。ソースのスラッグを盲目的にコピーするのではなく、自然で独自のスラッグを使用してください。

階層構造のカテゴリについては、翻訳された子カテゴリに正しい翻訳済みの親カテゴリが割り当てられていることを確認してください。必要に応じて階層構造の変更を同期してください。スラッグマップをリリース文書として保存してください。

6. ベース除去方法とフラッシュルールを一度有効にする

ステージングで選択したメソッドをアクティブ化します。次に、書き換えルールを再生成します。通常の管理者アクションは、設定 → パーマリンク設定は一度保存してください。WP-CLIを使用しているチームは、管理されたデプロイメント環境で適切なリライトフラッシュコマンドを使用できます。

WordPressは、リライトルールのフラッシュは負荷の高い処理であると警告しています。すべてのページリクエストや頻繁に発生するフックで実行しないでください。ルールが実際に変更された場合にのみ実行してください。

7. すべての言語とテンプレートをテストする

代表的なセットをテストします。

• 最上位カテゴリと子カテゴリ。
• 翻訳済み用語と未翻訳用語を含むカテゴリ。
• ページ分けされたアーカイブ、例えば/news/page/2/.
• フィード（サイトがフィードを公開している場合）。
• ログインおよびログアウトのリクエスト。
• 各設定済み言語ディレクトリまたはドメイン。

各最終 URL について、ステータス コード、ページ タイトル、アーカイブ ヘッダー、本文言語、正規、hreflangパンくずリスト、サイトマップエントリ、内部リンク。

8. リダイレクトを追加し、慎重にデプロイする

古いカテゴリの URL ごとに、新しいカテゴリの URL とまったく同じものへの 1 対 1 の恒久的なリダイレクトを作成します。古いカテゴリをすべてホームページにリダイレクトすることは避けてください。Google は、次のような恒久的なサーバーサイド リダイレクトを推奨しています。301 or 308URLが恒久的に移動した場合。

内部リンク、メニュー、パンくずリスト、サイトマップ URL、canonical を更新し、hreflang新しいパスを使用するための値を指定します。監視対象期間中にデプロイし、キャッシュを一度クリアし、ロールバック計画を保持します。

よくある問題とその対処法

翻訳されたカテゴリページは404エラーを返します

最初のセーブ設定 → パーマリンクルールを再生成するには、一度だけ実行します。次に、カテゴリの翻訳が存在し、その分類体系が翻訳可能であり、親階層が有効であることを確認します。ステージングでは、疑わしいルーティングレイヤーを一度に 1 つだけ無効にします。オリジンが返す場合200しかし、公開URLは404CDNまたはプロキシのキャッシュを検査してください。

パーマリンク変更後にリダイレクトがループする

ループとは、多くの場合、2 つのシステムが同じ URL を反対の方法で正規化していることを意味します。WordPress リダイレクト プラグイン、SEO 正規リダイレクトを確認してください。.htaccessまたはNGINXルール、WPML言語リダイレクト、CDNエッジルール。完全なリダイレクトチェーンをトレースします。最終的なURLは、200前のホップにリダイレクトしない。

間違った言語カテゴリが表示されます

各用語が正しいWPML翻訳に紐づいていること、およびリクエストに想定される言語コンテキストが含まれていることを確認してください。メニューやハードコードされたテーマリンクも確認してください。キャッシュされたサイトでは、キャッシュキーがWPMLの選択された言語メカニズムによって異なることを確認してください。言語ディレクトリ、ドメイン、パラメータ、またはCookieを無視するキャッシュは、誤ったアーカイブを提供する可能性があります。

ナメクジは言語間で対立する

問題のあるスラッグをページ、投稿、メディア添付ファイルのルート、カスタム投稿タイプのアーカイブ、タグ、その他の分類と比較します。 1 つのルートを明確な言語固有のスラッグに名前変更します。 次に、リダイレクト マップ、内部リンク、canonical を更新します。hreflang、およびサイトマップ。

CDNまたはキャッシュルールは古い動作を維持する

WordPressのページキャッシュ、該当する場合はオブジェクトキャッシュ、リバースプロキシ、およびCDNをクリアします。キャッシュされた内容を確認します。301ブラウザやエッジネットワークがレスポンスを保持する可能性があるため、レスポンスの保持には注意が必要です。CDNとは別にオリジンをテストし、その後、クリーンなブラウザセッションでテストしてください。

Google Search Console は、カバレッジまたは正規表現に関する警告を報告します。

古いURLと新しいURLの両方を調べます。古いURLが正確な代替URLに恒久的にリダイレクトされ、新しいURLが正しいURLを返すことを確認します。200新しいアーカイブに自己正規URLが設定されており、robots.txtルールでブロックされておらず、意図したサイトマップに表示されていることを確認してください。Googleが別の正規URLを選択していないかどうかも確認してください。修正後、関連するSearch Consoleワークフローを通じて検証または再クロールをリクエストしてください。

スケーラブルなWPML翻訳のためのQueueLingoワークフロー

URLエンジニアリングと翻訳操作は互いにサポートし合うべきです。開発者は/es/noticias/正しく解決されますが、カテゴリには正確な名前、スラッグ、説明、リンクされたコンテンツ、およびレビュー状況が必要です。

スケーラブルなQueueLingoワークフローは、以下の段階を経て実行されます。

1. WPMLの準備：言語、分類体系の翻訳設定、および承認済みのスラッグマップを定義します。
2. 翻訳ジョブを作成する：対象となるWPMLコンテンツおよび関連する分類テキストを管理対象の翻訳キューに送信します。
3. エンジンを選択してください：組織の設定済み統合、言語ペア、コンテンツタイプ、予算、データポリシーに基づいて、Google翻訳、Edge翻訳、またはサポートされているLLM翻訳エンジンに作業をルーティングします。
4. レビュー結果：用語、カテゴリ名、スラッグの長さ、意図、HTMLの整合性、および地域市場向けの表現を確認してください。
5. 返信して公開する：承認された翻訳をWPMLに返し、次にURL、canonical、およびを実行します。hreflangチェック。

キューの自動化により、繰り返し発生するエクスポート、割り当て、ステータス追跡、書き戻し作業を削減できます。しかし、分類体系の翻訳ミスがナビゲーションや多数の投稿URLに影響を与える可能性があるため、人間のレビューは依然として重要です。

WPML翻訳ホスティングについて詳しく見てみましょう、デモを見る、 または無料トライアルを開始する。

実施チェックリストとベストプラクティス

発売前：

• ファイルとデータベースをバックアップし、復元アクセスが可能であることを確認してください。
• 本番環境のプラグインとサーバースタックを使用して、ステージング環境で変更内容をテストしてください。
• すべてのカテゴリのURLを、すべての言語でエクスポートします。
• 古いURLを最終的な翻訳済みURLにマッピングします。
• すべての公開コンテンツタイプで、固有のカテゴリスラッグを予約します。
• WPMLでカテゴリの翻訳と親子関係を確認してください。
• 塩基除去方法を1つ選択し、その方法の所有者を記録してください。
• WPMLの設定に従って、ディレクトリ、ドメイン、またはパラメータをテストします。
• 正確に準備する301 or 308リダイレクトします。
• 内部リンク、正規リンクを更新します。hreflangパンくずリスト、サイトマップ。

発売後：

• 古いURLセットと新しいURLセットをクロールします。
• チェック404、 柔らかい404, 5xxループや長いリダイレクトチェーン。
• 発信元、WordPress、CDN、およびブラウザのキャッシュ動作を確認してください。
• サーバーログとGoogleサーチコンソールのレポートを監視してください。
• リダイレクトはそのままにしておいてください。
• WordPress、WPML、テーマ、ルーティングプラグイン、またはサーバーのアップデート後に再度テストしてください。
• 文書のロールバック手順、データ処理、翻訳の保持、アクセス制御、およびコンプライアンス要件。

カテゴリベースではないWPMLローンチで最も安全な方法は、最も巧妙な書き換えルールを持つことではありません。完全なURLマップ、固有の翻訳済みスラッグ、アーカイブごとに優先ルートが1つ、そして再現可能なテストを備えたローンチこそが、最も安全な方法なのです。

翻訳作業をより簡単にしたいですか？QueueLingoを無料でお試しくださいまたは営業担当者にお問い合わせくださいより大規模な多言語対応WordPressワークフロー向け。

公式資料

• WPML: 言語URLフォーマットオプション —公式文書を公開する
• WPML: 投稿カテゴリ、タグ、カスタム分類の翻訳 —公式文書を公開する
• WordPress開発者向けリソース：flush_rewrite_rules()—公式文書を公開する
• Google検索セントラル：多言語・多地域サイトの管理 —公式文書を公開する
• Google検索セントラル：正規化 —公式文書を公開する
• Google検索セントラル：リダイレクトとGoogle検索 —公式文書を公開する