SSM - メタデータのための統一規格

SSM - メタデータのための統一規格
基準

28

16 分。

定義

SSM規格は、メタデータのセマンティクス、アクセシビリティ、および動作ロジックに関する要件を規定しています。

構造と意味

ページタイトルと説明

  • インデックス登録の対象となる各ページには、内容を正確に表す固有の<title>を設定する。ページの主な内容を簡潔に示し、サイト名や汎用的なテンプレート文で置き換えない。
  • インデックス登録の対象となる各ページには、内容に沿った固有の説明文を設定する。表示される内容を反映し、キーワードの羅列にしない。
  • <title>や説明文に、すべてのサイトに共通する文字数上限はない。検索エンジンがタイトルを省略したり、ページ内の別のテキストから検索結果のタイトルやスニペットを生成したりする場合がある。
  • ページの説明文が検索スニペットに使われる場合もあるが、検索エンジンが別の文章を選ぶこともある。タイトルや説明文によってクリック数や検索順位が保証されるわけではない。

Canonical URL

  • 重複または非常によく似たURLの集合には、rel="canonical"または適切なHTTPレスポンスの仕組みを使って、優先するCanonical URLを指定する。
  • Canonical URLは、同等の主要コンテンツを持つアクセス可能なページを指す必要がある。通常は安定した絶対HTTPS URLを使用し、優先するページ自身にも自己参照のcanonicalを設定する。
  • canonicalは検索エンジンへのシグナルであり、無条件に従わせる命令ではない。優先するURLの判断や類似ページのシグナル集約に役立つが、ページを隠す方法でも、重複コンテンツに対する自動的な「ペナルティ」を防ぐ手段でもない。
  • 主要な内容が翻訳された別言語のページを、ひとつのcanonical URLにまとめない。言語ごとに固有のcanonical URLを設定し、hreflangで相互に関連付ける。

インデックス登録とクロール

  • インデックス登録とクロールは別の処理である。robots.txtは対応するクローラーがアクセスできるURLやリソースを制御するが、それだけでURLを検索結果から確実に除外することはできない。
  • アクセス可能なページをインデックスから除外するには、ページのメタデータまたはHTTPヘッダーX-Robots-Tagに、検索エンジンが対応するnoindexディレクティブを指定する。クローラーがこのディレクティブを処理するには、ページを取得できる必要がある。
  • robots.txtでブロックされたURLでも、外部リンクなどから検索エンジンに知られたままになる場合がある。ページ内容を取得できないため、noindexが読み取られないこともある。したがって、robots.txtは機密情報を保護する仕組みではない。
  • indexとfollowは通常の既定動作であり、必要がなければ明示しない。ディレクティブの値と対応状況は、対象とする検索エンジンごとに確認する。
  • 制限されたコンテンツや機密情報は、メタデータやクロール規則だけでなく、認証とアクセス制御で保護する。
  • アクセス可能なページは適切なHTTPステータスを返す。移転したリソースにはリダイレクトを設定し、削除したリソースには適切な不存在ステータスを返す。XMLサイトマップは優先URLの発見に役立つが、クロールやインデックス登録を保証しない。

ページをインデックスから除外するディレクティブの例:

<meta name="robots" content="noindex">

クローラーがこのディレクティブを確認できるのは、ページをクロールした場合に限られる。同じURLをrobots.txtでブロックすると、クローラーがnoindexを取得できないことがある。

メタデータの配信

  • 重要なメタデータは、対象とするクローラーやプラットフォームから取得できるようにする。受け取り側がJavaScriptを処理するか不明、または処理に制限がある場合は、初期HTMLレスポンスまたはHTTPヘッダーにメタデータを含める。
  • クライアント側で生成する場合は、レンダリング後のドキュメントと実際のHTTPレスポンスを確認する。ハイドレーション時の変更によって、メタデータの値が競合したり、異なるcanonical URLが複数残ったりしないようにする。

多言語対応と言語別ページ

  • 翻訳ページを別々のURLで公開する場合、各言語版に固有の恒久的なURLを割り当て、同じ言語と内容のページを指すcanonical URLを設定する。
  • 対応するページ同士は、正しいhreflang値を付けたrel="alternate"で関連付ける。各ページには自分自身と利用可能な他の言語版をすべて記載する。リンクは相互参照とし、リンク先はクロールおよびインデックス登録が可能であること。
  • hreflangには有効な言語コードを指定し、必要に応じて地域コードを追加する。特定の言語版に該当しない利用者向けの既定ページがある場合は、x-defaultを指定できる。
  • ドキュメントの主言語はlang属性で示す。この属性は支援技術やユーザーエージェントがコンテンツの言語を判定するのに役立つが、hreflangの代わりにはならない。
  • og:localeはOpen Graphのロケールを言語_地域の形式で指定する。たとえば日本語ページではja_JPを使用する。複数のog:locale:alternateで、そのページが利用できる他のロケールを列挙する。
  • og:locale:alternateは翻訳ページのURLを関連付けるものではなく、hreflangの代わりにもならない。代替ロケールの一覧は、実際に利用できる翻訳と一致させる。

言語別URLを関連付ける例:

<html lang="ja">
<head>
  <link rel="alternate" hreflang="ru" href="https://example.com/ru/article">
  <link rel="alternate" hreflang="en" href="https://example.com/en/article">
  <link rel="alternate" hreflang="de" href="https://example.com/de/article">
  <link rel="alternate" hreflang="ja" href="https://example.com/ja/article">
  <link rel="alternate" hreflang="x-default" href="https://example.com/article">
</head>
</html>

各言語版に、対応するlang値と同じ完全な相互リンクのセットを記述する。

リンク共有用メタデータ

Open Graph

  • Open Graphのプレビューには、プロトコルの基本プロパティであるog:title、og:type、og:image、og:urlを指定する。
  • og:descriptionには、そのページの内容を簡潔に記述する。画像にはog:image:altを指定することが望ましい。ここには投稿のキャプションではなく、画像の内容を記述する。
  • 画像URLとog:urlには、外部からアクセスできる絶対URLを指定する。画像にはHTTPSを推奨する。認証なしで取得でき、プラットフォームのクローラーがブロックされていないこと。
  • Open Graphの値は、共有されるページ自体の内容に一致させる。og:urlはページの優先する恒久的なURLと一致させる。
  • og:localeとog:locale:alternateはオブジェクトのロケールを伝えるために使うが、ソーシャルプラットフォームでローカライズ済みプレビューが表示されることを保証しない。

X Cards

  • Xのカードには、対象の投稿形式でサポートされている場合、twitter:card="summary_large_image"を含むtwitter:*プロパティを設定できる。
  • summary_large_imageは大きな画像を含むカード形式を指定する。最大のリーチやCTR、フィード内での優先表示を保証するものではない。
  • Xのメタデータをすべてのソーシャルネットワークで共通の仕様として扱わない。対応状況、優先順位、プレビューのキャッシュ方法はプラットフォームごとに異なり、変更される場合がある。
  • カードのタイトル、説明、画像はページ内容と一致させる。個別の値がない場合にOpen Graphの値を使うプラットフォームもあるが、対象のプラットフォームで動作を確認する。

サイトとウェブアプリのアイコン

サイトアイコン

  • サイトアイコンはrel="icon"のリンク関係を使ってひとつ以上指定する。対応する形式とサイズは、ブラウザーや表示場所によって異なる。
  • SVGは拡大縮小できるアイコンに適しているが、すべての環境で対応する唯一の形式とはみなさない。対象ブラウザーや環境との互換性に応じて、ICOまたはラスター形式も用意する。
  • faviconは正方形で、外部から取得でき、安定したURLで配信する。16×16、32×32、48×48などは選択可能なサイズであり、必須の完全な一覧ではない。
  • ブラウザータブや検索結果に使うアイコンと、インストール可能なウェブアプリに使うアイコンは、異なる仕組みやファイルで指定する場合がある。

Web App Manifestとモバイルプラットフォーム

  • ウェブアプリの設定が必要な場合にsite.webmanifestを読み込む。マニフェストでは、アプリ名、開始URL、表示モード、テーマ、アイコンセットを定義できる。
  • アイコンの選択に必要な場合は、マニフェストのアイコンに正確な形式、サイズ、用途を指定する。192×192と512×512のセットは一部のインストール環境で互換性のためによく使われるが、すべてのサイトや端末に共通する要件ではない。
  • マニフェストを追加しただけでサイトがインストール済みアプリになるわけではなく、インストール可能とも限らない。対応状況や条件はブラウザー、OS、サイトの機能によって異なる。
  • マニフェストのtheme_colorまたは対応するメタデータは、ブラウザーやアプリのUI色に影響する場合がある。対応状況や見た目の変化はプラットフォームごとに異なる。
  • apple-touch-iconとapple-mobile-web-app-capableは、Apple端末でサイトをホーム画面に追加し、独立したウィンドウで起動するシナリオに関係する。これらはプラットフォーム固有の設定であり、その利用環境を対象とする場合に限って使用する。通常のウェブサイトには必須ではない。
  • マニフェストとApple向けアイコンで、使用するファイルの選択が競合する場合がある。対象とするOSおよびブラウザーのバージョンで、実際に使われるアイコンを確認する。

構造化データ

  • 構造化データは、ページに表示される内容を正確に表し、そのコンテンツの種類に適合する場合にのみ追加する。
  • JSON-LDは構造化データの形式のひとつであり、Googleのドキュメントで推奨される形式である。Schema.orgの最新ドキュメントと、データを利用する各サービスの要件に基づいてタイプとプロパティを選ぶ。
  • マークアップによって一部のリッチリザルトの対象となる場合があるが、表示が保証されるわけではなく、質の高いコンテンツの代わりにもならない。
  • 評価、価格、商品の在庫状況など変化する情報は、正確かつ最新で、利用者にも見える必要がある。構文が正しくても誤解を招くマークアップは、構造化データの目的に適合しない。

Articleタイプの内容に対応するJSON-LDの例:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "記事タイトル",
  "image": "https://example.com/ja/images/article.webp",
  "datePublished": "2026-09-26",
  "dateModified": "2026-09-26"
}
</script>

各フィールドにはページの実際の情報を設定する。他の種類のコンテンツには適切なタイプとプロパティを使用し、任意項目に架空の値を設定しない。

テスト

  • インデックス登録の対象となる各ページについて、固有の<title>と説明文があり、実際の内容と一致することを確認する。
  • HTTPステータス、クローラーのアクセス可否、robots.txt、noindex、リダイレクト、canonical間の競合を確認する。
  • canonical URLが意図した言語版を指し、内部リンク、サイトマップ、og:urlと一致することを確認する。
  • サイトマップにアクセスでき、記載されたURLが正しいことを確認する。サイトマップにURLが含まれているだけでは、インデックス登録の証拠にならない。
  • 多言語ページでは、lang、すべてのhreflangリンク、相互参照、各言語版へのアクセス可否を確認する。
  • 対象とするソーシャルプラットフォームでプレビューを確認する。絶対URL、画像の読み込み、タイトル、説明、ロケール、キャッシュの挙動を検証する。
  • 対象ブラウザーとOSで、favicon、マニフェストのアイコン、ウェブアプリの表示モードを確認する。
  • 選択したタイプに対応する場合、Schema.orgバリデーターやリッチリザルトのテストツールで構造化データを検証する。検証に合格しても、リッチリザルトの表示は保証されない。

SSMチェックリスト

カテゴリー主な要素目的
ページメタデータ<title>、description検索結果でページを正確に示す
インデックス登録robots、noindex、robots.txt、HTTPステータスクロールとページのインデックス登録可否を制御する
CanonicalCanonical URL、リダイレクト、サイトマップ優先URLをそろえ、URLの発見を支援する
言語lang、hreflang、og:locale言語別ページを関連付け、ロケールを示す
SNSプレビューOpen Graph、Xメタデータ対応プラットフォームで共有リンクを表示する
アイコンとウェブアプリfavicon、Web App Manifest、プラットフォーム別アイコンサイトを識別し、対応するインストール方法を設定する
構造化データSchema.org、JSON-LDコンテンツ構造を示し、対応するリッチリザルトの対象となる可能性を高める

メタデータの全体例

以下は、最終的に生成されるドキュメントの一部を示す。メタデータはCMS、テンプレート、サーバーサイドレンダリング、静的サイトジェネレーターなどで生成できる。要件の対象は生成後のドキュメントとレスポンスであり、特定プラットフォームのAPIではない。

<html lang="ja">
<head>
  <title>ページタイトル</title>
  <meta name="description" content="ページ内容を簡潔に説明する文です。">
  <link rel="canonical" href="https://example.com/ja/article">
  <link rel="alternate" hreflang="ru" href="https://example.com/ru/article">
  <link rel="alternate" hreflang="en" href="https://example.com/en/article">
  <link rel="alternate" hreflang="de" href="https://example.com/de/article">
  <link rel="alternate" hreflang="ja" href="https://example.com/ja/article">
  <link rel="alternate" hreflang="x-default" href="https://example.com/article">

  <meta property="og:title" content="ページタイトル">
  <meta property="og:type" content="article">
  <meta property="og:url" content="https://example.com/ja/article">
  <meta property="og:image" content="https://example.com/ja/images/article-share.webp">
  <meta property="og:image:alt" content="記事のイラスト">
  <meta property="og:locale" content="ja_JP">
  <meta property="og:locale:alternate" content="ru_RU">
  <meta property="og:locale:alternate" content="en_US">
  <meta property="og:locale:alternate" content="de_DE">

  <meta name="twitter:card" content="summary_large_image">
  <link rel="icon" href="/favicon.svg" type="image/svg+xml">
  <link rel="icon" href="/favicon.ico">
  <link rel="manifest" href="/site.webmanifest">
  <meta name="theme-color" content="#ffffff">
</head>
</html>

関連記事

  • Reactコンポーネントの構造

    各Reactコンポーネントがどのような外観であるべきか、私の考え

    421

    13 分。

  • SST - タブに関する統一規格

    SST規格は、タブのセマンティクス、アクセシビリティ、および動作ロジックに関する要件を規定しています

    62

    11 分。

  • SSF-U - フルスクリーン表示の統一規格

    SSF-U規格は、フルスクリーン表示のセマンティクス、アクセシビリティ、および動作ロジックに関する要件を規定しています

    248

    3 分。

  • SSA - アコーディオンの統一標準

    SSA規格は、アコーディオンのセマンティクス、アクセシビリティ、および動作ロジックに関する要件を定めています

    258

    4 分。

  • ウェブサイトにおける悪い慣行

    ウェブデザインにおける致命的なミスの分析。スライダー、自動再生、重いページがコンバージョン率やGoogleでの検索順位を低下させる理由

    232

    2 分。

  • SSP - ページネーションの統一規格

    SSP規格は、ページネーションのセマンティクス、アクセシビリティ、および動作ロジックに関する要件を規定しています

    240

    3 分。

  • すべての記事

ご連絡ください