SEO と URL 管理のベストプラクティス seo-and-url-management-best-practices

検索エンジン最適化（SEO）は、多くのマーケターにとって重要な関心事となっています。したがって、多くの AEM プロジェクトで SEO の懸念に対処する必要があります。

このドキュメントでは、まず、AEM の実装でこうした目的を達成するための SEO のベストプラクティスおよび推奨事項を説明します。その次に、最初の節で提示するより複雑な実装手順のいくつかについて詳しく説明していきます。

SEO のベストプラクティス seo-best-practices

この節では、一般的な SEO のベストプラクティスをいくつか説明します。

URL urls

URL に関しては、一般に認められたいくつかのベストプラクティスがあります。

AEM プロジェクトで URL を評価するときには、次のことを確認してください。

回答が「はい」の場合、URL は検索エンジンで適切に機能する可能性が高くなります。

SEO 用の URL を作成する方法に関する一般的なヒントを以下に示します。

サーバーの設定 server-configuration

サーバーの設定に関しては、次の手段を講じることで、適切なコンテンツのみがクロールされるようにすることができます。

AEM の設定 aem-configurations

ここでは、SEO に関する前述の推奨事項に従って AEM を設定するために必要な実装手順を説明します。

Sling セレクターの使用 using-sling-selectors

これまで、エンタープライズ Web アプリケーションを構築する場合、クエリパラメーターを使用するのが一般的に認められた手法でした。

近年は、URL をよりわかりやすくするために、クエリパラメーターを削除する傾向にあります。多くのプラットフォームでは、Web サーバーやコンテンツ配信ネットワーク（CDN）へのリダイレクトの実装などが行われますが、Sling を使用すると簡単です。Sling セレクター：

サーブレット用のセレクターの使用 using-selectors-for-servlets

AEMでは、サーブレットを記述する際に 2 つのオプションが用意されています。

次の例では、これらのパターンの両方に従うサーブレットの登録方法と、Sling サーブレットを使用することで得られるメリットを示します。

bin サーブレット（1 レベル下） bin-servlets-one-level-down

bin サーブレットは、多くの開発者が使い慣れている J2EE プログラミングのパターンに準拠しています。このサーブレットは、特定のパスに登録されます。AEM の場合は通常 /bin に登録され、必要な要求パラメーターをクエリ文字列から抽出します。

このタイプのサーブレットの SCR 注釈は、次のようになります。

@SlingServlet(paths = "/bin/myApp/myServlet", extensions = "json", methods = "GET")

続いて、SlingHttpServletRequest メソッドに含まれる doGet オブジェクトを使用して、クエリ文字列からパラメーターを抽出します。次に例を示します。

String myParam = req.getParameter("myParam");

使用される結果の URL は次のようになります。

https://www.mydomain.com/bin/myApp/myServlet.json?myParam=myValue

この方法では、次の点に注意してください。

Sling サーブレット（1 レベル下） sling-servlets-one-level-down

Sling サーブレットを使用すると、逆の方法でサーブレットを登録できます。 サーブレットをアドレス指定し、クエリパラメーターに基づいてサーブレットでレンダリングするコンテンツを指定するのではなく、目的のコンテンツをアドレス指定し、Sling セレクターに基づいてコンテンツをレンダリングするサーブレットを指定します。

このタイプのサーブレットの SCR 注釈は、次のようになります。

@SlingServlet(resourceTypes = "myBrand/components/pages/myPageType", selectors = "myRenderer", extensions = "json”, methods=”GET”)

この場合、URL によってアドレス指定されるリソース（myPageType リソースのインスタンス）にサーブレットで自動的にアクセスできます。アクセスするには、次の呼び出しをおこないます。

Resource myPage = req.getResource();

使用される結果の URL は次のようになります。

https://www.mydomain.com/content/my-brand/my-page.myRenderer.json

このアプローチの利点は次のとおりです。

URL の書き換え url-rewriting

AEM では、すべての Web ページが /content/my-brand/my-content に保存されます。これは、リポジトリーデータ管理の観点では便利な場合がありますが、必ずしもこの方法で顧客にサイトを表示するわけではなく、URL をできるだけ短くするという SEO のガイダンスと矛盾する可能性があります。さらに、同じ AEM インスタンスや異なるドメイン名から複数の Web サイトを提供している場合もあります。

この節では、AEMでこれらの URL を管理し、より読みやすく SEO に適した方法でユーザーに提示するために使用できるオプションについて説明します。

バニティ URL vanity-urls

作成者が、プロモーション目的で別の場所からアクセス可能なページを作成する場合、ページごとに定義される AEM のバニティー URL が役立つことがあります。ページのバニティー URL を追加するには、 Sites コンソールで該当するページに移動し、ページのプロパティを編集します。「基本」タブの下部に、バニティー URL を追加できるセクションが表示されます。複数の URL を使用してページにアクセスできるようにすると、ページの SEO 値が分断されるので、正規 URL タグをページに追加して、この問題を回避する必要があることに留意してください。

ページ名のローカライズ localized-page-names

翻訳済みコンテンツのユーザーにローカライズされたページ名を表示したい場合があります。 次に例を示します。

ページ名のローカライズに伴う課題は、AEM プラットフォームで使用可能なローカリゼーションツールの多くでは、コンテンツを同期しておくためには、ロケール間でページ名を一致させる必要があるという点です。

sling:alias プロパティを使用すると、両方を同時に実現できます。sling:alias を任意のリソースにプロパティとして追加すると、リソースのエイリアス名を使用することができます。前述の例では、次のようになります。

これにより、マルチサイトマネージャーなどの AEM 翻訳ツールでは、次のページ間の関係を引き続き維持できます。

また、エンドユーザーもページ名を母国語で操作できます。

/etc/map etc-map

標準 AEM インストールでは、

AEM で受信要求のマッピングまたはページ上の URL の書き換え、あるいはその両方を行うために、この場所にマッピング定義を追加できます。

新しいマッピングを作成するには、この場所の sling:Mapping または /http の下に新しい /https ノードを作成します。このノードで設定された sling:match および sling:internalRedirect プロパティに基づいて、AEM は、一致した URL のすべてのトラフィックを internalRedirect プロパティで指定された値にリダイレクトします。

これは、AEM および Sling の正式なドキュメントに記載されているアプローチですが、この実装で提供される正規表現のサポートは、SlingResourceResolver を直接使用することによって利用可能なオプションと比べると、範囲が限られています。また、この方法でマッピングを実装すると、Dispatcher のキャッシュの無効化に関する問題が生じることがあります。

次に、この問題がどのように生じるかについて例を示します。

キャッシュの無効化の目的で、短い URL を長い URL にマッピングするカスタムディスパッチフラッシュルールを設定する方法があります。

ただし、これをより簡単に管理する方法もあります。

Apache HTTP サーバ mod_rewrite apache-http-server-mod-rewrite

これまでに、URL をページに出力するときに、定義したマッピングを使用するために、マッピングをロジックとともにコンポーネントに実装しました。

最後の手順は、短縮された URL の Dispatcher での処理です。ここでは、mod_rewrite を使用します。mod_rewrite を使用する最大の利点は、URL が、Dispatcher モジュールに送信される​ 前に ​長い形式に再びマッピングされる点です。つまり、Dispatcher は公開サーバーに長い URL を要求し、それに応じて URL をキャッシュします。したがって、公開サーバーからの Dispatcher フラッシュ要求により、そのコンテンツを正常に無効にすることができます。

このようなルールを実装するには、Apache HTTP Server の設定で仮想ホストに RewriteRule 要素を追加します。前の例の短縮 URL を展開する場合は、次のようなルールを実装できます。

<VirtualHost *:80>
  ServerName www.mydomain.com
  RewriteEngine on
  RewriteRule ^/(.*)$ /content/my-brand/$1 [PT,L]
  …
</VirtualHost>

正規 URL タグ canonical-url-tags

正規 URL タグは、コンテンツのインデックス作成時に検索エンジンでページがどのように処理されるかを明確にするために、HTMLドキュメントの先頭に配置されるリンクタグです。 ページの URL に違いが含まれている場合でも、ページのインデックスが同じ（異なるバージョンの）ページになるようにするのがメリットです。

例えば、ページのプリンターフレンドリーなバージョンをサイトで提供する場合、検索エンジンでは、通常のバージョンのページとは別に、このページのインデックスが作成される可能性があります。正規タグは、同じであることを検索エンジンに通知します。

例：

両方について、ページの先頭に次のタグを適用します。

<link rel=”canonical” href=”my-brand/my-page.html”/>

href は、相対パスとして指定することも、絶対パスとして指定することもできます。ページの正規 URL を確認し、このタグを出力するには、このコードをページマークアップに挿入する必要があります。

大文字と小文字を区別しないための Dispatcher の設定 configuring-the-dispatcher-for-case-insensitivity

すべてのページに小文字を使用して表示することをお勧めします。 ただし、URL に大文字を使用して Web サイトにアクセスする際に、ユーザーに 404 を返さないようにする必要があります。 こうした理由から、すべての受信 URL を小文字にマッピングするように、Apache HTTP Server の設定に書き換えルールを追加することをお勧めします。さらに、小文字の名前を使用してページを作成するようコンテンツの作成者をトレーニングする必要があります。

すべての受信トラフィックを強制的に小文字に変換するように Apache を設定するには、次のコードを vhost の設定に追加します。

RewriteEngine On
RewriteMap lowercase int:tolower

さらに、次のコードを htaccess ファイルの最上部に追加します。

RewriteCond $1 [A-Z]
RewriteRule ^(.*)$ /${lowercase:$1} [R=301,L]

開発環境を保護するための robots.txt の実装 implementing-robots-txt-to-protect-development-environments

検索エンジンは、サイトをクロールする前に、サイトのルートに ファイルがあるかどうかをチェック ​するはずですrobots.txt。ただし、Google、Yahoo、Bing などの主要な検索エンジンではすべてこの点が考慮されるのに対し、なじみのない検索エンジンの中には、この点が考慮されないものもあります。

サイト全体へのアクセスをブロックするための最も簡単な方法は、robots.txt というファイルに次の内容を指定して、サイトのルートに配置することです。

User-agent: *
Disallow: /

また、実稼働環境では、インデックスが作成されないように特定のパスを禁止することもできます。

ただし、robots.txt ファイルをサイトのルートに配置すると、Dispatcher フラッシュ要求によって、このファイルが除去されることがあり、URL マッピングによって、Apache HTTP Server の設定で定義された DOCROOT とは異なる場所にサイトのルートが置かれる可能性があります。このため、このファイルをオーサーインスタンスのサイトルートに配置し、パブリッシュインスタンスにレプリケートするのが一般的です。

AEMでの XML サイトマップの作成 building-an-xml-sitemap-on-aem

クローラーは、Web サイトの構造をより深く理解するために XML サイトマップを使用します。 サイトマップを提供することで SEO ランキングが向上する保証はありませんが、これは合意に基づくベストプラクティスです。 Web サーバー上で XML ファイルを手動で維持してサイトマップとして使用できますが、サイトマップをプログラムで生成することをお勧めします。これにより、作成者が新しいコンテンツを作成すると、サイトマップに変更が自動的に反映されます。

プログラムによってサイトマップを生成するには、sitemap.xml の呼び出しをリスンする Sling サーブレットを登録します。次に、サーブレットは、サーブレット API を介して提供されたリソースを使用して、現在のページとその子を参照し、XML を出力します。 XML はその後、Dispatcher でキャッシュされます。robots.txt ファイルのサイトマッププロパティで、この場所を参照する必要があります。さらに、新しいページがアクティベートされたときには必ず、このファイルがフラッシュされるように、カスタムフラッシュルールを実装する必要があります。

レガシー URL の 301 リダイレクトの作成 creating-redirects-for-legacy-urls

新しい構造でサイトの運用を開始するときには、次の 2 つの理由から、Apache HTTP Server で 301 リダイレクトを実装し、テストすることが重要です。

301 リダイレクトの実装手順と、リダイレクトが期待どおりに動作しているかをテストするためのツールについては、以下の追加のリソースの節を必ず確認してください。

その他のリソース additional-resources

詳しくは、以下のその他のリソースを参照してください。