Webサイト制作会社が構造化データに対応しているかを判断するには？

Structured data website builder providerを評価する際、サービス提供者が「構造化データに対応しています」と答えるだけでは不十分です。本当に確認すべきなのは、どのページにマークアップを設定できるのか、データの取得元はどこか、変更後に同期されるのか、公開後の検証と保守を誰が担当するのかです。特に多言語の商品カタログを持つ貿易企業にとって、個別ページにコードを挿入できることと、サイト全体のマークアップを長期的に管理できることは、まったく異なる能力です。

まず区別する：コードの挿入に対応しているのか、業務データのマッピングに対応しているのか

構造化データとは、定められた形式でページの内容を記述する情報です。一般的にはSchema.orgの語彙とJSON-LD形式を使用し、ページが企業、製品、その他のエンティティに関するものであることを検索エンジンに伝えます。キーワードタグではなく、ページ本文の代わりにもなりません。検索エンジンがマークアップを認識しても、インデックス登録やランキング向上、リッチリザルトの表示が保証されるわけではありません。

サービスを選定する際は、具体的な操作を実演してもらうとよいでしょう。管理画面で商品名や画像を変更してページを公開した後、構造化データも同期して変わるかを確認します。ページごとにコードを手作業で記述するしかない場合、少数の固定ページなら対応できるかもしれません。しかし、商品数が多く更新頻度も高い場合、繰り返しの保守によってページ内容とマークアップが一致しなくなるおそれがあります。

コードをどの階層に追加するのかも確認してください。サイト全体の共通設定なのか、ページテンプレートの設定なのか、個別ページのカスタムコードなのかを明確にします。サイト全体に設定するコードは企業共通情報に適していますが、同じ商品情報をすべての商品ページに複製する用途には適しません。判断のポイントは「コードを貼り付けられるか」ではなく、適切なページに対応するデータを出力できるかどうかです。

対応タイプの多さではなく、ページの種類に応じてマークアップを確認する

企業サイトでは通常、Organization、BreadcrumbList、Productなどのタイプが関係します。記事ページではArticleが関係する場合があります。どのタイプを採用するかは、ページの実際の内容と対象検索エンジンの要件に基づいて決める必要があります。Schema.orgは利用可能な語彙を定義していますが、あるタイプが存在するからといって、Googleなどの検索エンジンが必ず対応する表示機能を提供するとは限りません。

B2Bの商品ページでは、フィールド情報の正確さに特に注意が必要です。メーカーのサイトには仕様、用途、問い合わせ窓口のみが掲載され、価格や在庫が公開されていない場合があります。その場合、フィールドを埋めるために価格、通貨、供給状況を捏造してはいけません。ページに実際に取引可能な見積価格が表示されている場合は、マークアップ内の価格、通貨、適用条件がページの内容と一致しているか確認します。

サービス提供者が提示する「対応一覧」については、フィールド単位の詳細も確認してください。商品型番を管理画面のフィールドにマッピングできるか、パンくずリストがカテゴリ階層に応じて変わるか、企業名、URL、ロゴの更新後に古いデータが削除されるか、といった点です。特定のタイプに対応していることは、そのタイプに必要なフィールドをすべて設定できることを意味しません。

一連のデモで設定・公開の機能を検証する

機能紹介を見るより確実なのは、テスト環境でサービス提供者に「設定、公開、変更、再検証」の全工程を実行してもらうことです。商品詳細ページと一覧またはカテゴリページを一つずつ選び、それぞれに個別のマークアップを設定できるか、テンプレートの変更が他のページに影響するか、公開後の実際のURLに何が出力されるかを確認します。

受け入れ時には、次の項目を重点的に確認できます。

• ページのソースコードまたはレンダリング後のページを確認し、JSON-LDが実際に存在すること、URL、名称、画像などのフィールドが現在のコンテンツを参照していることを確認します。
• Schema.orgのマークアップ検証ツールで構文と語彙を確認します。Googleがサポートするリッチリザルトのタイプについては、Googleのリッチリザルトテストツールも使用し、該当する問題を確認します。
• システムが自動生成するマークアップと手動で追加したマークアップを併せて確認し、同じエンティティに異なる名称、URL、価格が設定されていないか確認します。
• 実際のフィールドを一つ変更して再公開し、古い値が残っていないことを確認します。必要に応じてキャッシュをクリアして再テストします。

検証ツールでエラーが報告されなかったとしても、そのツールの検査範囲内で該当する問題が見つからなかったことを示すにすぎず、業務データの正確さを意味するわけではありません。ツールはページ内容の人手による確認に代わるものではなく、検索結果に特別な表示が必ず出ることも保証しません。スクリプトでマークアップを生成するサイトでは、検索エンジンが関連ページのリソースにアクセスし、処理できるかどうかも確認してください。

多言語サイトの課題は、データの関連付けと保守責任にある

同じ商品でも、言語ごとのページでは名称、説明、ページURLが異なる一方、商品型番は同じ場合があります。評価時には各言語版を抜き取り確認し、マークアップにそのページの言語とURLが使われているか、画像にアクセスできるか、通貨や見積価格がそのページに適用されるかを確認します。デフォルト言語だけを検証して、多言語サイト全体の設定が完了したと判断してはいけません。

どの情報がシステムによって自動生成され、どの情報を編集担当者が入力するのかも明確にしてください。たとえば企業の連絡先が変更された際、ページ本文は更新されても、フッターと構造化データに古い情報が残っていると、後の原因究明に手間がかかります。重要なフィールドのデータソースを明確にし、コンテンツ更新後の確認手順を定めておくと、より確実です。

ウェブサイトとマーケティングを一体的に提供するチームは、コンテンツ、検索最適化、広告用ページの管理にも同時に関わることが一般的です。易营宝は、スマートサイト構築、多言語サイト、SEOなどを事業領域としています。このようなソリューションを評価する際は、部門間の連携も確認項目に含めるとよいでしょう。フィールド設定の担当者、翻訳と業務情報の確認者、テンプレート更新後の再検証担当者を明確にします。具体的な構造化データ機能については、プロジェクトのデモと納品条件に基づいて判断してください。

受け入れ条件を納品範囲に明記する

契約前に、サービス提供者に対象ページ、マークアップのタイプ、フィールドのデータソース、設定権限、検証方法を提示してもらい、新しい言語の追加や商品テンプレートの変更に追加開発が必要かどうかも説明してもらうことをおすすめします。カスタムコードについては、企業側で確認、変更、削除できるか、テンプレートを変更した際にコードをどのように移行するかも確認してください。

受け入れ確認ですべてのページを対象にする必要はありませんが、異なるテンプレートと言語版からページを抽出し、テスト用URLと結果を記録しておきます。信頼できる判断基準は、業務担当者がコンテンツを更新した後にシステムが一貫した情報を出力できること、技術担当者が独立して確認できること、問題発生時に明確な責任者を特定できることです。これらの条件を満たして初めて、構造化データがウェブサイトの日常的な保守プロセスに組み込まれたといえます。