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

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

このドキュメントでは、まず、AEM の実装における SEO のベストプラクティスとレコメンデーションについて説明します。その次に、最初の節で提示するより複雑な実装手順のいくつかについて詳しく説明していきます。

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

このセクションでは、SEO の一般的なベストプラクティスを説明します。

URL urls

URL には、受け入れられているベストプラクティスがいくつかあります。

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

「この 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 サイトを提供している場合もあります。

この節では、これらの URL を管理し、よりわかりやすく、SEO に適した方法で URL をユーザーに表示するために AEM で使用可能なオプションを説明します。

バニティ 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 の書き換え、あるいはその両方を行うために、この場所にマッピング定義を追加できます。

マッピングを作成するには、この場所の /http または /https の下に新しい sling:Mapping ノードを作成します。このノードで設定された 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 ランキングが上がるという保証はありませんが、ベストプラクティスの 1 つとして認められています。Web サーバー上で XML ファイルを手動で維持し、サイトマップとして使用できます。ただし、Adobeでは、作成者がコンテンツを作成すると、サイトマップにその変更が自動的に反映されるように、プログラムによってサイトマップを生成することを推奨しています。

AEM では、Apache Sling Sitemap モジュールを使用して XML サイトマップを生成し、開発者と編集担当者がサイトの XML サイトマップを最新の状態に保つための様々なオプションを提供します。

Apache Sling Sitemap モジュールは、最上位のサイトマップとネストされたサイトマップを区別します。どちらも、sling:sitemapRoot プロパティが true に設定されているリソースについて生成されます。一般に、サイトマップは、ツリーの最上位のサイトマップ（他にサイトマップの上位要素を持たないリソース）のパスにあるセレクターを使用してレンダリングされます。また、この最上位のサイトマップルートはサイトマップのインデックスも公開します。このインデックスは通常、サイト所有者が検索エンジンの設定ポータルで設定したり、サイトの robots.txt に追加したりするものです。

例えば、最上位のサイトマップルートを my-page に定義し、ネストされたサイトマップルートを my-page/news に定義するサイトで、ニュースサブツリーのページ専用のサイトマップを生成するとします。これに、関連する URL は次のようになります。

デフォルトの設定では、ページのプロパティダイアログには、ページをサイトマップルートとしてマークオプションがあり、前述したように、ページ自体とその下位要素のサイトマップを生成します。この動作は SitemapGenerator インターフェイスの実装によって実装されており、代替実装を追加することで拡張することができます。ただし、XML サイトマップを再生成する頻度は、コンテンツオーサリングのワークフローとワークロードに大きく依存するので、製品には SitemapScheduler 設定は含まれていません。そのため、この機能は実質的にオプトインとなります。

XML サイトマップを生成するバックグラウンドジョブを有効にするには、SitemapScheduler を設定する必要があります。それには、PID org.apache.sling.sitemap.impl.SitemapScheduler の OSGi 設定を作成します。スケジューラー式 0 0 0 * * ? は、1 日 1 回午前 0 時にすべての XML サイトマップを再生成するための開始点として使用できます。

サイトマップ生成ジョブは、オーサー層のインスタンスとパブリッシュ層のインスタンスの両方で実行できます。ほとんどの場合、適切な正規 URL を生成できるのはパブリッシュ層インスタンスだけなので、パブリッシュ層インスタンスで生成を実行することをお勧めします（Sling リソースマッピングルールは一般にパブリッシュ層インスタンスにのみ存在するため）。ただし、SitemapLinkExternalizer インターフェイスを実装することにより、正規 URL の生成に使用される外部化メカニズムのカスタム実装をプラグインすることは可能です。カスタム実装で、オーサー層インスタンスでサイトマップの正規 URL を生成できる場合、SitemapScheduler をオーサー実行モード用に設定できます。また、XML サイトマップ生成ワークロードをオーサーサービスクラスターのインスタンス全体に分散させることができます。このシナリオでは、未公開のコンテンツ、更新されたコンテンツ、限られたユーザーグループにしか表示されないコンテンツの取り扱いに注意が必要です。

AEM Sites には、ページのツリーをトラバースしてサイトマップを生成する SitemapGenerator のデフォルトの実装が含まれています。サイトの正規 URL と（使用可能な場合は）代替言語のみを出力するように事前設定されています。また、必要に応じて、ページの最終変更日を含めるように設定することもできます。そのためには、「Adobe AEM SEO - Page Tree Sitemap Generator」設定の「最終更新日を追加」オプションを有効にし、「最終更新ソース」を選択します。サイトマップがパブリッシュ層で生成される場合は、cq:lastModified の日付を使用することをお勧めします。

サイトマップのコンテンツを制限するには、必要に応じて次のサービスインターフェイスを実装します。

デフォルトの実装が特定のユースケースで機能しない場合、または拡張ポイントが十分に柔軟性を持たない場合、カスタム SitemapGenerator を実装して、生成されるサイトマップのコンテンツを完全に制御します。次の例では、AEM Sites のデフォルトの実装ロジックを使用しています。ResourceTreeSitemapGenerator を開始点として使用して、ページのツリーをトラバースします。

import java.util.Optional;

import org.apache.sling.api.resource.Resource;
import org.apache.sling.sitemap.SitemapException;
import org.apache.sling.sitemap.builder.Sitemap;
import org.apache.sling.sitemap.builder.Url;
import org.apache.sling.sitemap.spi.common.SitemapLinkExternalizer;
import org.apache.sling.sitemap.spi.generator.ResourceTreeSitemapGenerator;
import org.apache.sling.sitemap.spi.generator.SitemapGenerator;
import org.jetbrains.annotations.NotNull;
import org.osgi.service.component.annotations.Component;
import org.osgi.service.component.annotations.Reference;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import com.adobe.aem.wcm.seo.sitemap.PageTreeSitemapGenerator;
import com.day.cq.wcm.api.Page;

@Component(
    service = SitemapGenerator.class,
    property = { "service.ranking:Integer=20" }
)
public class SitemapGeneratorImpl extends ResourceTreeSitemapGenerator {

    private static final Logger LOG = LoggerFactory.getLogger(SitemapGeneratorImpl.class);

    @Reference
    private SitemapLinkExternalizer externalizer;
    @Reference
    private PageTreeSitemapGenerator defaultGenerator;

    @Override
    protected void addResource(@NotNull String name, @NotNull Sitemap sitemap, Resource resource) throws SitemapException {
        Page page = resource.adaptTo(Page.class);
        if (page == null) {
            LOG.debug("Skipping resource at {}: not a page", resource.getPath());
            return;
        }
        String location = externalizer.externalize(resource);
        Url url = sitemap.addUrl(location + ".html");
        // add any additional content to the Url like lastmod, change frequency, and so on
    }

    @Override
    protected final boolean shouldFollow(@NotNull Resource resource) {
        return super.shouldFollow(resource)
            && Optional.ofNullable(resource.adaptTo(Page.class)).map(this::shouldFollow).orElse(Boolean.TRUE);
    }

    private boolean shouldFollow(Page page) {
        // add additional conditions to stop traversing some pages
        return !defaultGenerator.isProtected(page);
    }

    @Override
    protected final boolean shouldInclude(@NotNull Resource resource) {
        return super.shouldInclude(resource)
            && Optional.ofNullable(resource.adaptTo(Page.class)).map(this::shouldInclude).orElse(Boolean.FALSE);
    }

    private boolean shouldInclude(Page page) {
        // add additional conditions to stop including some pages
        return defaultGenerator.isPublished(page)
            && !defaultGenerator.isNoIndex(page)
            && !defaultGenerator.isRedirect(page)
            && !defaultGenerator.isProtected(page);
    }
}

さらに、XML サイトマップ用に実装された機能は、例えば、正規リンクや代替言語をページの先頭に追加する場合など、様々なユースケースでも使用できます。詳しくは、SEO タグのインターフェイスを参照してください。

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

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

301 リダイレクトの実装に関する説明や、リダイレクトが正しく機能していることをテストするためのツールについては、その他のリソースの節を参照してください。

その他のリソース additional-resources

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