言語

AMPのSEO

AMP（Accelerated Mobile Pages）とは何か、その仕組み、ランキング要因になったことがない理由、2021年6月にトップニュースで必須ではなくなった理由、そして維持・削除を判断する方法を解説します。

初回公開：2026年6月27日 · 最終更新：2026年8月6日 · Advanced
言語
AI執筆者：AI v2

AMP（Accelerated Mobile Pages）は、Googleが2015年に公開した、ほぼ瞬時に表示できるモバイルページ向けのフレームワークです。ランキング要因になったことはなく、2021年6月以降はトップニュースにも必須ではありません（Core Web Vitalsが引き継ぎ、AMPバッジは削除されました）。任意で利用は減少しています。新しくAMPを構築せず、既存のAMPを維持する前に運用コストと見返りを比較してください。

TL;DR — AMPはGoogleが2015年に公開した、ほぼ瞬時に表示できるモバイルページ向けのオープンソースフレームワークです。Google AMP Cacheによる制限付きHTML／CSS／JSとプリレンダリングを組み合わせます。Googleが明言しているとおり、ランキング要因になったことはありません。また、2021年6月のページエクスペリエンスアップデート以降、トップニュースへの掲載に必須ではなくなりました。Core Web Vitalsがその役割を引き継ぎ、AMPバッジは削除されました。キャッシュされたAMPは今もgoogle.com/amp/s/…で配信されます。**Signed Exchange（SXG）**なら独自のURLで配信できますが、Chromeのみです。canonicalの関係では、rel="amphtml"を持つ自己canonicalの非AMPページと、rel="canonical"で戻るAMPページを組み合わせます。現在のAMPは任意で、利用は減少しています。新しくAMPを構築せず、維持する前に運用コスト（特に分析）と見返りを比較してください。

Evidence for this claim AMP is not required for Top Stories eligibility; Google removed the AMP requirement with the page experience rollout. Scope: Current official or standards documentation. Confidence: high · Verified: Google Search Central: Page experience rollout Evidence for this claim The Google AMP Cache is a proxy-based CDN that stores and serves valid AMP documents. Scope: Current official or standards documentation. Confidence: high · Verified: AMP: How pages are cached

少し歴史を振り返る

Googleは2015年にAMPを公開し、同年10月にはGoogle検索で利用できるようにしました。モバイルでの速度においてパブリッシャーのページが競争力を保つための、オープンウェブ版のFacebook Instant ArticlesやApple Newsへの回答という位置づけでした。公開時にはTwitter、LinkedIn、WordPress、Pinterestなどがパートナーとして支援し、後にプロジェクトの運営はOpenJS Foundationへ移りましたが、Googleは現在も最大の貢献者です。

多くのパブリッシャーが実際に導入した理由は理念ではなく、トップニュースカルーセルでした。およそ2016年から2021年まで、そこに掲載されるにはAMPが事実上必要で、GoogleはAMPの結果に稲妻（⚡）バッジを付けていました。

AMPの技術的な仕組み

AMPは制約によって速度を得ます。

  • 制限されたマークアップ。 AMPページでは<html ⚡>（または<html amp>）を宣言し、AMP JSランタイム（<script async src="https://cdn.ampproject.org/v0.js">）を読み込み、AMPのボイラープレートと必須のcharsetおよびviewportメタタグを含めます。
  • 作成者のJavaScriptは不可。 独自のJSは、サンドボックス化されたamp-scriptコンポーネント経由を除いて使用できません。サードパーティーのJSはiframe内でのみ動作します。実行される処理はすべて非同期なので、レンダリングをブロックしません。
  • CSSはインラインで、75KBが上限。 外部スタイルシートは使えません。
  • リソースの寸法は静的に宣言。 画像と埋め込み要素の領域をあらかじめ確保し、レイアウトシフトを防ぎます。

これらのルールにより、ユーザーがタップする前に、Googleは非表示のiframe内でAMPページを安全にプリレンダリングできます。それが「瞬時に」感じられる理由です。

Google AMP Cache

AMPの速度はフレームワークだけでなく、配信によるものでもあります。GoogleはAMPページの検証済みで最適化されたコピーをcdn.ampproject.orgに保存し、HTTPSと最新のプロトコルで配信し、画像を最適化します。覚えておくべき結果の1つは、キャッシュされたAMPでは、コンテンツのホストがあなたのサーバーではなくGoogleのインフラになることです。なお、デスクトップのAMPページはAMP Cacheから配信されません。canonical AMPは通常の結果として扱われるため、CDNによる高速化の利点は実質的にモバイル向けです。

Google検索で実際に起きたこと

重要なタイムラインは次のとおりです。

  • 2016〜2021年： 検索結果にAMPバッジ（⚡）を表示。トップニュースにはAMPが必須でした。
  • 2021年4月： Googleはページエクスペリエンスアップデートに伴い、トップニュースでは*"using the AMP format is no longer required"*（AMP形式の使用はもはや必須ではない）と発表しました。
  • 2021年6月： ページエクスペリエンスアップデートを展開。トップニュースの掲載資格を判定するパフォーマンスシグナルがCore Web Vitalsになり、Googleは検索結果からAMPバッジを削除しました。
  • 2021年〜現在： AMPは任意でランキングを押し上げず、パフォーマンス関連のシグナルを実際に左右するのはCWVです。

必要な結論はこれです。AMP自体はランキング要因ではなく、トップニュースに入るための切符でもありません。

URL書き換えの問題（とSigned Exchange）

1つのAMP記事には、実際には3つのURLが関係します。元のパブリッシャーURL、cdn.ampproject.org上のAMP Cache URL、そしてGoogle AMP ViewerのURLです。後者はhttps://www.google.com/amp/s/[your-domain]/[path]のような形になります。プリレンダリングには同一オリジンのiframeが必要なため、Viewerはコンテンツをgoogle.comのURLで配信し、ユーザーにはあなたのドメインではなくGoogleのドメインが表示されます。これはブランドの混乱やアトリビューションの問題を実際に引き起こしてきました。

**Signed Exchange（SXG）**がこの問題への対策です。AMPドキュメントをURLに結び付いた暗号署名で包むため、Chromeが検証するとアドレスバーにはあなたのドメインが表示されます。Googleは、対応している場合、AMP ViewerよりSigned Exchangeを優先します。ただし、SXGはChromeのみで、署名の有効期間は最大7日（そのためパッケージャーが再署名する必要があります）。リッチ結果と基本結果に限られ、カルーセルには対応せず、amppackagerサーバーまたはサードパーティーのSXGプロバイダーが必要です。「正しい」配信方法ではありますが、運用負荷は無視できません。

AMPのcanonicalタグ

AMPの実装で最も頻繁に壊れるのがここです。構成は2つあります。

  • ペア構成（最も一般的）： 非AMPページと、別のAMPページを用意します。
    • 非AMPページは自分自身をcanonicalとし、 <link rel="amphtml" href="https://example.com/article/amp/">を追加します。
    • AMPページには<link rel="canonical" href="https://example.com/article/">を追加し、非AMP版を指します。
  • AMPのみ： 1つのURLがcanonicalとAMPを兼ねるため、自分自身を参照します。

実務上のルールはこうです。Googleがインデックスするのはcanonical URL（AMPは重複として扱われます）なので、両方のバージョンに構造化データを置き、サイトマップにはcanonical URLだけを含め、AMPの発見はrel="amphtml"に任せます。Googleはこのrel="amphtml"／rel="canonical"のペアを正確に文書化しています。上のどちらの構成にも当てはまらない場合は、AMPについて：コンテンツを発見可能にするで基準となる関係を確認してください。

AMPの分析上の課題

AMPのトラッキングの複雑さは、理論上の話ではなく、実際の運用コストです。

  • リファラーの問題。 キャッシュされたAMPページからのトラフィックは、これまでオーガニック検索ではなくcdn.ampproject.orgからのリファラルとして表示されることがありました。対策は、そのドメインをリファラー除外に加えることです。
  • セッションの分断。 キャッシュされたAMPページから非AMPページへ移動すると、標準では新しいセッションが始まりました。キャッシュとサイトの境界を越えてamp_id= URLパラメーターでクライアントIDを渡すAMP Linkerが、セッションをつなぎます。
  • AMP向けGTMはamp-analyticsコンポーネントを使います。標準のGTMより設定が複雑で、機能も少なくなります。
  • GA4は2024年6月にAMPのネイティブサポートを得ました。 それ以前のAMP計測は、コミュニティー実装に頼る面がありました。

Search Engine LandがAMPを停止した際、報告された成果の1つは「a clearer picture of their audience analytics」（オーディエンス分析をより明確に把握できること）でした。これは既知の問題点です。

その他のAMPの用途（混同しないために）

  • Web Stories（2018年にAMP Storiesとして開始し、2020年にGoogle Web Storiesへ改称）は、AMPを基盤にした視覚的でタップして読むストーリー形式です。検索、Discover、画像に表示されます。通常のAMP記事とは別物です。
  • AMP for Emailは、インタラクティブなコンテンツ（フォーム、カルーセル、リアルタイムデータ）をGmailなど一部のクライアントに取り込みます。メールの機能であり、検索SEOの機能ではありません。存在を知っておく価値はありますが、ランキングには関係しません。

BingとAMP

Bingは2016年9月にAMPのオープンソース活動へ加わり、一時期は独自のAMP Viewerとキャッシュを運用して、独自の稲妻表示も行っていました。しかしBingによれば、AMPはランキングアルゴリズムにまったく影響しませんでした。現在のBingにおけるAMPサポートはほぼ歴史的なものです。AMPを必要とするニュースカルーセルも、Bing Webmaster Toolsで目立ったAMPレポートもありません。実際の姿勢はGoogleと同じで、任意であり、ランキングを押し上げません。

それでもAMPを使うべきか

AMPを維持する意味があるケース：

  • すでにAMPを導入しており、Search Consoleのエラー率が低く、切り替えコストが高いニュース／メディアパブリッシャー。
  • AMPが良好なCore Web Vitalsを実現するための最も手軽な方法になっている、単純なコンテンツのサイト。

AMPを削除するケース：

  • AMPが対応できない機能を持つエンタープライズサイト。これは私がSMX Westで主張したまさにそのケースです。大企業で構造が複雑な場合、AMPは実装が難しく、過剰なリスクを抱えます。また、AMPが許可しないサイト要素を維持すべき現実的なビジネス上の理由もあります。
  • もはや存在しないトップニュースバッジだけを理由にAMPを運用しているサイト。
  • 分析の明確さが重要なサイト。AMPのトラッキングの複雑さは実際のコストです。
  • すでにCore Web Vitalsを通過しているサイト。AMPによる追加の利点はありません。
  • AMPのURL書き換えがブランドやアトリビューションの問題を起こしているサイト。

2026年の正直な答え： AMPは任意で、利用は減少しています。新しいプロジェクトでは導入しないでください。既存のプロジェクトでは、運用コストと残っている利点を比較しましょう。

AMPを削除する方法（決めた場合）

  1. canonical（非AMP）ページからrel="amphtml"タグを削除します。
  2. AMP URLをcanonicalの非AMP相当URLへ301リダイレクトします。
  3. Search ConsoleでAMPステータスレポートの監視を停止します。
  4. 数週間後にSearch ConsoleのAMPエラーが解消されたことを確認します。

正しく行えば、canonicalページは引き続きインデックスされ、ランキングされます。Search Engine Landを含む大手パブリッシャーも、トラフィックへの影響を最小限に抑えてAMPを削除しています。

なくすべき神話

  • 「AMPはランキングを押し上げる。」 そんなことはありません。AMPはランキング要因ではなく、速度が要因です。AMPは速度を得る1つの方法にすぎません。
  • 「トップニュースにはAMPが必要だ。」 2021年6月以降は誤りです。
  • 「AMPは通常のページより常に速い。」 いいえ。優位性はGoogleによるキャッシュコピーのプリレンダリングから生じます。高速な非AMPページが低速なAMPページに勝つこともあります。
  • 「AMP URLは自分のURLだ。」 Signed Exchange（Chromeのみ）の場合に限ります。標準のViewerではgoogle.com/amp/s/…が表示されます。
  • 「AMPを削除するとトラフィックが急落する。」 canonicalとリダイレクトを正しく処理すれば、通常は影響を最小限にできます。

現在重要なパフォーマンスシグナルについては、Core Web Vitalsと、より広いWeb Performanceクラスターを参照してください。

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.