HAIKではソーシャル系のボタンを"#share_buttons"で書けますが、ここの中でfacebook
用のボタンの働きに疑問。

このプラグインで得られるfacebook用ボタンをクリックするとfacebookへのシェアにな
りますが、問題はそこで得られる画像。

一般的にはシェアするページの冒頭画像（アイキャッチを除く）が得られるのですが、
HAIKのそれはどうしてもロゴ画像が貼り付いてしまいます。そしてfacebookページの方
ではロゴ画像がおマヌケに拡大されて表示。（全ページそうなるから情けなや）

何か回避策はないものでしょうか？
まんまじゃ使う気になれません。というか、仕様のミスでしょうか。

Google+のボタンはうまく作動しているのにねえ。

ちなみに"#fb_likebutton(*オプション*)"で表示されるシェアボタンは正常。

追記：

別のサイトを見ると件のボタンで正常のページもあればダメなページもあり。
条件がわからない。

追記2
もしかすると、facebook側に問題がある気も。

編集

続き

HAIKの画像OGタグ書き出しでは、本文内画像が深い#colsに書かれているときは
読まれにくいことを書いた。

しかしここで、どうしても#colsを使わざるを得ない場面について説明しておきま
す。

例えば、ページのレイアウトとして「メニューなし」「フルページ」などを使って
いる場合、左右余白を調整するためには#colsは必須と言える。

最初の#colsが本文の本体である。これで左右余白が決定される。

そしてその#colsの内部に、左右の段組として更に#colsがあり、そこに初めて本文
用の画像がある・・・こんなのは当たり前にあり得る#colsの使い方だと思う。

しかし、HAIKは#colsが深いと画像をOGPとして読んでくれないんですよねー。

で、この場合はアイキャッチがあればそれが取り上げられて画像OGタグとなる。

本文が更新され、それに伴って本文の冒頭にある画像も更新されても、シェアされ
る画像はいつもアイキャッチとなる。

ま、妥協するしかないか・・・

しかし、これまでに書いたことが100%再現というわけでなく、ことによっては例
外が発生するのがやってられない。

ちなみに、WordPressにある有名なプラグイン「All in one SEO」では、デフォに
設定されているOGP書き出しに加え、書き出されるOGPタグをページごとに自由に
編集可能である。これは完璧だ！

編集

HAIKの画像OGタグの書き出し、これまでに観察されたこと。

（あくまで個人的観察。本来は仕様が知りたい。）

HAIKはそのページに対して冒頭部分から画像の有無をスキャンしている様子。

以下のような順番となるようだ。

「ロゴ画像→アイキャッチ→本文内の冒頭画像」

スキャンの結果、最後にヒットした画像が《原則的に》画像OGタグとなる。

例えば、「ロゴ有り、アイキャッチ有り、本文内の冒頭画像有り」のページであれ
ば、最後にヒットする本文内の冒頭画像が画像OGタグとして生成される。
（原則的にです）

ちなみに、ロゴしかなければロゴを、アイキャッチしかなければアイキャッチが画
像OGタグとなる。

《しかし例外がある》

「ロゴ、アイキャッチ、本文内の冒頭」の三点セットのページでも「本文内の冒
頭」が読まれず、アイキャッチが生きて画像OGタグとなることがある。
（↑これ、私にとって大迷惑）

これは、その本文内の冒頭画像が深い#colsの中に書かれているとき。

HAIKは知ってか知らずか、ネストが深めな#colsにある画像を読みにくい。
（必ず読まないとは限らないからややこしい）

今までの実証実験では、全く#colsを使わずに書いたページで本文内の冒頭画像が
拾われなかった例はない。

続く

編集

私も今回の件で，記事を書いたらすぐにFBのシェアデバッガーで画像を一度表示させておく対策をすることにしました。
昨日は既存の記事についてその確認作業をやりました。
そうしないとユーザーがシェアしようとしたときにうまくいかない可能性が大きいですね。

編集

おお、うみほしさん。なんとかなりげで良かったです。

私も今回のOGPの疑問で勉強する羽目になり、いやHAIKとfacebookは
あまり相性がよくないかもなあ、という気分。

どちらも論理的には間違っていないかもしれないけれど、現実にそれら
のデータを受け渡そうとするとうまく行かないという感じ。

ところで、私がなぜここまでシェアの結果にこだわるのかと言えば、純
粋にビジネス上のこと。

まずは自己宣伝として、新サービス、新製品などの紹介としてシェアし
ようとしたとき、あらぬ画像や本文要約が出てきたのでは効果半減。

（ことによってはマイナス評価）

また、顧客や潜在顧客がシェアしようとしたときも同様、それに加えて
UX（ユーザーエックスペリエンス）としてもマイナスと思います。

「サイトの機能が正常に働いていること」これは信頼性そのものを意味
していると思います。

と言っても、私自身がここの部分でテストをおろそかにして今日まで来
たということが言えます。たまたまうまく行ったシェアしか見ていない
と不具合はわかりません。

そして不具合を見たユーザーがそれをわざわざ教えてくれたりはしませ
んから。

しっかり仕事をしようと思います。

編集

謎が解けました。
その他のタグにog:urlが設定されていたためでした。
キャッシュがおかしい記事の日付から今年の4月頃からそうなっていた様子。何で書いたのかもう忘れましたが，消したら正常化しました。

ただ誤ったリンクがキャッシュされているので，それをデバッグで再取得するのが手間です。地道に作業して修正中。
いいねのカウントも正常に。
ただ取得される画像はYujiroさんの指摘通り，うまくいかないことがあります。何度も読み込ませてみてますが，やり過ぎるとロックされてしばらく更新できなくなりました。
　少しずつやるしかないようです。
やはりGoogle＋のシェアの方が画像が選べるので優れてます。

Yujiroさんが問題を取り上げてくれたおかげでFBシェアのエラーを発見できました。ありがとうございました。

編集

うみほしさん

謎なんですが、index.phpの有り/無しなど、何かまるで.htaccessの記述
がからんでいそうな。

編集

見ていただきありがとうございます。

エラーメッセージでは，

＞修正する必要があるエラー
複数のOG URLが指定されています 「https://umihoshi.com」の「website」タイプのオブジェクトは複数のOG URLを指定しているため無効なものです: https://umihoshi.com, https://umihoshi.com/index.php

となっていて，index.phpの有り無しが複数指定となっています。
これが原因？どちらでもアクセスできるのは元々からのはずなのですが，片方に統一しろということかな？

編集

うみほしさん

うみほしさんのページを拝見させていただました。

参考として「日食とオーロラ」のページをシェアデバッガに通して見たところ、
canonicalにフロントページが指定されている結果に見えます。
（少なくともfacebookはそう読んでいます）

これが事実なら「日食とオーロラ」のページはフロントページに同じという
意味でfacebookに伝わっていませんか？

それから更にオブジェクトデバッガを通すと更にちょっと複雑そうなエラー表示が。

他のページもどうやらすべてcanonicalがフロントページ指定と読まれているようです。

でもページの内容そのものはそんなcanonicalは書かれていない・・・謎。

何かの指定が・・・コンフリクトを起こしている感じ。

私の方の手持ちサイト3件ほどではこれは起こりません。何か複雑に絡んでいるような・・

編集

結局のところFacebookでHAIKの記事のシェアは使いものになりません。私のサイトではどのページでシェアしてもフロントページになっちゃいます。

Google＋は問題なくどの記事でもシェアできています。

編集

さらなる調査結果

【facebook】

HAIKが望ましいOGPタグ（画像の）を吐いたとしても、それを素直に受け取らないことが
ある。

素直に受け取ったとしても、スクレイピング結果として反映しにくい側面もある。
このことはfacebookにある「Open Graphオブジェクトデバッガー」によって観測された。
https://developers.facebook.com/tools/debug/og/object

【Google+】

こちらは各ページにあるOGPタグを鵜呑みにしていない様子。Google独自にページ内容を
解析し、その結果をシェアの表示に使っている。常識的なページ構成であればほぼ100%
の確率でライターが望むであろう状態にシェアされる。特に、OGPがないページでもそこ
そこに表示可能になるのは流石。

編集

総合追記

作りかけのページがあり、そこでシェアボタンの機能を試したときなど、そのときのUR
LとOGPデータがfacebook側にキャッシュされてしまう。
（OGPなしの場合もあり得る）

すると、ページ完成後も先にキャッシュされたデータが生きたままでいるので思いもよ
らないシェア用表示になる。（これが私のハマったところのよう）
（ことによってはサイトオープン後も「閉鎖中」表示だったり）

例えばロゴ画像のみの状態でシェアボタンを試したらそれがキャッシュされ、後から本
文中に画像を貼ってもそれがfacebookの方には反映されないということがある。

後からアイキャッチ画像を設定したとか、そんな場合も同じ。

このようなときにはfacebookのシェアデバッガーへ行き
https://developers.facebook.com/tools/debug/sharing/

データを上げ直すと改善が見られる。

あとはHAIKの気分次第。

というのは、やっとこさ本文中にある画像がシェアされるケースがあるが、なぜか二番目
以降の画像だったりする。

選択基準が不明だーー！ある確率で不定なんだなーーー

編集

わかったこと（その8）

▼facebookのシェアデバッガー
https://developers.facebook.com/tools/debug/sharing/

ここにアクセスしておかしなシェアをされるページのURLを入れる。

出てきた結果がシェア時に表示される内容である。

これを見て気に入らなければ「前回のURLスクレイピングの日時と方法」欄にある「もう
一度スクレイピング」ボタンを押す。

何度かボタン押下で望む状態の物が出たら成功！

そうでなかったら、HAIKの機嫌が悪いかセッティングにミスがないか確認。

同じ条件で書いているページが様々な結果を生むから本当に不思議で手に負えない。

が、これで望む状況に近ずくと思う。

今のところ、結論としてはHAIKが書き出すOGPタグの内、画像データのURLだけがなぜ
か不安定に思えてならない。

これとfacebookのキャッシュが相まってややこしい表示を生むようだ。

以上、報告。

編集

わかったこと（その7）

さて、今度はfacebook側のことを・・・

facebookはあるページでシェアボタンが押されたら、とりあえずHAIKが書き出したOGPタ
グを素直に読み込む。（読み込もうとする）

しかしどうも、HAIKとfacebookの双方で処理にごたつくことはありげ。

ただ最終的には、facebookはHAIKが書き出したタグを素直に読んで処理をしているよう
に見える。（たとえ思いもよらない画像がシェアされようと）

そして問題なのは、facebookが、あるページのURLとそのOGPデータを読み込むと、facebo
ok側でそれがキャッシュされる様子であることだ。

2回目に同じURLのページがリクエストされても新たに読み込まず、キャッシュのデータ
を使おうとするようだ。

これによって、HAIKページのライターが望みもしない状態のものがfacebookの方に溜ま
る。

しかしながら望みもしないデータを吐いているのはHAIKそのものの不思議な挙動である。

そこで少なくとも、facebook側のキャシュらしきものを一旦クリアする方策が望まれる。

それができそうなのが・・

「facebookのシェアデバッガー」

わかったこと（その8）へ

編集

わかったこと（その6）

私が怪しいと思っているのはこの部分・・・

同じページ構成なのに、なぜかOGPタグの画像URL優先順位がバラバラに見えて仕方ない。

うまく行っている中に、あるページだけコロッとおかしいというのが確かにある。

ページをロードするとき、同じページなのにOGPタグの画像URLが変わっていることがあ
る。

要するに不安定なのである。うまく行くときはうまく行く。がダメなときはダメ。

同じページでなんで吐き出すOGPタグが変わるかなあ？である。

正直、WordPressでもサイトを作っており、OGPをコントロールするプラグインなどを使っ
ているが、そちらでそんなトラブルはない。

そしてもうひとつ、HAIK側のOGP書き出し不安定さに加え、それを受けるfacebook側のこ
とについて書こう。

わかったこと（その7）へ

編集

わかったこと（その5）

ややこしい、HAIKのシェア用画像OGPタグ書き出し諸条件の続き。

ただし、アイキャッチと言ってもHAIKの場合は二通りある・・わけで・・

1）HAIKテーマ設定でONにしたアイキャッチ画像
2）上でON/OFFにかかわらず各ページに独自に書いたアイキャッチ

そして以下はOGPタグに入る画像の例・・の続き

例4）ページ本文にある最初の画像
これがあれば一般的にこれが使われることになる。（が、そうとばかりは限らないから困る）

以上の例1）〜例4）で、OGPタグに入る画像優先順位は一般的には逆順に例4）〜例1）と
なっているようだ。

が、2種類のアイキャッチなどの存在も交えて、この優先順位が実際にはケースバイケー
スで変わる。（ここがわからない点）

例えば「ロゴあり、どちらかのアイキャッチあり、本文に画像あり」のケースでは、普
通は「本文の画像」が多くの例ではOGPタグに書き出される。

しかしながら現実には上の例の構成をしたページで、なぜかロゴ画像のURLがタグに入っ
ていることがある。

わかったこと（その6）へ

編集

わかったこと（その4）

以下はOGPタグの画像データ書き出しとしてHAIK側にある諸条件。

1）ページに画像が全く含まれない
2）ロゴ画像だけある
3）ロゴ画像有り、HAIKのテーマ編集でアイキャッチONの場合
4）ロゴ画像有り、HAIKのテーマ編集でアイキャッチOFFだが各ページにアイキャッチ
5）ロゴなしで3）と4）の場合
6）上の1）〜5）でページ本文に画像が（いくつか）ある
etc

どうやら上の組み合わせの中で、HAIKはシェアに最適と判断された画像をOGPタグとして
書き出すようになっている。（らしい）

どの画像がタグとして選ばれているのかは、ページのソース、head内にある以下の行を
見るとわかる。

<meta property="og:image" content="画像データのURL" />

例1）「サイト画像」が入る
そのページにロゴ画像を含め全く画像がなければ、（その1）で設定した「サイト画像」
のURLが入る。（もしサイト画像の設定をしていない場合、何が出るか？試すと面白い）

例2）ロゴ画像が入る
そのページにロゴ画像が有り、他に何もなければロゴ画像のURL

例3）アイキャッチ画像が入る
ロゴの有無にかかわらず、アイキャッチの画像があればそのURLが入る。

ただし、アイキャッチと言ってもHAIKの場合は二通りある。

わかったこと（その5）へ

編集

わかったこと（その3）

・・・・実はここが怪しい・・・

【ソーシャル連携ONでHAIKがしていること】

ここをONにすると、HAIKは初めて「Open Graph Protocolタグ（略してOGPタグ）」をペー
ジのソースに書き出す。

「OGPタグ」とはそ、のページのシェアの操作などで、ページの情報をfacebookなどに受
け渡すためのデータを保持している。ページタイトル、本文の要約、画像などだ。

たとえば、シェアされるはずの画像なら以下のタグがページのソースに書き込まれてい
る。

<meta property="og:image" content="画像データのURL" />

この「OGPタグ」に書き出される内容は、基本的に「わかったこと（その1）」に書いた
セッティングそのものである。

しかし、シェアで使われる「画像データのURL」に関しては、HAIK側のページ構成諸条件
によって様々なケースが存在することがわかった。

わかったこと（その4）へ

編集

わかったこと（その2）

設定＞ソーシャル連携　の続き

《facebook連携》

ソーシャル連携の最下段にある「アプリID」と「管理アカウント」は空欄のままでもOK。
取得するのが面倒なら空欄でも問題なさげ。
（どちらかを入れるとどちらかが破棄される仕組みになっている）

ただし、どちらの設定も空欄のままだと、一応はfacebookのシェアデバッガー上ではそ
のことについてはエラー表示となる。（ただしシェアそのものは成立）

▼facebookのシェアデバッガー
https://developers.facebook.com/tools/debug/sharing/

もしもHAIKでソーシャル連携をONにしていないと、facebookでシェアした時にHAIKペー
ジ内のどの画像が使われるか確定しない率がさらにアップ。時にはロゴマーク、時には
アイキャッチ画像、時にはコンテンツ内部の画像など。

そして、このソーシャル連携に何か変更を加えたら、ページ最下部にある「設定する」
ボタンのクリックを忘れないこと。

わかったこと（その3）へ

編集

わかったこと（その1）

facebookのシェアで望ましい画像と要約を表示させる方法
（あくまで希望的）

【必須HAIK設定：ソーシャル連携をON】

設定＞ソーシャル連携＞Open Graph Protocol タグを有効にする

《サイトの説明》

ここは任意。空欄が妥当かも。シェアされた時に表示されるページの要約文として表示
される。

表示の優先順位

1)ここに入力した内容。
2）HAIK各ページに記入した#description(★)の内容
3）サイト情報の設定で書いた「説明」
4）上の1）〜3）に何も記入がない場合、各ページの冒頭文章が使われる。

《サイト画像》

ここにはとりあえず何か入れておくのが吉。

ただし、入力欄の説明にある「100px〜200px四方くらいの画像をご用意ください」は当
たらない。というのは、facebook側としては200px〜200px四方以下の画像はキャンセル
される。表示させたいなら200px〜200px四方以上の画像を用意。

何も入れない場合、HAIKの特質とfacebookの仕様が絡み、どの画像がシャアに使われる
か未確定要素となる。ときにはロゴ画像、ときにはアイキャッチ、そしてページ本文の
冒頭画像など、未確定になりげ。

わかったこと（その2）へ

編集

調査の結果、だんだんわかってきました。

完全とは言えませんがなんとかしのげる方法がありげ。
正直なところ、HAIKの機能に怪しいところあり。

これとfacebook側の「性質」が相まっておかしなことが起こる感じ。

追って解説していきます。ややこしいです。

編集

https://developers.facebook.com/docs/plugins/like-button
でいいねボタンのスクリプトを作成できるので，それでボタンを作ってみました。

HAIK標準の#fb_likebuttonと同じデザインのボタンが作れましたが，動作はやはり同じ。
作ったURLのページではなく，フロントページのシェアになってしまいました。
こうなるとFacebook自体の仕様が問題なのではという気がしてきました。Googleでは何の問題も無いのに...

編集

>ちなみに"#fb_likebutton(*オプション*)"で表示されるシェアボタンは正常。

私のサイトではどちらも同じ不具合です。フロントページのタイトル，画像，本文引用になってしまいます。

編集

自分のサイトで実験してみたところ動作が変です。

どのページをシェアしてもフロントページのシェアになってしまいました。
「いいね」のカウントもどのページも同じなって，おかしいなと思っていたのですが，どうやらどこにいいねしてもフロントページしか対象になっていないのではないかという疑惑。

HAIK-Teamに正式に不具合報告した方がいいかな。


Google対策でページの説明省いてますが，それのせいか？
なぜフロントページしかシェアされないのか？

Googleのシャアではそんなことは無く，該当ページがきちんとシェアされます。画像も本文引用ともそのページのものになっています。
Facebookのシェアボタンと，いいねボタンの動作がおかしいようですね。

編集

デバッガーで私のサイトをテストしたら、該当ページではなく表紙ページで使っている画像がプレビューされました。
私はロゴ画像を使っていないので、次点の画像になったのでしょう。

修正が必要な問題として指摘されていることは、

推測されるプロパティ
値が他のタグから推測される場合でも、og:imageプロパティは明示的に指定してください。
プロパティがありません
次のプロパティは必須です: og:type, og:title, og:image, og:description, fb:app_id

となってるのでこの辺が問題のようですが、どう対処したらいいかはわかりません。

編集

私のサイトに設置している、
#fb_likebutton(noface,noshare,layout=button_count)
のほうもカウントが正しいのか疑問符がついてます。

編集

自己レスです。

ああーー、どうやらこちら側のOpen Graph Protocolの設定あたりがまずい感じが。

調査続行。

facebookのシェアデバッガーなるページがある。
https://developers.facebook.com/tools/debug/

追記1
HAIK側のOpen Graph Protocolの設定など無関係のよう。原則的に不要な感じ。
（後からわかるが関係ありだった）

編集