SNS share buttonは記事の末尾へ置く前に共有したいURLと外部scriptの管理を決める

SNS share buttonは、記事の末尾へ何種類も並べる前に、読者がどのURLを誰へ共有するのかを決めます。buttonを置いただけでは、記事のtitle、画像、説明、URLが共有先で正しく伝わるとは限りません。共有してほしいpageが一つに定まり、link先の情報が現在の内容とそろってから、必要なbuttonだけを置きます。

share buttonは読者が外部serviceへ進む入口です。記事を読むためのlink、問い合わせへ進むlink、page内の操作とは役割が違います。buttonの見た目を増やすことより、共有したあとに何が見えるか、外部scriptを誰が管理するか、何を計測するかを分けます。共有数が多いことを、記事の価値や問い合わせの成果と同じに扱いません。

共有してほしいpageを先に決める

share buttonを置くpageは、読者がほかの人へ渡す理由がある内容に限ります。問題の解決方法を説明した記事、eventの案内、利用者が確認するべき更新情報のように、URLだけで内容が伝わるpageなら、共有の入口を置く意味があります。一方で、問い合わせ完了page、個別の見積もりpage、検索結果page、管理画面のように、第三者へ渡す理由がないpageまで同じbuttonを出す必要はありません。

説明用の仮例として、事業者が夏季休業のお知らせを公開する場合を考えます。取引先や利用者へ共有してほしいなら、休業日、連絡の扱い、再開日を一つの公開URLで読めるようにします。top pageの一部にだけ書き、別の更新で消える状態なら、share buttonを押しても後から同じ案内を確認できません。共有するURLと、案内を残す場所を同じ判断で決めます。

記事pageへbuttonを置く場合も、一覧pageやcategory pageのURLを共有させるのではなく、その記事の正規URLを使います。同じ内容へ複数URLから開けるなら、どれを共有の正本にするかを先に決めます。URLが分かれていると、読者が同じ記事を別々に共有し、更新の案内や計測も分かれます。buttonを作る仕事と、URLをそろえる仕事を切り離しません。

OGPはbuttonの外側で共有内容を決める

SNS上で見えるtitle、説明、画像は、button自体の文言では決まりません。共有されるpageのheadに置く情報と、page本文の内容が関わります。記事のtitleを変えた、画像を差し替えた、URLを移したときは、share buttonが残っているかだけでなく、共有先へ出す情報と本文が同じ内容かを確認します。

たとえば、記事の冒頭を価格改定の案内へ直したのに、共有用の説明が古いサービス内容のままなら、読者は違う期待でpageを開きます。画像だけを新しくしても、titleとURLが前の企画を示していれば、共有された情報は揃いません。buttonを置く前に、何を共有した人へ伝えたいのかをpage側で決めます。

外部serviceごとに表示の形が違うこともあります。すべての画面で同じ見た目になることを約束せず、公開pageのtitle、description、画像、URLに矛盾がないことを先に確認します。共有先の表示を追いかけて本文を変えるより、記事の正本を読者が理解できる形に整えます。OGPは装飾ではなく、pageの案内を外へ渡すための情報です。

外部scriptを入れるなら管理する人と更新を残す

share buttonには、HTMLのlinkだけで置けるものと、外部のscriptを読み込むものがあります。外部scriptを入れると、buttonの見た目や共有用の処理を提供できますが、読み込むURL、version、表示、page速度、外部serviceの変更を確認する仕事も増えます。便利そうなbuttonを一度に増やさず、必要なserviceだけを選びます。

scriptをthemeへ入れる場合は、どのfileへ置いたか、誰が更新するか、外したいときにどこを直すかを記録します。広告や解析のscriptと同じ場所へ無計画に加えると、ページが重くなった、表示が崩れた、外部serviceの仕様が変わったときに原因を探しにくくなります。外部から読み込むものと、自分のsiteに置く本文を同じ管理にしません。

share buttonをpluginで入れる場合も、pluginを有効にしただけで完了ではありません。記事page、固定page、mobile画面を開き、buttonが本文を隠していないか、意図しないpageへ出ていないかを見ます。外部serviceとの連携を制作会社へ頼むなら、accountの名義、scriptの変更、停止時の対応を会社側で確認できるようにします。buttonの設置を委託しても、siteへ何を読み込むかの責任まで渡しません。

計測するなら共有数と読者の行動を分ける

share buttonが押された回数を計測すると、どの記事が共有の入口として使われたかを確認できます。しかし、その回数は共有先で読まれた回数でも、問い合わせになった回数でもありません。buttonを押した人が自分の画面で共有をやめる場合もあります。計測した数字の名前と、判断したい結果を同じにしません。

仮に、ある記事のshare buttonがよく押された場合は、まず記事のtopic、共有したURL、buttonの場所、期間を確認します。記事末尾に置いたbuttonと、固定headerに置いたbuttonを同じeventとして数えれば、どこが使われたか分かりません。buttonを増やす前に、何を一件として記録し、どのpageからの操作を見たいかを決めます。

共有が増えても、読者が次に必要なpageへ進めないなら、buttonの数を増やす理由にはなりません。記事内の関連link、問い合わせへの入口、公開した案内の更新を先に確認します。share buttonは読者が外へ渡すための補助です。site内の説明や連絡先が不足している問題を、共有によって埋めることはできません。

最初の一手は、share buttonを置いているpageを三つ選び、「共有する正規URL」「共有先で伝えるtitleと画像」「外部scriptの有無」「計測する目的」を書くことです。第三者へ渡す理由がないpageのbuttonは外し、必要な記事だけに残します。buttonの数ではなく、共有した人と受け取った人が同じpageを読める状態を優先します。