解決したい問題

Facebook でシェアボタンを押したときに表示されるプレビュー、または実際にフィード上の表示がなんかイメージと違う、という問題に対してチェックすべきことを解説します。

例えばタイトル部分を変えたいとか、画像を変えたいとか、そもそも関係ないページが表示されてしまっている、といったときにどうすべきか。

(画像ははてなブログ開発ブログの適当なエントリのものです)

確認すべきポイント

シェア対象の URL は正しいか
シェア対象の URL は Facebook のクローラからアクセスできるか
シェア対象のページの Open Graph Protocol の meta タグはちゃんと設定できているか
Facebook クローラが保持しているキャッシュは古くないか

シェア対象の URL は正しいか

そもそも間違った URL をシェアしようとしてしまっていないでしょうか。

シェア用の画面を開いた状態でアドレスバーを確認してください。
以下のような URL になっていると思います。
https://www.facebook.com/sharer/sharer.php?app_id=113869198637480&sdk=joey&u=https%3A%2F%2Fdevelopers.facebook.com%2Fdocs%2Fplugins%2F&display=popup&ref=plugin

このときシェア対象となっている URL は u=*** の部分です。

https%3A%2F%2Fdevelopers.facebook.com%2Fdocs%2Fplugins%2F
↓ (URL デコード¹)
https://developers.facebook.com/docs/plugins/

これで得られた URL が間違っているなら、それをなおしましょう。

そもそも Facebook 公式のツールで HTML タグを生成していれば、こういったミスは起こりにくいかもしれません。

Share Button

シェア対象の URL は Facebook のクローラからアクセスできるか

ページの情報を取得するために、Facebook クローラがシェア対象の URL にアクセスしに来ます。
ここで Facebook クローラが何らかの理由でアクセスできなければ、当然ページ情報は取得できません。

ありがちなのは、企業内の開発環境等での確認段階で、開発環境には IP 制限や BASIC 認証がかかっていて、外部からのアクセスを弾いてたりすることです。

以下のページで確認ができます。

Debugger

Facebook が公式に提供するデバッグツールです。
対象の URL を入力して Debug ボタンを押すと、Facebook クローラからページがどう見えているか、を確認することができます。
ボタンを押したらページ下部の「See exactly what our scraper sees for your URL」というリンクを開いてみましょう。
Facebook のクローラが対象の URL にアクセスして、どのような HTML を取得したのかが確認できます。

ここで「Document returned no data」と表示されていれば、アクセス制限等の理由によりクローラが弾かれていることになります。
もしくはリダイレクトにより、全く違うページを取得していることもあるかもしれません。

以下の対策を取り得るでしょう。

推奨: アクセス制限のかかってない URL (例えば本番環境) で試す
非推奨: Facebook クローラにのみアクセス制限を行わないように設定する
あきらめる

本番環境で試せるならそれが一番良いでしょう。
ただ、解禁前情報を含むページなど、それをやるべきでない理由があることもあるでしょう。

Facebook クローラだけ制限を解除することは、やろうと思えばできますが、クローラの判定をどうやるかが問題です。
IP は変わるかもしれないし、User-Agent だと偽装による悪用の可能性もあるでしょう。

テスト段階での確認を行うのが難しそうなら、リリース後にぶっつけ本番でやるしかないこともあるでしょう。

シェア対象のページの Open Graph Protocol の meta タグはちゃんと設定できているか

前の項目の確認で、クローラ的になんとなく HTML の取得はできていたとしましょう。

だとすると、次に問題になるのは HTML 中にひつような情報をきちんと持たせられているか、です。
正しく情報を表示するには、Open Graph Protocol と言われる仕様に基づく meta タグを設定する必要があります。

Open Graph Protocol (OGP) というのは、ざっくり言えばページの属性情報 (タイトルとか、説明文とか、サムネイル画像とか) を記述するためのルールです。

これも前の項目同様、公式の Debugger から確認することができます。
URL を入力して、以下のようなエラーメッセージが出ていれば修正したほうが良いかもしれません。

この場合は、og:title と og:url が設定されてないから適当に推測しといたよ、という者で、推測結果に問題がなさそうであれば、まぁいいのかもしれません。
設定値に問題があったときは具体的な問題点や、関連する情報へのリンクを示してくれたりと割と新設なので、英語でも頑張って理解しましょう。

HTML レベルで確認するときは、前の項目と同様、ページ下部の「See exactly what our scraper sees for your URL」というリンクを開いてみましょう。

Facebook クローラが保持しているキャッシュは古くないか

これが一番ハマりがちな問題かもしれません。
正しく OGP の記述を行っているはずなのに、Facebook のクローラからは全く違う情報が見えているようだ、という場合です。
クローラはページへのリクエスト結果をキャッシュするので、場合によっては古いデータが残り続けていることもあります。

この問題については、解決は簡単です。
これもやはり Debugger に URL を入力して Debug ボタンを押します。
次の画面で以下のようなボタンが 2 つ表示されています。

このうち、「Show existing scrape information」だとキャッシュからの結果を取得するだけです。
最初の画面で Debug ボタンを押した時も、これと同じ挙動のようです。

もう一方の「Fetch new scrape information」というボタンを押すと、キャッシュがあってもそれを無視して、新たにページ情報を取得しに来ます。
このタイミングで、シェア時のプレビュー時に使用するキャッシュも一緒にクリアされる²ようで、この時点で問題が解決しているかもしれません。

もしかしたら、最新の状態でも OGP の記述に問題があるかもしれないので、そのときは再び「シェア対象のページの Open Graph Protocol の meta タグはちゃんと設定できているか」を確認しましょう。

リダイレクトに注意

「シェア対象の URL は正しいか」の細かい話として、リダイレクトに注意が必要です。

例えば、シャア対象の URL に以下を指定していたとします。
http://example.com/articles
ですが、実際にアクセスしたときは以下のように末尾にスラッシュが入ってリダイレクトされるような場合です。
http://example.com/articles/

このとき、Facebook 上のキャッシュはそれぞれの URL で別々に管理されているようです。
例えばシェア用の URL が http://example.com/articles なのに、http://example.com/articles/ に対してキャッシュのクリアを行っても、キャッシュが反映されないように見えてハマることになります。

もう一度、一番最初の「シェア対象の URL は正しいか」をチェックすると問題に気づくかもしれません。

ツール等で URL デコードすることもできます http://tech-unlimited.com/urlencode.html ↩
というより同一のキャッシュを参照しているんだと思いますが ↩