OGPは画像だけを決めずtitle、URL、説明を公開pageと同じ内容にそろえる

OGPを設定するときは、共有用の画像だけを作って終わりにしません。og:title、og:type、og:image、og:urlを、利用者が実際に開くpageの内容とそろえます。共有画面で目を引くことより、クリックした人が期待したpageへ着き、題名と説明が食い違わないことを優先します。

記事を共有したときに会社siteの共通画像だけが出たり、古いtitleが表示されたり、top pageのURLにまとまったりすると、何を読むlinkなのか分かりにくくなります。OGPは検索順位を上げるための設定ではありません。外部serviceがpageを共有用のobjectとして扱うために読むmetadataです。画像、説明、URLのどれか一つだけを整えても、link先の内容が違えば利用者の期待を外します。

Open Graph Protocolの基本仕様は、og:title、og:type、og:image、og:urlを基本metadataとして挙げています。og:urlはshared objectのpermanent IDとして使うcanonical URLです。HTMLのheadへmetadataを置き、共有するpageごとにそのpageを表す値を出します。共通templateで設定する場合も、個別pageのtitleやURLを取り違えないようにします。

共有画面とlink先のpageは同じ約束を伝える

利用者は共有画面のtitle、説明、画像から、link先で何が読めるかを予想します。共有画面で「料金を説明するpage」と見せて、link先が会社のtop pageなら、利用者は目的の情報へ着けません。逆に、link先は料金pageなのに、共有画面が共通の会社紹介だけを示せば、pageを読む理由が伝わりません。

説明用の仮例として、WordPressで「問い合わせformの必須項目」を説明する記事を公開するとします。og:titleは記事の題名、og:urlはその記事の正規URL、og:imageはformや入力を連想できる画像、og:descriptionは記事で説明する範囲を短く示す文章にします。会社siteのlogoだけを全記事へ出すことが悪いわけではありませんが、個別記事の主題を伝える目的には弱くなります。

一方、会社のtop page、about page、privacy policyのように、個別の共有画像を毎回作る必要がないpageもあります。この場合は共通画像を使って構いません。ただし、top pageのog:titleと記事のog:titleまで同じにしてはいけません。共通にするものと個別に出すものを分けると、templateを保ちながらpageの意味を保てます。

og:urlは表示中のURLではなく正規URLを出す

同じcontentが複数のURLで開けるsiteでは、OGPのURLにどれを出すかを先に決めます。HTTPとHTTPS、wwwの有無、末尾slash、parameter付きのURL、print用pageなどが混在すると、同じ記事が別々のobjectとして扱われることがあります。og:urlには、利用者へ案内する代表URLを出します。

たとえば、広告やmail newsletterから?source=mailのようなparameter付きURLへ来る場合、OGPまでそのparameterを含むURLにすると、同じ記事の共有情報が分かれる理由になります。どのparameterを残すかは計測の設計によって違いますが、共有用のobjectを何で一つと数えるかは、計測用のURLとは別に決めます。canonical URL、redirect、internal link、OGPのURLを同じ代表URLへ寄せると、読む人と運用する人の両方が迷いにくくなります。

URLを正規化することと、古いURLを消すことは別です。すでに外部からlinkされたURLやbookmarkされたURLがあるなら、必要に応じて対応する新URLへredirectします。OGPへ新URLを書いただけでは、旧URLを開いた利用者が正しいpageへ移るとは限りません。metadataの整理、redirect、internal linkを同じ目的で確認します。

画像は見栄えよりpageを表すものを選ぶ

og:imageは、共有画面でlinkを見分ける手掛かりになります。文字を多く詰め込んだ画像や、どの記事でも同じstock photoを使うより、pageの内容を見分けられる画像の方が、題名と一緒に読んだとき意味を持ちます。記事用画像に文字を入れる場合も、画像だけを見なければ内容が分からない設計にはしません。titleとdescriptionで主題を読める状態にします。

画像のURLは、外部serviceが取得できる公開URLにします。管理画面だけで見えるpath、loginが必要な画像、公開前のtest domain、期限付きのURLを指定すると、共有時に画像を読めない場合があります。画像を差し替えたあとも、公開pageをログアウトしたbrowserで開き、title、description、画像URLが外から取得できるかを確認します。

WordPressのfeatured imageをOGPへ使う場合は、featured imageを設定しない記事の扱いも決めます。画像がないときに共通画像を出すのか、記事の種類ごとに画像を用意するのか、どのtemplateが値を出すのかを決めます。投稿画面でimageを選ぶ作業と、themeがog:imageへ正しいURLを出す作業を同じものとして扱いません。

OGPを構造化dataや広告文の代わりにしない

OGPは共有したlinkを表すmetadataです。検索結果に出すtitleやdescription、schema.orgの構造化data、広告の見出しと、目的も読む相手も同じではありません。同じ文章を使える場合はありますが、片方を変更したら他方も必ず正しいとは限りません。

たとえば、広告では期間限定の案内を強調し、OGPでは記事の恒久的な主題を示したい場合があります。schema.orgでは事実関係を機械へ伝え、OGPでは共有画面でlink先の内容を表します。dataを別々に手入力すると、title、URL、画像の修正が片方だけに残りやすくなります。可能なら、page title、canonical URL、featured imageのように共通にできる元dataを決め、templateが必要なmetadataへ出すようにします。

ただし、一つの元dataから出すことは、全ての表示文を同じにすることではありません。記事本文のtitle、HTMLのtitle、meta description、OGP description、広告文には、文字数や読み手の違いがあります。どこまで同じにし、どこから個別に書くかを決め、編集したpageで実際のHTMLを確認します。自動出力に任せたまま、全記事がtop pageのURLや共通descriptionになっていないかを確認します。

公開前には、article page、固定page、画像なしの記事、parameter付きURL、redirect元のURLを一つずつ開きます。HTMLのheadに出たog:title、og:url、og:image、og:descriptionを読み、画面のtitle、本文、canonical URLと比べます。外部serviceの共有画面が即時に新しい情報を読むかはserviceごとに違うため、まず自社のHTMLと公開URLが正しいことを確認します。

最初の一手は、最近公開した記事を一つ選び、画面の題名、canonical URL、featured image、HTMLのog:title、og:url、og:imageを並べることです。同じ記事を指していなければ、画像の大きさより先に元dataとtemplateを直します。