bloginfo()でサイト情報とOGP・構造化データを一元管理する方法|小売ECのブランド一貫性とSEO設計

ECサイトを長く運用していると、いつの間にか「サイト名の表記がページによって違う」「OGPで表示される会社名と実際のブランド名が食い違っている」といった小さなズレが蓄積していきます。担当者が変わるたびにハードコーディングでサイト名やURLを書き足していくと、こうしたズレは避けられません。

bloginfo()は、WordPress管理画面の「設定」で登録したサイトタイトルやキャッチフレーズ、サイトURL、管理者メールアドレスなどのサイト情報を、テーマやテンプレートから呼び出して表示するための基本的なテンプレートタグです。地味な関数に見えますが、この関数(およびPHP変数として値を取得する get_bloginfo())を正しく使うかどうかで、サイト全体のメタ情報の一貫性が大きく変わります。

この記事では、bloginfo()の技術仕様を踏まえたうえで、小売ECサイトにおいてサイト情報・OGP・構造化データをどう一元管理し、ブランドの一貫性とSEOを両立させるかを解説します。

この記事で分かること

  • bloginfo()で取得できる情報の種類と使い分け
  • サイト名・URL表記のブレが小売ECのSEOとブランド信頼性に与える影響
  • OGP・構造化データにサイト情報を安全に流し込む実装パターン
  • ハードコーディングによる表記ズレを防ぐ運用ルール
  • マルチブランド・多言語展開時の注意点
  • 制作会社に依頼する際に確認しておくべきポイント

サイト情報の表記ブレが小売ECの信頼性を落とす理由

ユーザーは検索結果やSNSのシェアカードで最初にサイトの情報に触れます。このとき、ページごとにサイト名の表記が「株式会社◯◯」だったり「◯◯ショップ」だったり揺れていると、同じサイトなのか不安に感じるユーザーが出てきます。特に決済や個人情報入力が発生するECサイトでは、こうした細かな表記の不一致が信頼感の低下に直結します。

また、検索エンジンに送る構造化データ(Organization、WebSiteなど)にサイト名やURLが正しく一貫して記述されていないと、検索結果でのサイト名表示やナレッジパネルの生成に悪影響が出る可能性があります。

  • ページによってサイト名表記が異なり、ユーザーが不安に感じる
  • OGPのサイト名とページタイトルの整合が取れていない
  • 構造化データのpublisher情報とフッターの会社名表記が食い違う
  • サイトURLをハードコーディングしていて、独自ドメイン移行時に大量の修正が発生する

bloginfo()の役割を実務目線で理解する

bloginfo()は第一引数の$showパラメーターに指定した文字列に応じて、様々なサイト情報を出力します。主なパラメーターは次のとおりです。

bloginfo( 'name' );           // サイトタイトル
bloginfo( 'description' );    // キャッチフレーズ
bloginfo( 'url' );            // サイトアドレス(フロントURL)
bloginfo( 'admin_email' );    // 管理者メールアドレス
bloginfo( 'version' );        // WordPressバージョン
bloginfo( 'charset' );        // 文字エンコーディング
bloginfo( 'language' );       // サイトの言語コード

bloginfo()は値を直接出力(echo)する関数なので、OGPタグや構造化データのJSON-LDのように「値を組み立ててから出力したい」場面では、PHP変数として値を取得できる get_bloginfo() を使う必要があります。

$site_name = get_bloginfo( 'name' );
$site_url  = get_bloginfo( 'url' );

$og_tags = '<meta property="og:site_name" content="' . esc_attr( $site_name ) . '">';
$og_tags .= '<meta property="og:url" content="' . esc_url( $site_url ) . '">';

echo $og_tags;

注意点として、子テーマ開発時にテーマファイルのパスを取得したい場合は bloginfo(‘stylesheet_url’) ではなく get_stylesheet_directory_uri() を使う方が推奨されます。また、独自ドメインへの移行やマルチサイト構成では bloginfo(‘url’) の代わりに home_url() や site_url() が推奨されるケースもあり、用途に応じた使い分けが必要です。

小売事業者のインバウンド集客に落とし込む考え方

OGPタグをサイト情報から動的に生成し、シェア時の表記を統一する

商品ページや特集記事がSNSでシェアされたとき、OGPのog:site_nameやtwitter:siteが正しく設定されていないと、シェアカードに意図しないサイト名が表示されたり、無表示になったりします。get_bloginfo()でサイト名やURLを動的に取得し、全ページ共通のOGPテンプレートに流し込むことで、どのページがシェアされても同じブランド表記が保たれます。

  • og:site_nameをget_bloginfo(‘name’)から動的生成する
  • og:urlの起点をget_bloginfo(‘url’)またはhome_url()に統一する
  • ページ固有のog:titleとサイト全体のog:site_nameを役割分担させる

構造化データのOrganization情報を一元管理する

検索結果でのリッチ表示やナレッジパネル対応を狙う場合、Organizationスキーマの name、url、logo をサイト情報から一元的に取得して出力すると、ページごとの表記ゆれを防げます。会社名変更やドメイン移行があった際も、管理画面の設定を1か所変更するだけで全ページに反映される設計にしておくと、修正漏れのリスクを大きく減らせます。

$org_schema = array(
    '@context' => 'https://schema.org',
    '@type'    => 'Organization',
    'name'     => get_bloginfo( 'name' ),
    'url'      => get_bloginfo( 'url' ),
);

複数店舗・複数カテゴリページのメタタイトルにブランド名を安全に付加する

「商品名|サイト名」のようにメタタイトルの末尾にサイト名を付加する実装は多くのサイトで採用されていますが、サイト名をハードコーディングしていると、ブランド名を変更したりリブランディングしたりする際に、全テンプレートを洗い出して修正する必要が出てきます。get_bloginfo(‘name’)を使ってサイト名を動的に埋め込んでおけば、管理画面での変更だけで全ページに反映できます。

問い合わせフォームや自動返信メールの差出人情報を一元化する

お問い合わせフォームの自動返信メールや、システムからの通知メールに管理者メールアドレスやサイト名を記載する場合も、bloginfo(‘admin_email’)やget_bloginfo(‘name’)を使って動的に取得しておくと、担当者変更時の修正漏れを防げます。

多言語・越境EC展開時の表記統一

越境ECや多言語対応を進める小売事業者では、言語ごとにサイト名の表記を出し分けたいケースがあります。bloginfo(‘language’)でサイトの言語設定を取得しつつ、多言語プラグインと組み合わせて言語別のサイト名管理を行うことで、どの言語のページを見ても一貫したブランド体験を提供できます。

実装・運用の進め方

  • 現状のテーマファイル・プラグイン設定内で、サイト名やURLがハードコーディングされている箇所を洗い出す
  • OGPタグ、構造化データ、フッター表記、メール文面など、サイト情報が使われている全箇所を棚卸しする
  • bloginfo() / get_bloginfo() を使った動的取得に置き換える
  • WordPress管理画面の「設定」>「一般」に登録されているサイトタイトル・キャッチフレーズ・管理者メールアドレスの内容を、実際のブランド表記と照合する
  • 置き換え後、OGPデバッガーや構造化データテストツールで表示崩れがないか確認する

よくある失敗と回避策

  • サイト名やURLをテンプレートに直書きしている:get_bloginfo()による動的取得に統一する
  • siteurl・homeなど非推奨の引数を使い続けている:home_url()やsite_url()など推奨関数に置き換える
  • OGPと構造化データでサイト名の取得元が別々になっている:どちらもget_bloginfo(‘name’)など単一のソースから取得する設計にする
  • 管理画面のキャッチフレーズが初期設定のまま放置されている:ブランドの価値提案を反映した文言に更新する
  • マルチサイトでbloginfo(‘url’)を使い、意図しないブログのURLが出力される:get_site_url()やhome_url()など文脈に応じた関数を使い分ける

社内で持つべき判断軸

  • サイト名・ブランド表記が全ページで一貫しているか、定期的に確認する体制があるか
  • リブランディングやドメイン移行が発生した際、影響範囲を即座に把握できる実装になっているか
  • OGP・構造化データの整合性を、SEO担当者だけでなく制作担当者も理解しているか

成果測定で見るべき指標

  • SNSシェア時のOGP表示崩れの件数
  • 検索結果でのサイト名表示の一貫性(Google Search Consoleでの確認)
  • 構造化データテストツールでのエラー・警告件数
  • ブランド名検索(指名検索)からの流入数の推移
  • サイト名変更・ドメイン移行時の修正対応にかかった工数

運用イメージ(仮想パターンで理解する)

例えば、雑貨小売の企業が「株式会社◯◯」から「◯◯ストア」へブランド名を変更したと仮定します。サイト名がテンプレートに直書きされていた場合、OGPタグ、構造化データ、フッター、メールテンプレートなど、あらゆる箇所を個別に洗い出して修正する必要があり、修正漏れによって旧ブランド名が一部のページに残ってしまうリスクがあります。

一方、get_bloginfo()で一元的にサイト名を取得する設計になっていれば、管理画面の設定変更だけで大部分のページに新しいブランド名が反映されます。これはあくまで仮想的な例ですが、「変更が発生したときに、どこまでの修正で済むか」という観点は、サイト設計の初期段階で検討しておく価値があります。

よくある質問

bloginfo()とget_bloginfo()はどう使い分ければよいですか

その場でそのまま出力してよい場合はbloginfo()、値を組み立てたり条件分岐に使ったりする場合はget_bloginfo()を使います。OGPタグや構造化データの生成にはget_bloginfo()が適しています。

サイトURLを移行する予定がなくても対応しておくべきですか

はい。将来のドメイン移行やリブランディングの予定がなくても、ハードコーディングを避けておくことで、不測の変更にも柔軟に対応できます。保守性の観点から早めの対応をおすすめします。

マルチサイトでbloginfo(‘url’)を使うと何が起きますか

現在処理中のブログのURLが返りますが、文脈によっては意図しない挙動になる場合があります。マルチサイト環境ではhome_url()やget_site_url()など、目的に応じた関数を使い分けることが推奨されます。

OGPプラグインを使っていればbloginfo()を意識する必要はありませんか

OGP生成をプラグインに任せている場合でも、プラグインの設定項目がサイト情報と正しく連動しているかは確認が必要です。プラグインの初期設定のまま放置されていて、サイト名が反映されていないケースも見られます。

構造化データはプラグインとbloginfo()どちらで実装すべきですか

SEOプラグインの構造化データ機能を使う場合でも、そのプラグインがサイト情報をどこから取得しているかを理解しておく必要があります。プラグインの設定とWordPress本体のサイト情報がずれていないか、定期的に確認することが重要です。

キャッチフレーズは検索結果に表示されますか

キャッチフレーズ自体が直接検索結果に表示されるとは限りませんが、テーマやOGPの実装によっては説明文として利用される場合があります。ブランドの価値提案が伝わる文言にしておくことをおすすめします。

EC制作・EC広告の相談先を探している小売事業者の方へ

bloginfo()の使い方を知るだけでは、サイト全体のメタ情報設計は完成しません。OGP・構造化データ・パンくず・メタタイトルの整合まで含めて、ブランドの一貫性とSEO評価を両立させる設計が必要です。特に商品数の多い小売ECでは、テンプレート単位での実装ミスが数百ページ規模で影響することもあります。

サイト情報の整理、OGP・構造化データの実装、広告配信先とのメタ情報整合まで、まとめて見直したい場合は、要件整理の段階から相談できる体制を持っておくと、修正漏れによる機会損失を防ぎやすくなります。

まとめ

bloginfo()は、サイト名やURLなどの基本情報を出力するためのシンプルな関数ですが、これを軸にOGPや構造化データを一元管理する設計にしておくことで、小売ECサイトのブランド表記の一貫性とSEOの安定性を両立できます。

ハードコーディングによる表記ズレは、蓄積すると修正コストが膨らみます。サイト情報を一元管理する設計は、早い段階で取り組むほど効果が大きくなります。

コメント

タイトルとURLをコピーしました