Googleに強い土台を作るためのマニアックＳＥＯ対策

© INFINIX Inc.
Googleに強いCMSカスタマイズ
プライベートセミナー

3© INFINIX Inc.
META情報の最適化について

検索結果での見え方と重要性
© INFINIX Inc. 4
A) ページのタイトル情報は、検索結果で表示されるタイトルの
候補として利用されます。あなたのビジネスを簡潔でわかり
やすく説明するものにしましょう。
B) ドメイン名は Google の検索結果の重要な要素です。ウェブ
サイトには、わかりやすくて読みやすいドメイン名、URL を設
定しましょう。たとえば、
www.stasiasbakery.com/prodid?12345 といった数字の羅列
からなる URL ではなく、www.stasiasbakery.com/custom-
cakes といったわかりやすいものにしましょう。
C) メタデータ (descriptions) はページの概要を表すものであり、
検索エンジンの検索結果ページで頻繁に使用されます。
ページごとに、160 文字以下の固有の説明を設定しましょう。
※Googleガイドラインより
検索結果での見栄えを良くする
 Title : 有効文字数60文字。主要ページは30文字程度にする必要があります。
全ページタイトルが別で、上位表示を狙いたいキーワードを含み簡潔に表現している必要があります。
 Description : 有効文字数160文字。ページの説明を80～110文字程度で、出来るだけページ別の説明である必要が
あります。そのページ内コンテンツを裏付ける為のもので、ページコンテンツの概要を設置する事が好ましいです。
ページ内に無い概要がdescriptionにあると、検索エンジンは結果に表示する概要と相違していると判断し、ネガティ
ブな要素となってしまいます。
 Keywords : そのページで重要視するキーワードを4～8個程度に絞り設置する必要があります。多すぎず、少なすぎ
ず、そのページで一番強調したいキーワードを、Webサイト構造にあったキーワードにする必要があります。

Googleの検索結果レイアウトの変更
© INFINIX Inc. 5
検索結果の表示デザインの変更
2014年4月、Googleは文字を大きくして、下線を取り
除いたデザインに変更を行いました。
パソコン版では以前32～33文字程度のタイトルから、
30文字程度まで縮小されております。
Ｇｏｏｇｌｅには32文字は認識されておりますが、CSS
にて30文字での表示されております。
スマートフォンでは33文字表示されます。
訪問者の為のタイトル作りとして、30文字を超える
ページがある場合、見直しする必要があります。

6© INFINIX Inc.
robots.txtの必要性と記述方法
クローラー
について

robots.txtの役目
© INFINIX Inc. 7
robots.txtとは
不要なページに対し、クローラーのアクセスをブロックすることが出来ます。
クローラーが不要なページにはクロールされなくなる為、クロール・バジェット
(Crawl Budget)が無駄に消費されないようになります。
クロール・バジェットとは、クローラーに対してサイトごとに割り当てる、時間と
ページ数の事を指します。
つまり、不要ページへのクロールを許可してしまうと、本来最も読みに来てほし
いページをクロールする可能性を減らしてしまう事になります。
正しく設置する事で、クローラーを回す必要のあるページに、より多くのクロー
ラーが回るようになるためサイト全体のSEOが改善されます。
クロール(検索エンジンでの巡回)する際の基本指示
Googleでは以下の項目を、自動的に生成されたコンテンツとしてクロール頻度を抑える必要があると示しています。
 自動化されたツールで翻訳されたテキストが人間によるチェックや編集を経ず公開されたもの
 マルコフ連鎖などの自動化されたプロセスを通じて生成されたテキスト
 自動化された類義語生成や難読化の手法を使用して生成されたテキスト
 Atom/RSS フィードや検索結果からの無断複製によって生成されたテキスト
 複数のウェブページからのコンテンツに十分な付加価値を加えることなくそれらをつなぎ合わせたり組み合わせ
たりしたもの

robots.txtの記述方法
© INFINIX Inc. 8
前項での、自動的に生成されたコンテンツについて、「ユーザーにとって不要と感じるページをrobots.txtを
用いてクロールを防ぐ」という意味をもちます。
robots.txtの記述例
User-Agent: *
Disallow: /test/
Allow: /test/test.html
Sitemap: http://example.com/sitemap.xml
Sitemap: http://example.com/sitemaps/00.xml
Sitemap: http://example.com/sitemaps/01.xml
と、User-Agentでは特定のクローラーのUserAgentを指定し、それに対しての指示を行えますが、基
本ここを指定することはめったにない為、通常通りの User-Agent: *と、すべてのクローラーを指定し
ます。
次に、Disallowにて、クロールの必要の無いURLもしくは、ディレクトリを指定します。
主に、検索画面などpost以外でリンクとなっているページでは、大量の検索ページをクロールしてし
まう可能性がある為、対象の検索ページのディレクトリを拒否設定します。
間違っても Disallow: / と設定しないように気をつけてください。すべてのページをクローラーが読み
にいかなくなってしまいます。
拒否するページが無い場合は Disallow: のみで問題ありません。しかし、設定する事でよりコンテンツ
ページへのクロール頻度をあげる事が出来るため、ユーザーに不要なページは極力設置する事が
好ましいです。
Allowでは、Disallowよりも優先される為、万が一Disallowしたディレクトリ内に、クロールしてほしいコ
ンテンツが有る場合は、そのページを指定します。これにより、拒否されたディレクトリ内の特定の
ページをクロールしにくるため、コンテンツの評価をされないという事を防ぐことが出来ます。
最後に、SitemapにてそのWebサイトのSitemap.xmlを指定することが出来ます。
ここでは複数のsitemap.xmlを指定することが出来ます。
robots.txtの記述とそれぞれの意味について

クローラーの挙動について
© INFINIX Inc. 9
robots.txt
一番最初に読み込み、巡回が許可されているか確認をします。
この際、許可/不許可のディレクトリも確認します。
sitemap.xmlの記述があれば認識し、sitemap.xmlを読み込みます。
クローラー別に、UserAgentを指定してクロール頻度やクロール範囲などを制御する事
が出来、クロール最適化をする為に用います。
※bingのクローラーが頻繁に訪れ、トラフィックを圧迫するなどの事が起きており、これ
に対応する為に、「Clawl-Delay: 10」等と、10秒に1回以下でアクセスしてくださいといっ
た制御が出来ます。
sitemap.xml
sitemap.xmlがある場合は読み込みます。(robots.txtに記述されている場合は、その
sitemap.xmlを読み込み、記述されていない場合は、ドメイン直下のsitemap.xmlを読み
込もうとします。)
ここで、サイトのページを認識し、lastmodがあれば更新日の新しいページを重点的に
読みにいきます。無い場合はランダムページ内リンクを辿り巡回します。
何度か巡回するにあたり、そのサイトの更新頻度や変化を認識して、クロールバジェッ
トを設定します。
また、サイトを巡回するにあたって、外部リンクから辿って巡回するケースもあります。
クローラーが巡回する仕組みについて

Meta Robotsによる制御
© INFINIX Inc. 10
クローラーを制御する為に、一番優先順位が高いのはrobots.txtになりますが、robots.txtでは記述できないページ等を、Meta
Robotsを用いて制御を行います。
特定の検索エンジンを指定する場合は、name=“Googlebot” 等の様に設定できます。
検索エンジンの検索結果に表示させたくない場合 ※コンテンツを削除した場合など
<meta name=“robots” content=“noindex”>
検索エンジンにそのページから先をクロールさせたくない場合(通行止め)
※そのページから先にPageRankが流れないようになります。
<meta name=“robots” content=“nofollow”>
上記両方を併せて使う場合は
<meta name=“robots” content=“noindex,nofollow”> または <meta name=“robots” content=“none”>
検索エンジンに保管(キャッシュ)されたくない場合 ※過去のコンテンツを見られないようにする為等
<meta name=“robots” content=“noarchive”>
Meta Robotsの使用例と記述例
aタグへのnofollow
上記のmeta robotsではnofollowにする事で、そのページで通行止めにする事が出来ます。
その為、そのページから先のリンクに渡らないようにする事が出来、PageRankを渡さないようになります。
それを、限定的にaタグで、リンク個々に設定する事が出来ます。
<a href=“http://www.yahoo.co.jp/” rel=“nofollow”>Yahoo! JAPAN</a> ではYahoo! JAPANへのリンクにはPageRankを渡さず、クローラー
が巡回しない様に出来ます。
相互リンクや、リンク集などコンテンツとの関連で紹介するわけではない場合に用います。
※Googleはnofollowを設定してもクロールを行う場合があります。

11© INFINIX Inc.
Sitemap.xmlの構造について

Sitemap.xmlの役目
© INFINIX Inc. 12
• Sitemap.xmlとは
設置することで、サイトのクロールをより効率的に行えるようになる。サイト
マップは検索エンジンへのURL追加規約であり、URL排除規約である
robots.txtを補完するものである。
その為、検索エンジンは robots.txt を認識した後、 sitemap.xml を読み込
み、Webサイトの全体像を認識します。
robots.txtど同様にドメイン直下にsitemap.xml(sitemapindexの場合も)を設
置してください。
• なぜ必要なのか
検索エンジンはランダムにクロールする為、sitemap.xmlが無い場合は、
ページを巡回しながらインデックスに向けて準備をしますが、その際途中ク
ロールをやめてしまう可能性があり、全てをインデックスされない可能性が
あります。
より効率よく、全てのページを認識させ、インデックスする為には必要不可
欠な物と言えます。
クローラーが巡回できるページは全てsitemap.xmlに記載できているのが
好ましい。
クロール(検索エンジンでの巡回)する際の必要な要素
Sitemap.xml は Googleウェブマスターツールから登録する事が出来る為、ある程度
手動でクロールを促すことが出来ます。その為、Googleウェブマスターツール上では、
送信したSitemap.xmlでのページ数と、実際にインデックスされたページ数とグラフと
してみることが出来ます。
その為、CMSで更新した際に自動的にSitemap.xmlに記述できるような仕組みが効
果的と考えられます。

Sitemap.xmlの記述方法
© INFINIX Inc. 13
Sitemapindex形式の記述
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns=“http://www.sitemaps.org/schemas/sitemap/0.9”> <= sitemapindex形式
<sitemap> <= sitemapの設置場所を記述する定義
<loc>http://www.example.com/sitemap1.xml</loc> <= sitemap1.xml の設置場所の記述
<lastmod>2014-01-01T00:00:00+09:00</lastmod> <= sitemap1.xml の内部urlの最新更新日時
</sitemap>
<sitemap>
<loc>http://www.example.com/sitemap2.xml</loc> <= sitemap2.xml の設置場所の記述
<lastmod>2014-01-01T00:00:00+09:00</lastmod> <= sitemap2.xml の内部urlの最新更新日時
</sitemap>
</sitemapindex>
上記の記述で、sitemap.xmlの上限5万URLを超えて、複数のsitemap.xmlを1つのsitemapにインクルードす
る事が出来ます。
1Sitemapindexで1000個のsitemap.xmlを格納できます。
通常のSitemapの記述
<?xml version=”1.0″ encoding=”UTF-8″?>
<urlset xmlns=”http://www.sitemaps.org/schemas/sitemap/0.9″>
<url> <= ページURLを指定するという意味
<loc>http://www.example.com/</loc> <=ここに場所を指定
<lastmod>2014-01-01T00:00:00+09:00</lastmod> <=そのページ毎の最終更新日
<lchangefreq>daily</lchangefreq> <=更新頻度 ※オプション
<priority>1.0</priority> <=優先度 0.0～1.0 (1.0が最優先)
</url>
Sitemapindexと読み込むSitemap.xml
【最終更新日】
YYYY-MM-DDThh:mm:ss+TZD 形式
※Zは+09:00と日本を設定しても可
【更新頻度について】
・always（アクセスする度に更新されている）
・hourly（1時間毎に更新されている）
・daily（毎日更新されている）
・weekly（1週間毎に更新されている）
・monthly（1ヶ月毎に更新されている）
・yearly（1年毎に更新されている）
・never（アーカイブページなどに指定します）
【優先度】
・トップページが1.0
・第一階層が0.8
・第二階層が0.5
等という数値設定。
ページの優先度を判断して指定して下さい。
全てのURLに1.0に指定すると、その効果が
無くなります。

14© INFINIX Inc.
HTML5/XHTMLの記述について

Hタグについて
© INFINIX Inc. 15
Hタグ <H1>～<H6>
•H1の使用可能数は1ページあたり1つです。
•Hタグ内にDIVタグやPタグ等のブロック要素やTABLEタグ等, STRONGタグを用いるのは構文違反になります。
•Hタグ内で主に使用できるのはAタグやIMGタグ、SPANタグになります。
•Hタグには設置の順番がございます。 => 後述へ
注意点
HタグはHeading/Headlineから取った見出しタグになります。またSEOとしても特に重要なタグです。
a. H1は大見出しとなり、タイトルと同等で問題ありません。Header部分に設置して下さい。また、TOPページ以外はサイト名
を省いてしまっても問題ありません。画像では効果が下がってしまうため、テキストにてサイト最上部やロゴ下等に設置を
して下さい。
b. H2は中見出しとなり、参考とまして、小説の「第～章～～～」の項目にあたります。中央部分のコンテンツに入れる必要
があります。その為、何箇所使用することが出来るか、コンテンツにあわせる必要があります。イメージとしましては、作
文を書く時に似ています。テキストである事が重要で、画像になってしまう場合はaltで必ず記述して下さい。デザイン要素
を使う場合は、cssにてbackground属性を用いて、画像を背景に設置しテキストを重ねる手段がよく使われます。
c. H3は小見出しとなり、各章の中の小分類化されたものになります。H2タグ階層の下にある必要が御座います。H2テキス
トに関連した項目タイトルを入れる必要があります。こちらは画像でaltで記述して問題ありませんが、テキストの方が好ま
しいです。
d. H4/H5は更に準見出しとなります。特に情報量の多いページでしか使用できません。H3から更に細分化して説明する場
合に使用します。
e. H6はH5を用いて更に見出しを必要とする場合に使用しますが、殆どの場合で使用する機会はありません。

Hタグの並び方規則
© INFINIX Inc. 16
• H１は常に上部にあり、1つのみです。
• H2は中見出し要素になる項目の数だけ使用でき、必ずH1の下の階層である必要があります。
• H3は小見出しとなり、必ずH2の下の階層である必要があり、H2に関連した小見出しである必要
があります。
• H4は準見出しとなり、H3の下の階層である必要がございます。しかし、H4から先は滅多に使用機
会がない為、むやみに見出し扱いで設置するのはマイナス効果となってしまいます。
順番は
小規模サイト : <H1><H2><H3>
中規模サイト : <H1><H2><H3><H2><H3>,
大規模サイト : <H1><H2><H3><H4><H4><H3><H4><H4><H2><H3><H4><H4><H3><H4><H4>
といった並び方が想定されます。
途中で順番を飛ばしてしまうことはネガティブ要素につながる可能性があります。
Hタグの並び方
注意事項としまして、headerへのH1タグ以外のHタグ, footerへのHタグ, 両サイドの共通カラムへのHタグは、
ホームページ上で記述は控えるようにしてください。
H2から先はメインコンテンツの中央部分に位置している必要がございます。
※HTML5では、明示的な扱いになりH1に全てを置き換えることが可能です。(個人的には非推奨です)

DIV・Pタグについて
© INFINIX Inc. 17
DIVタグ
DIVタグはDIVISIONからきており、所謂区域や部門といった意味からきて
おり、ブロック要素になります。
右図の様に、主にidでレイアウトを決める際に使われます。
• idとclassの違いは
id : html内で1つのIDしか要素を持つことが出来ません。その為レイアウ
トとして使われることが多いです。また、JavaScriptで動的にデザイン変
化を出す場合にもよく使われます。
class : 複数個所で同じ要素を使用することが出来ます。特に右図の
descの様に類似した構成を使う場合に用いられます。また、1DIVタグで
複数のclass要素を持つことも出来ます。その為、デザイン要素で主に使
用されます。
Pタグ
PタグはParagraphからきており、文字通り段落という意味です。その為、
Hタグの下にコンテンツの説明テキストを記述するタグとして使用されま
す。
Pタグにもidやclassを使うことが出来ますが、主にデザイン要素として使
われるため、DIVタグのidとは若干認識が変わってきます。
以上の意味から、デザイン優先で両者を使うと文法的には好ましくない
形になってしまうことが多く見受けられます。
DIV・Pタグの違い
<div id=“header”>
<h1>
<ul id=“nav”>
<div id =“side”>
<div id=“footer”>
<div id=“contents”>
<div class=“desc”>
<h2>
<p>
<div class=“desc”>
<h2>
<p>

© INFINIX Inc. 18
HTML5にした場合ブロック構成
HTML5での配置例
<header> : ヘッダー部分
<h1> : 大見出し ※基本タイトルと同文
<nav> : グローバルナビ等の主となるナビ要素
※主とならないヘッダー・フッターナビはul/liのみで
<aside> : 関連要素(主にサイドバー等)
※サイド要素以外でも共通項目やコンテンツではない要素に対しても
用います。
<main> : コンテンツ部分枠
<article> : 独立したコンテンツ要素 (基本はH2要素を囲う形)
※ページ内でコンテンツが異なる場合は複数回使用(今回主にTOP
ページ)
<section> : コンテンツの区切り(主にH2,H3,H4等の見出しを囲う為に
用います。)
<h2> : セクション毎の中見出し
<p> : 見出しに対するテキスト等段落として使える箇所に
<footer> : フッター部分
上記のタグを使うことで、より検索エンジンに、より明確的に内部を教
えてあげることが出来る様になります。
以前までは<div>に対し、idやclass等を使い部分名を示しておりまし
たが、制作会社によって、わかりにくい名前となっていた為、より明確
的に示せるようになったのがHTML5になります。
<header>
<h1>
<nav>
<aside>
<footer>
<main>
<article>
<h2>
<section>
<h3>
<section>
<h3>
<article>
<h2>
<section>
<h3>
<section>
<h3>

19© INFINIX Inc.
Google Search Consoleのエラー対応について

Google Search Consoleのエラーの種類
© INFINIX Inc. 20
HTMLの改善
クロールエラー
《メタデータ》
重複するメタデータ(descriptions)
長いメタデータ(descriptions) : 161文字以上の場合
短いメタデータ(descriptions) : 20文字未満の場合
《タイトルタグ》
タイトルタグの記述なし
タイトルタグの重複 (パラメーターや、エリア等で同一ページが存在する場合が多いです)
長いタイトルタグ : 61文字以上の場合
短いタイトルタグ : 10文字未満の場合
情報が不足しているタイトルタグ : キーワードの詰め込みすぎや認識が困難な文章等
インデックス登録できないコンテンツ : 画像や動画などのメディア等が登録出来ないものが含まれているページ
上記の種類に分類されております。基本的にエラーの数は少なくしていただく事で、質の高いWebサイトとして認
識されるようになります。
Googleでは公式に、存在しないURLへのリンクが大量にあってもインデックス数やランキングには影響しな
いといっています。
不要なクロールバジェット消費を避けるために、リンクミス等を改善する必要はあります。
Googleは認識したURLが404になった後も、復活する可能性がある認識で、その後も継続的にURLを巡回し
ようとします。410(消滅)の場合は頻度は少なくなるようです。
しかし、404になっている場合でも、HTTPステータスコードで200を返す場合は『ソフト404』となり、Googleか
らアラートが来てしまい、ネガティブ要素として認識されてしまう為、ビジュアル的にも404、ステータスコード
的にも404となるよう統一してください。

21© INFINIX Inc.
リダイレクトの種類と正規化

URLリダイレクトの種類と正規化について
© INFINIX Inc. 22
リダイレクトの各ステータスコード
左表のような種類がありますが、良く使用されるのは 301及び302になります。
主に 301リダイレクトでは
http://www.example.com/ 及び http://example.com/ というwwwの有無両方にア
クセスできるようになっている場合
http://www.example.com/ に統一する為に用いる場合が多い。
wwwの有無両方でアクセスできてしまう場合、外部リンクや内部リンクなどのアン
カーリンクが統一されていない等で、重複コンテンツとして認識されてしまう場合が
あります。
その為、www有無のどちらかに統一する為に用います。
また、サイトの移転等でも使用されており、リダイレクト方法で唯一外部リンクを引
き継ぎます。
302リダイレクトでは、何秒後にどこにリダイレクトしますといった、一時的な利用が
多くなっております。この方法は、古いURLを残す場合に用います。
Meta Refreshでは、0秒に設定した場合は301リダイレクトと同様の効果があり、1
秒以上の場合は302リダイレクトと同様の効果があります。
S tatus C ode 説明
301 M oved Perm anently
U R Lが新しいU R Lへ恒久的に移動した事を示します。
古いU R Lを保持しているクライアントは、以後新しいU R Lのみ
を使用する。サイトリニューアルでU R Lが変更になった場合と
か、本来アクセスされるU R Lとは異なるU R Lへのアクセスを制
御させたい時とかに使用します。
また、リダイレクト元の外部リンクを引き継ぐ特性があります。
302 Found (M oved Tem porarily)
移動先のU R Lを発見したという意味があります。
リダイレクト先は一時的なU R Lのため、古いU R Lを保持してい
るクライアントはこの後も古いU R Lを保持し続ける。
303 See O ther
他を参照せよ。という意味があり、新しいU R LにG ETメソッドで
アクセスすることが決められたリダイレクト。フォームから
PO STした後にリダイレクトしてTO Pページへ戻す、というような
遷移で使う。
307 Tem porary R edirect
一時的リダイレクトという意味があります。302と似ています
が、リダイレクト前と同一メソッドでリダイレクト先へもアクセス
を行うところが異なっております。
基本的には、302リダイレクトにて規格外の使用法が目立った
ため、307が誕生しました。
サーバ障害等にもう片方にリダイレクトして処理を続行させる
場合とかで使用します。
正規化方法について
上記のリダイレクトでは、301がURLの正規化にあたります。その為、Webサイトの移転やURLの変更、またwwwの有無の統一などを行う場合は301リダイレクトを使用してく
ださい。
また、301リダイレクト以外にLINKタグのrel属性canonicalを用いて、正規化を行うことも出来ます。
殆どコンテンツが一緒のページが存在する場合は、正規化先となるURLにcanonicalのhrefを設定して頂くことで、クローラーに重複コンテンツとしての認識をされないよう回
避する事が出来ます。
詳細は、次項にて

正規化による外部リンクの引継ぎについて
© INFINIX Inc. 23
301リダイレクトとrel=“canonical”での外部リンクの引継ぎ
上記、左図301リダイレクト及び、右図rel=“canonical”においては両方とも外部リンクを引き継ぐ付加効果があります。
その為、URLを恒久的に移動した場合は301リダイレクトを用いて、外部リンクの力を引き継ぎ、重複コンテンツの可
能性がある場合はrel=“canonical”を用いて、正規化先URLへ外部リンクを引き継ぎを行ってください。
example.com/abcd.html
example.com/1234.html
外部リンク
301リダイレクト
example.com/abcd.html
example.com/1234.html
rel=“canonical” href=“/abcd.html”
外部リンク
rel=“canonical”

24© INFINIX Inc.
Linkタグについて

Linkタグとは
© INFINIX Inc. 25
HTMLに関連するファイルの指定
SEO対策として重要なポイント
LINKタグはHTMLファイルに関連する別のファイルを指定し、関係性を定義するものです。
その関係性を示す方法として、rel属性を用いて、ファイルの指定を行います。
《例》
rel="リンクタイプ"････････この文書からみた別の文書との関係
reｖ="リンクタイプ"･･･････別の文書からみたこの文書との関係
href="URI"･･････････････関連文書のURI
type="MIMEタイプ"･･･････関連文書のMIMEタイプ
target="フレーム名"･････関連文書を表示させるフレーム名
charset="文字セット"････関連文書の文字コードセット
hreflang="言語コード"････関連文書の言語コードセット
media="メディアタイプ"･･･関連文書が出力するメディアタイプ
と多くの属性がありますが、今回はWebサイトにとってSEOに重要なポイントを抜粋させて頂きます。
今回はSEOにとって特に重要な働きをする記述方法を紹介致します。
1. 『rel=“canonical” href=“URI” 』
2. 『rel=“prev” href=“URI”』
3. 『rel=“next” href=“URI”』
という重要な役割について、次ページより使用例含めてご説明いたします。

rel=“canonical”の使用例①
© INFINIX Inc. 26
『Yahoo!JAPAN ヤフオク』の使用例
上記2つは、違うURLで同じコンテンツを表示しているページです。
この場合、2つのページURLが別々に認識される場合、重複ページとしてGoogle等の検索エンジンに認識されてしまいます。
上記はYahoo!JAPANのヤフオク『すべてのカテゴリ > コンピュータ > パソコン > Windows > ノートブック、ノートパソコン』の検索結果を例にしています。
Yahoo!JAPANでは、これらに適切に対応しており、さまざまなURLで認識されるURLをcanonicalを用いて正規化をしています。
http://auctions.search.yahoo.co.jp/search?ei=UTF-8&p=ジャンク
&rkf=1&s1=bids&o1=a&slider=0&tab_ex=commerce&fixed=0&nockie=1&auccat=23412
http://auctions.search.yahoo.co.jp/search/ジャンク/23412/

rel=“canonical”の使用例②
© INFINIX Inc. 27
『ヤフオク』でのソート後URLのcanonical使用例
上記では、システムURLと思われる
「http://auctions.search.yahoo.co.jp/search/ジャンク/23412/」というURLに正規化をされています。
また、右図のソートなどを変えても上記のURLに正規化を行われており、表示結果が同じURLを統一しています。
「同じ結果」を表示するページは、統一したURLに正規化/基準化(canonical)する事で、『重複タイトル』や『重複コンテンツ』といったネ
ガティブ要素を回避する事が出来ます。
※しかしヤフオクではcanonicalは実装されていますが、prev/nextは実装されておりません。
http://auctions.search.yahoo.co.jp/search?ei=UTF-8&p=ジャンク
&rkf=1&s1=bids&o1=a&slider=0&tab_ex=commerce&fixed=0&nockie=1&auccat=23412

rel=“canonical”の使用例③
© INFINIX Inc. 28
『楽天市場』においての間違った使用例
上記では、ソートによりcanonicalのURLも変更されています。
この場合、ソートを変えても掲載内容は変わりません。その為、この場合重複コンテンツという認識をされる可能性が高くなります。
※楽天市場の場合もヤフオク同様にprev/nextに対応しておらず、prev/nextにおいて結果全てを1つのコンテンツと認識させていない
為、違う結果という事で回避されている可能性があります。
prev/nextを併用する場合、ページネーションにおいて全ページ分を1つのコンテンツとして見なすため、ソートの変化にるURLの変化
はcanonicalでデフォルトで表示するURLに正規化してください。
【参考 : http://googlewebmastercentral-ja.blogspot.jp/2009/07/blog-post.html 】
http://search.rakuten.co.jp/search/mall/-/タブレットPC本体-560029/f.1-p.1-s.1-sf.0-st.A-v.2
http://search.rakuten.co.jp/search/mall/-/タブレットPC本体-560029/f.1-p.1-s.2-sf.0-st.A-v.2
【楽天市場】検索結果 - タブレットPC本体スマートフォン・
タブレット(価格が安い順写真付き一覧在庫あり)：通販・
インターネットショッピング
【楽天市場】検索結果 - タブレットPC本体スマートフォン・
タブレット(標準順写真付き一覧在庫あり)：通販・イン
ターネットショッピング

rel=“prev”, rel=“next”について
© INFINIX Inc. 29
Googleのprev/nextの対応と、それまでの方法について
canonicalによる正規化は2009年より対応しておりますが、
prev/nextによるページネーションの相関性は2011年後半
に対応しました。
それまでは、右上図の様に、ページネーションがある場合
でも、検索結果を全表示したURLへcanonicalで正規化す
る必要がありました。
それが、各ページネーションによる相関性を示すために、
prev/nextを用いてページ間の関係性をタグで示す事がで
きるようになり、検索結果全表示（View All）の膨大な掲載
ページを用意する必要がなくなりました。

並び替えによるURLへの対処方法について
© INFINIX Inc. 30
右上図では、oldest(古い順)を標準の並び替えとした場合、
newest(新着順)の並び替えも別URLとして認識されてしまうの
は好ましくありません。
この場合、orderにて、oldest/newestというパラメーター別に
なっている為
右下図の様に、orderというパラメータにおいてoldestという値を
デフォルト化する事が出来ます。
しかし、『?parameter=value』というURL認識させる必要がある為、
『ぴゅあらば』のエリア一覧等では、Googleウェブマスターツー
ルを使わずに、システム的にcanonicalを用いて正規化をする
必要があります。
また、パラメータついてしまっており、重複認識をされてしまって
いる場合は、パラメーターをGoogleに無視させるために
パラメーターを指定して
『いいえ: ページのコンテンツには影響しません』を選択してくだ
さい。
しかしこれは、対Googleのみになる為、canonicalで正規化する
のが効果的です。
並び替えのパラメータのGoogleウェブマスターツール上での設定方法

31© INFINIX Inc.
Sitemap.xmlのPing通知について

Sitemap.xmlを検索エンジンに伝える方法とは
© INFINIX Inc. 32
• Google Search Consoleの利用
Google Search Consoleから、Sitemap.xmlを登録及び更新により、
Webサイトの増加ページをGoogleに伝える事が出来ます。
登録したSitemap.xmlを選択して、『再送信』をする事で、更新され
たページを検索エンジンに伝える事が出来ます。
この方法では、Sitemap.xmlを更新する度に、『再送信』を行わなく
てはいけません。※自動でも取得されますが、Googleのスケ
ジュールに左右されます。
手動でSitemap.xmlを通知する方法
自動でSitemap.xmlを通知する方法
・Sitemap.xmlのPing通知
様々なプログラムにより、GoogleへSitemap.xmlをPing通知する事が出来ます。

Sitemap.xmlのPing通知方法
© INFINIX Inc. 33
《PHP cURL関数》
※Sitemap.xml更新時に自動でPHPを実行する為、連携する必要があります。
$ping_to =
'http://www.google.com/webmasters/tools/ping?sitemap=http%3a%2f%2fwww%2eexample%2ecom%
2fsitemap%2exml';
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $ping_to);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_HTTPHEADER, FALSE);
$res = curl_exec($ch);
curl_close ($ch);
《cron + curl》
0 6 * * * /usr/bin/curl
http://www.google.com/webmasters/tools/ping?sitemap=http://www.example.com/sitemap.xml >
/dev/null
上記では、毎日6時にPing通知する設定をしております。
Sitemap.xmlを自動生成するプログラムがPHPの場合は、前者のPHP curlによる連携通知が好まし
いと考えられます。
これ以外にも、PerlやPython等、他にも利用できるプログラミング言語は多数有りますので、システ
ムに合わせて、連携する事が好ましいです。
※Pingを利用する場合、予めWebサイトをGoogle Search Consoleに登録しておく必要がございます。
Sitemap.xmlのPing通知方法について
PHP curlにて行う場合
ping?sitemap= から先のURLはエンコードを行う必要があります。
http://www.example.com/sitemap.xml
をUTF-8にてエンコードすると
http%3a%2f%2fwww%2eexample%2ecom%2fsitemap%2exml
の様になります。
また、Ping通知する場合は、sitemap.xml内においてlastmodによる更
新日時の記述が必要になります。
DBに、コンテンツのChangeDate等更新日時を管理している場合は、
そちらを連動するようにしてください。
ページ数が膨大で、バッチ処理にて更新を行う場合は、バッチ処理を
する際に必ず更新されているページのlastmodはバッチ処理の日時
を設定しても問題ありません。
lastmodを設定する場合、更新したページとなる為、更新内容を評価
してもらうのが意図となります。特に評価に結びつく大きな変化が無
い、もしくは重要なコンテンツでない場合は、lastmodを記述せずに、
lastmodを記述したページを優先的にクロールしてもらうようにして下
さい。

34© INFINIX Inc.
RSSとPubSubHubbubについて

PubSubHubbubとは
© INFINIX Inc. 35
RSSは、読みにいくサーバ(Subscriber), RSSリーダーはRSSを配信しているサーバ(Publisher), WordPress等のBlog系CMSで
は定期的にRSSを取得する事しか実際にRSSの内容が更新されているかどうか知ることが出来ませんでした。
所謂手動もしくは自動設定による時間間隔でRSSを読みに行くことでしか情報を伝えられず、最大で1時間に1回のRSS取得
であれば、24回しか更新を伝えられませんでした。
そこで作られたのがPubSubHubbubという仕組みです。
Pub : Publisher ( 配信側 )
Sub : Subscriber ( 購読者 )
Hub : Hub ( 中継 )
から、Hubbub ( わいわいがやがや ) をかけて、このような名前になりました。
配信側は、Pingを使い更新したという情報を中継のサーバに伝え、より早く購読者に伝える事が出来ます。
2009年8月19日、Googleがいち早く対応し、より早くリアルタイムに近い間隔でGoogleの検索結果に反映する事が出来る様に
なりました。
RSSの更新と通知をリアルタイム化

RSS2.0の記述方式について
© INFINIX Inc. 36
<rss xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" version="2.0">
<channel>
<title>カテゴリ1 | Webサイトタイトル</title>
<atom:link href="http://www.example.com/cat01/feed/" rel="self" type="application/rss+xml" />
<link>http://www.example.com/cat01/</link>
<description>カテゴリ1のページです</description>
<lastBuildDate>Sun, 05 Jan 2014 01:00:00 +0000</lastBuildDate>
<language>ja</language>
<sy:updatePeriod>hourly</sy:updatePeriod>
<sy:updateFrequency>1</sy:updateFrequency>
<generator>FeedGenerator 1.0</generator>
<atom:link rel="hub" href="http://pubsubhubbub.appspot.com" />
<atom:link rel="hub" href="http://pubsubhubbub.superfeedr.com" />
<item>
<title><![CDATA[ページタイトル02]]></title>
<link>http://www.example.com/cat01/001/</link>
<pubDate>Sun, 05 Jan 2014 01:00:00 +0000</pubDate>
<dc:creator><![CDATA[ テスト太郎 ]]></dc:creator>※オプション
<category><![CDATA[ カテゴリ002 ]]></category>※オプション
<description><![CDATA[ ページ説明文02 ]]></description>
<content:encoded><![CDATA[ <p>表示する要約部分のhtmlコード</p> ]]></content:encoded>
</item>
<item>
<title><![CDATA[ ページタイトル01 ]]></title>
<link>http://www.example.com/cat01/001/</link>
<pubDate>Sun, 05 Jan 2014 00:00:00 +0000</pubDate>
<dc:creator><![CDATA[ テスト太郎 ]]></dc:creator>※オプション
<category><![CDATA[ カテゴリ001 ]]></category>※オプション
<description><![CDATA[ ページ説明文01 ]]></description>
<content:encoded><![CDATA[ <p>表示する要約部分のhtmlコード</p> ]]></content:encoded>
</item>
</channel>
</rss>
RSS2.0の記述と形式
RSS2.0の場合はxmlnsにより属性を設定できる為、Atom等の属性も取り込むこと
が出来ます。
その場合の設定を左記に記述します。
コメント等がある場合は、xmlnsに
xmlns:wfw="http://wellformedweb.org/CommentAPI/"
を記述する必要があります。
基本的には、xmlnsで設定した形式を記述する事が出来ます。
<atom:**> では、Atom形式を
<sy:**> では、
updatePeriod :
チャンネルフォーマットが更新される期間チャンネルフォーマットが更新される期間
updateFrequency :
更新期間に関連して、更新の頻度
updateBase :
上記2つを利用し、発行スケジュールが正確に計算できるよう、基準日の設定
等が設定できます。
XMLはマークアップする為のものなので、マークアップではない形式を記述する場
合は、CDATAセクションを用いる必要があります。
左記では、<title>や<description>等では、CDATAセクションは必要ない場合があ
りますが、特に<content:encoded>等で、実際の要約部分のhtmlを記述する場合
等には必要となります。
『※オプション』部分は、特に記述が無くとも問題が無い箇所になります。その場合、
xmlnsから削除しても問題はありません。
<item>にて、最新コンテンツが上に来るように生成する必要があります。
<lastBuildDate>や<pubDate>はRFC822の日付形式で記述する必要があります。
<generator>では、生成プログラムの名前がある場合などに、名称やURLを設置し
ます。

PubSubHubbubによる目的とメリット
© INFINIX Inc. 37
オリジナルコンテンツをいち早く
左図の様に、通常のRSSからPubSubHubbubにする事で得られるメリットが
1. オリジナルコンテンツがいち早くGoogleにインデックス化
2. 無断でコンテンツをコピーするスクレイパーからWebサイトの防御
の2点が挙げられます。
1と2に言える事は、せっかくのオリジナルコンテンツであっても、スクレイ
パーのWebサイトがいち早くGoogleにインデックスされてしまっては、せっ
かくのオリジナルコンテンツが検索エンジンにはコピーコンテンツとして、
Webサイトへのマイナス評価となります。
その為、コンテンツをコピーするスクレイパーから身を守りつつ、より高速
なGoogleのインデックス化により、質の高いコンテンツを提供していると評
価され、SEO対策をする上では、膨大なバックアップ効果を得られる事が
出来ます。

PubSubHubbubとPing通知の違いについて
© INFINIX Inc. 38
PubSubHubbubの特性
RSSをPingでPubSubHubbub対応のHUBサーバに通知を行うと、RSS記載の最新URLへのク
ロール指示を行えます。
この際PubSubHubbubで効果のあるページはRSSに記載されたURLのみになります。
RSSは掲載件数最大～件と制限するのが一般的の為、全ページをPing通知する事は出来ま
せん。
Pingで通知する際は、pubDateが更新されるタイミングが好ましく、更新頻度の高いサイトでは、
PubSubHubbub対応のHUBサーバにPingでRSSを通知すると、最短で10分程度でGoogleにイン
デックスされるようになります。この際、Googleは最初にPubSubHubbub専用のGooglebotが巡
回に来ます。
この様に、新規追加ページのみクローラーに伝える事が出来る仕組みです。
主にブログ・ニュースサイトで活用されています。
※コピー記事をかかれ、クローラーにオリジナルと認識されるのを防ぐ目的で利用されています。
それぞれの特性について
Ping通知(Sitemap.xml)の特性
Sitemap.xmlをPingで通知します。
‘http://www.google.com/webmasters/tools/ping?sitemap=http%3a%2f%2fwww%2eexample%2e
com%2fsitemap%2exm’ と、Google Search Console宛にsitemap.xmlのURLをPingで伝えます。
MicrosoftのBingにも同じような機能があります。
こちらは、Sitemap.xmlのlastmodを見て、新規・更新ページを認識して、巡回に来ます。
PubSubHubbubと違う点は、更新したページも巡回してもらえるという特徴を持っています。
同じく新規ページもlastmodを記載する事で、巡回してもらうことが可能です。
しかし、PubSubHubbbubとは違い、クロールするタイミングはGoogleの任意のタイミングとなる
為、すぐには巡回してもらえないことが多いです。

PubSubHubbubの通知先
© INFINIX Inc. 39
PubSubHubbubのHubサーバは、Googleの http://pubsubhubbub.appspot.com/ や、http://pubsubhubbub.superfeedr.com/
があります。
Googleの場合は
https://pubsubhubbub.appspot.com/publish に hub.mode=publish&hub.url=[Feed出してるURL]
と通知するだけでいけますが、プログラムとの連携を考慮する必要がございます。
Hubサーバ

FeedのPubSubHubbub対応方法
© INFINIX Inc. 40
《ATOMの場合》
<link rel="self" type="application/atom+xml" href="feedのURL" />
<link rel="hub" href="http://pubsubhubbub.appspot.com" />
<link rel="hub" href="その他のHubサーバを指定する場合は追加" />
を、入れます。
《RSS2の場合》
<rss version=“2.0” の中に
xmlns:atom=“http://www.w3.org/2005/Atom” と、ATOMのNSを入れます。
その上で、
<atom:link rel="self" href="feedのURL" type="application/rss+xml" />
<atom:link rel="hub" href="http://pubsubhubbub.appspot.com" />
<atom:link rel=“hub” href=“その他のHubサーバを指定する場合は追加" />
を追記していただく必要があります。
ATOM/RSS2 Feedの修正

Publish通知をHubに送る①
© INFINIX Inc. 41
《PHP curl関数》
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'http://pubsubhubbub.appspot.com/');
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTDATA, ‘hub.mode=publish&hub.url=’.urlencode(‘feedのURL'));
curl_exec($ch);
curl_close($ch);
《Google App Engine for Java(GAE/J)》
URLFetchService ufs = URLFetchServiceFactory.getURLFetchService();
HTTPRequest req = new HTTPRequest(new URL("https://pubsubhubbub.appspot.com/publish"),HTTPMethod.POST);
req.setPayload(("hub.mode=publish&hub.url=" + URLEncoder.encode(url,"UTF-8")).getBytes());
ufs.fetchAsync(req);
参考サンプル例①

Publish通知をHubに送る②
© INFINIX Inc. 42
《Perl》
use strict;
use warnings;
use LWP::UserAgent;
use HTTP::Request::Common;
my $post = {
url => 'http://pubsubhubbub.appspot.com/',
data => {
'hub.mode' => 'publish',
'hub.url' => 'http://example.jp/feed‘
}
};
&http_post($post);
sub http_post {
my $post = shift || return(0);
my $lwp = '';
my $req = '';
$lwp = LWP::UserAgent->new(timeout => 10);
$req = POST($post->{url}, [$post->{data}]);
$lwp->request($req);
return;
}
参考サンプル例②

通知後のクローラーの動向
© INFINIX Inc. 43
Hubサーバへ通知後、以下の様なログが確認できます。
107.178.200.205 - - [10/Dec/2014:21:04:21 +0900] "GET /feed/ HTTP/1.1" 200 3703 "-" "AppEngine-Google;
(+http://code.google.com/appengine; appid: s~pubsubhubbub-hrd)“
しかし、PubSubHubbubのクローラーがきても、feed内の各リンクを巡回してくれない場合があります。
一番好ましい方法として、PubSubHubbub後のクローラーのアクセスを確認して、新規記事ページへクローラーが来ない場合
は、再度Hubサーバへの通知が送信できる仕組みが効果的です。
または、定期的にHubサーバへ通知するcronジョブを設定しても良いと思われます。
通知後の動向と対応について

44© INFINIX Inc.
画像圧縮によるページ表示速度の向上

Google PageSpeed Insights
© INFINIX Inc. 45
Google PageSpeed Insightsでは、Google Developers
サイト内
( https://developers.google.com/speed/pagespeed/i
nsights/?hl=ja )
以外に、Chrome拡張機能でも提供しております。
左図の様に、赤枠の箇所に「PageSpeed」というのが
追加されます。
これにより、実際にブラウジングする環境視点で、
PageSpeed Insightsの解析を行うことが出来ます。
ロスレス圧縮が可能な画像がある場合は、青枠の所
で、「最適化されたコンテンツを表示」というリンクが
出現して、実際にロスレス圧縮した画像を表示して保
存する事が可能です。
しかし、これでは手間がかかる為、サーバ上で画像
圧縮ができるような仕組みを組み込むことで、半自
動で画像の最適化を行えます。
また、画像を使わずにベクトルデータのSVGを使うこ
とで、より高速化する事が出来ます。ロゴや各種アイ
コンをIllustratorを使用して作成した場合は、SVGを
おススメします。
Google PageSpeed Insights

46© INFINIX Inc.
CSSスプライトについて

CSSスプライトとは
© INFINIX Inc. 47
複数のファイルとして扱う画像パーツを、1つの画像にまとめて扱うことで、Webページ表示時のHTTPリクエスト数を削減する為の技術
として使われています。
また、画像を1つにまとめることで、複数画像ファイルの合計サイズよりもファイルサイズを小さく出来るメリットもあります。
更新頻度の高い画像に対しては、メンテナンス性が悪いためあまり向いていません。
しかし、Webサイト全体で使用する共通画像を1つにまとめる事で、ページ表示速度の高速化が出来ます。
CSSスプライトの概要
メリット
- 画像へのHTTPリクエストの削減でページ表示速度高速化
- 装飾画像などをIMGタグとしてALT属性の記述も必要なくなる
- HTMLソースが削減ができる
デメリット
- 画像更新の手間が増える
- 管理ツールGrunt等を使用する必要が出てくる
- ＣＳＳ内でbackground-positionが多くなる
メリット・デメリット

手動によるSprite化とGrunt出力例
© INFINIX Inc. 48
CSSスプライト化用のコード例(overflow)
.ico_test_sprite,.ico_test_banner_001,.ico_test_banner_002,.ico_test_banner_003 {
background-image: url('../images/sprite_test.png');
background-repeat: no-repeat;
}
.ico_test_banner_001 {
background-position: 0 -542px;
height: 70px;
width: 180px;
}
height: 70px;
width: 180px;
}
height: 70px;
width: 180px;
}
#spriteTest li {
display: block;
margin-bottom: 5px;
width: 190px;
}
#spriteTest li a {
display: block;
padding-left: 190px; /* text-indent を使わない方法で実装 */
overflow: hidden; /* text-indent を使わない方法で実装 */
background-image: url(“sprite.png”); /* CSSスプライト用の画像 */
}
.spriteTest bgimg, { height: 52px }
.spriteTest-a { height: 37px }
.spriteTest-b { background-position: 0 0 }
.spriteTest-c { background-position: 0 334px }
.spriteTest-d { background-position: 0 282px }
.spriteTest-e { background-position: 0 230px }
.spriteTest-f { background-position: 0 178px }
.spriteTest-g { background-position: 0 126px }
**** 略 ****
Gruntによるスプライト出力例

49© INFINIX Inc.
schema.orgについて

schema.orgとは
© INFINIX Inc. 50
『スキーマとは、ウェブマスターがページをマークアップすることによって大手検索プロバイダーに認識されやすくなるHTMLタグです。
Bing、Google、Yahoo! などの検索エンジンサイトはこのマークアップを通してより質の高い検索結果を出すことができ、またユーザは
探したいページを簡単に見つけられるようになります。』
『Bing、GoogleとYahoo!は協力し合い、sitemaps.orgのようにウェブマスターが使えるスキーマ語彙を提供することにしました。』
と、大手検索エンジン会社が協力して、セマンティック(ウェブページの意味を扱う)検索を実現する為のボキャブラリの共通化を行って
います。
schema.orgとはWebページの「ボキャブラリ」（語彙）
• microformats.org
Microdataの類似セマンティック技術のmicroformatsの仕様化の活動を行っており、Webサイトで人やイベント、ブログ記事、レビュー、
ライセンスなどのような共通して公開されているものを記述する際に用いるマークアップパターンを策定しています。
• data-vocabulary.org
Schema.orgはMicrosoft,Google,Yahoo!といった検索エンジン大手3社が協力して策定している仕様ですが、こちらはGoogleが独自に策
定しています。特にパンくずの語彙が含まれているところが特徴です。
schema.org以外の語彙

schema.orgを用いれる記述方式
© INFINIX Inc. 51
Microdataは、HTMLにメタデータを埋め込むための記述方法です。HTML5の仕様の一部として策定が開始され、昨年はW3Cから勧告
予定でしたが、打ち切られWorking Group Notes(アイデアの記録)に移行されました。その為、HTML5での正式な仕様の一部にはなっ
ておりません。
しかし、現在schema.orgを使用するにあたって、もっとも情報量が多い記述方式になります。
また、いち早くGoogleが対応したことから、セマンティックSEOとしての効力は有効です。
Microdata
RDFaはMicrodata以前から策定が進められているセマンティック技術の一部です。Microdataとの違いは、主にHTML5だけではなく、従
来のXHTMLにも対応している点で、幅広い拡張性があります。
RDFaでは、記述が若干複雑で、より高度なメタデータを記述する事が可能です。
しかし、記述量が多い為、Microdata並みに簡易的に記述出来る様になったのが、RDFa Liteになります。その為、RDFaとMicrodataで
は、記述の簡単さから、コーダーにとってはMicrodataの方が記述しやすい傾向にありました。しかし、RDFa Liteが正式に勧告されたこ
とで、一旦打ち切られたMicrodataよりもRDFa Liteの方が主流になりつつあります。
RDFa / RDFa Lite
JSON-LD
JSON-LDでは、前者の2つの記述方式とは異なり、Linked Dataを送信する仕組みで、関連するデータを結びつける事で記述を可能に
する事が出来、直接HTML内に記述する必要が無く、今後一番導入しやすい技術になると思われます。
基本的には、JSONつまりJavaScriptとして記述する事が出来る為、1つにまとめて全ページで読み込ませることが可能です。

schema.orgを用いた記述
© INFINIX Inc. 52
HTMLコードに意味を持たせる
《例》通常のHTMLソース
<div>
私の名前は東京太郎ですが、みんなから「東太」と呼ばれています。私のホームページは、
<a href="http://www.example.com">www.example.com</a> です。
東京都港区に住んでおり、エンジニアとして ACME 社に勤めています。
</div>
《例》 Microdataを適用したHTMLソース
<div itemscope itemtype="http://schema.org/Person">
私の名前は<span itemprop="name">東京太郎</span>ですが、
みんなから「<span itemprop="nickname">東太</span>」と呼ばれています。
私のホームページは、
<a href="http://www.example.com" itemprop="url">www.example.com</a> です。
東京都港区に住んでおり、<span itemprop="title">エンジニア</span>として
<span itemprop="affiliation">ACME 社</span>に勤めています。
</div>
《例》 RDFa Liteを適用したHTMLソース
<div vocab="http://schema.org/” typeof=”Person">
私の名前は<span property="name">東京太郎</span>ですが、
みんなから「<span property="nickname">東太</span>」と呼ばれています。
<a href="http://www.example.com" property="url">www.example.com</a> です。
東京都港区に住んでおり、<span property="title">エンジニア</span>として
<span property="affiliation">ACME 社</span>に勤めています。
</div>
左記の様に、MicrodataとRDFa Liteでは、記述方法に若干の違
いがあります。
RDFaとRDFa Liteでも記述方法が異なりますが、そちらは後述に
てご説明致します。
主な違いは、親ブロックに schema.org を記述をしますが、
Microdataではitemtypeとしてタイプまでを含むURLを記述します。
しかし、RDFa Liteではvocabにてschema.orgを指定した後に、
typeofにてタイプを記述するという分けたやり方になります。これ
は、以前からのRDFaの流れを汲んでいる為と思われます。
そして、itempropとpropertyの違いになるのみで、基本的にはあ
まり大差がありません。

RDFaとRDFa Liteの違い
© INFINIX Inc. 53
RDFaとRDFa Liteでの記述方法の違いについて
HTMLとしての記述であれば、そこまでの違いはありませんが、
基本となる拡張性の問題でLiteで簡素化されたという形に
なっております。
《例》 RDFaを適用したHTMLソース
<div xmlns:v=”http://schema.org/” typeof=”v:Person">
私の名前は<span property=“v:name">東京太郎</span>ですが、
みんなから「<span property=“v:nickname">東太</span>」と呼ばれています。
<a href="http://www.example.com" property=“v:url">www.example.com</a> です。
東京都港区に住んでおり、<span property=“v:title">エンジニア</span>として
<span property=“v:affiliation">ACME 社</span>に勤めています。
</div>
《例》 RDFa Liteを適用したHTMLソース
<div vocab="http://schema.org/” typeof=”Person">
私の名前は<span property="name">東京太郎</span>ですが、
みんなから「<span property="nickname">東太</span>」と呼ばれています。
<a href="http://www.example.com" property="url">www.example.com</a> です。
東京都港区に住んでおり、<span property="title">エンジニア</span>として
<span property="affiliation">ACME 社</span>に勤めています。
</div>
主に、RDFaでは、XML属性を記述する事で、さまざまな拡張性を
持っています。
主な方法として、xmlnsによる指定で、その部分がどの部分を参
照させるかを指定することが出来ます。
今回は、schema.orgというvocabularyを使うため、xmlns:vと、
vocabularyのvが指定出来ます。それいがいにも、RDFの記述方
式を取り入れるために、xmlns:rdfによる参照元の指定や、svgと
しての参照元を指定する事も可能です。
しかし、拡張性が豊富すぎるがゆえに、組込の手間やHTMLソー
スコードも膨大に膨れ上がります。そこで、より簡素にして取り入
れやすくなったのがRDFa Liteになります。
RDFa Liteを用いることで、既にW3Cが勧告済みという事もあり、
現在主流となってきております。

構造化データの確認方法
© INFINIX Inc. 55
左図の様に、
https://developers.google.com/structured-data/testing-tool/
というURL構造で、チェックをする事が出来ます。
最初はテストサーバ等で、schema.orgの記述がしっかりと行えて
いるか確認し、問題なければ本番に反映という形を取っていただ
ければと思います。

JSON-LD記述サンプル
© INFINIX Inc. 56
JSON-LDでの記述サンプル
《例》 JSON-LDを適用した例
<script type="application/ld+json">
{
"@context": "http://schema.org",
"@type": "LocalBusiness",
"name": "店舗名",
"description": "店舗説明",
"openingHours": [
"11:00-24:00”
],
"telephone": "電話番号",
"url": "http://www.example.com",
"priceRange” : "4,000-14,000円”,
"image": "http://www.example.com/shop.jpg",
"address": {
"@type": "PostalAddress",
"streetAddress": "住所番地",
"addressLocality": "市区町村",
"addressRegion": "都道府県"
"postalCode": "郵便番号",
}
}
</script>
左記の様に、JSON-LDでの記述が行えます。
通常のjavascript形式で {} によって親子関係を作ることが出来ま
す。
表向きに設定例を公開されておりませんが
<script type="application/ld+json" src="sample.js"></script>
と、一つのjsを読み込む事も出来ると考えられます。
左記は、店舗ページ毎にその店舗ページのみのjsonとして読み
込む必要があります。

JSON-LDの確認方法
© INFINIX Inc. 57
Microdata/JSON-LD sniffer
https://chrome.google.com/webstore/detail/microdatajson-ld-
sniffer/djgonlcfpeeddedjhpgijdckhgddcfgf
というChromeの拡張機能により、そのページの構造を確認する
事が出来ます。

パンくずリストのRDFaマークアップ方法
© INFINIX Inc. 59
パンくずリストのHTMLコードの変更 (RDFa)
《例》通常のHTMLソース
<a href="http://www.example.com/dresses">洋服</a> ›
<a href="http://www.example.com/dresses/real">ドレス</a> ›
<a href="http://www.example.com/dresses/real/green">緑のドレス</a>
《例》 RDFaを適用したHTMLソース
<div xmlns:v="http://rdf.data-vocabulary.org/#">
<span typeof="v:Breadcrumb">
<a href="http://www.example.com/dresses" rel="v:url" property="v:title">
ドレス
</a> ›
</span>
<a href="http://www.example.com/dresses/real" rel="v:url" property="v:title">
ドレス
</a> ›
</span>
<a href="http://www.example.com/dresses/real/green" rel="v:url" property="v:title">
緑のドレス
</a> ›
</span>
</div>
今回のパンくずの利用において、RDFa Liteを用いた記述例が無い為、Liteを取り入れるのはまだ待つ必要がありそうです。

パンくずリストのRDFaマークアップの記述注意点
© INFINIX Inc. 60
記述に関する注意点
親ブロックに xmlns を使用してネームスペースを宣言しています。
末尾には必ずスラッシュと # を付けます。
（xmlns:v="http://rdf.data-vocabulary.org/#"）
ul/liを用いる場合は、ulを囲むdiv等が適切です。
各パンくずは typeof=“v:Breadcrumb”で指定します。
ul/liを用いる場合は、<li typeof=“v:Breadcrumb”> としてください。
パンくず名は title プロパティで識別されます。プロパティ名の前には v: を付けます。（<span property="v:title">）。
rel 属性は、リンクがパンくずの URL であることを示しています。property 属性は、<a> 要素内で指定します。
（<a href="books.html" rel="v:url" property="v:title">書籍</a>)
※<a>内に<span>が有る場合は、v:titleは<span>に記述します。v:urlは当然<a>に記述いたします。
各パンくずアイテムは、その順序で表示され、最初のアイテムがトップレベルのページを表し、最後のアイテムが現在のペー
ジの親を表します。

パンくずリストにおける注意点
© INFINIX Inc. 61
パンくずリストの対応に関しましては、検索エンジン大手3社が協力して策定している、schema.orgでは定義する事が出来ません。
この様に、Googleのdata-vocabulary.orgでは策定が完了されておりますが、3社協力のschema.orgでは、策定が完了しておりません。
その為、部分的に利用するボキャブラリを変える必要があります。
schema.orgは使用できません

© INFINIX Inc. 63
HTTPS(SSL)での検索順位優遇について
Google は 2014年8月にHTTPS(SSL接続)の場合、検索順位が優位にな
る旨発表しました。
兼ねてより、HTTPSでのサイトと通常のHTTPのサイト運営の比較を
行っており、実際に影響が出始めていたのは2013年後半より既に優位
な状態が出ておりました。
正式にGoogleにより発表され、ここ最近では導入されるWebサイトが非
常に多くなってきている様に見受けられます。
このHTTPSについてですが、常にHTTPSになるような設定は必要なく、
HTTP及びHTTPS両方でアクセスできる状態であっても優遇されるとの
発表があります。その為、表向きにHTTPSにする必要はなく、HTTPSで
も接続できるという状態にできれば恩恵を受けることができるようです。
しかし、HTTPSにすることで、大きな順位の上昇を狙うことは出来ませ
んが、『塵も積もれば』という意味ではキーワードの相乗効果を得ること
で、全体的には大きなアクセスアップに繋がると考えられます。

© INFINIX Inc. 64
SSL証明書の導入について
SSL証明書は、いろいろな機関が発行をしておりますが
左のロゴのように、RapidSSL, StartSSL, COMODO, GeoTrust, Norton, DigiCert と
様々あります。
現状どのグレードじゃないと検索順位に影響があるわけではなく、あくまでもWeb
サイトが暗号化されていてユーザーが安心して利用できるというユーザー目線に
たって評価をされているようです。
その為、無料のSSL証明書でも問題ありませんが、個人サイトではない場合は
RapidSSLやCOMODO等比較的安価なSSL証明書で運用したほうが良いと思われ
ます。
参考までに、これまでにHTTPSで検証したサイトはどれも無料のSSL証明書で他
サイトよりも比較的順位が上昇しやすい傾向にありました。

© INFINIX Inc. 66
タブ等隠れた動的コンテンツはインデックスされない
Googleは左図の様なタブでユーザー操作で切替が必要なコンテンツは、隠
れているものはインデックスされないという回答がされました。
これはGoogleが昨年4月よりJavaScript解析を開始してから見えないコンテ
ンツをインデックス, 評価しない傾向にある延長上にある措置と思われます。
実際に、目に見えない場所にあるコンテンツ(テキスト等)は、Webサイト上と
しても重要視されたコンテンツではないゆえ、インデックスやコンテンツ評価
の優先度が落ちるものだと思われます。
今まではHTMLソースから解析されるコンテンツにより検索順位の決定がさ
れてきましたが、よりユーザー目線で見た場合のWebサイトとして評価をす
るようになりました。

© INFINIX Inc. 67
コンテンツ評価の優先度低下の例
左図では、前面にポップアップで出る広告等の例になります。右図では、よく見かける年齢認証ページ等、どちらもJavaScriptを用いて前面に出すタイプで、
裏にあるコンテンツを隠してしまいます。
JavaScript解析が始まるまでは有効でしたが、いずれにしても『隠す』という扱いになる構造は避ける必要があります。
現在はまだ猶予を与えられているサイトも多く見かけられますが、今後どのタイミングでコンテンツの評価を下げてくるかわからない状況ですので、成るべく
リスクを回避できるように作りこむのを推奨します。

© INFINIX Inc. 69
Schema.orgにてパンくずリストのサポート
2015年6月12日に
https://developers.google.com/structured-data/breadcrumbs
にて、schema.orgをサポートしたと発表がありました。
しかし、6月末まではバグがありましたが、ようやく安定して
schema.orgでパンくずリストを使用することができるようになりました。
また、JSON-LDでリッチスニペットに対応が進められており、Google
は全面的にJSON-LDを勧めてきております。
しかし、ようやく安定はしましたが当分はData-Vocabulary.orgでの対
応も続ける為、そちらはキープしつつ、JSON-LDでschema.orgの記
述をする方法を取り入れてもらえればと思います。

© INFINIX Inc. 70
『MULTIPLE』による複数パンくずリストの対応
前項のURLにて、複数パンくずがある場合のマークアップ方法が記載さ
れております。
JSON-LDの場合は、<script type=“application/ld+json”>～</script>を
2つ記述するだけという比較的簡単になりました。
Data-Vocabulary.org の時は、spanの入れ子をする必要があり、ソース
コード的にも非常にわかりにくい構造が必要でしたが、schema.orgの対
応により、より簡素化されております。
また、RDFa Liteでの記述方法も記載されておりますので、これまで
RDFaでData-Vocabulary.orgを記述してきたものをRDFa Liteに置き換え
ることも出来る様になりました。

Googleに強い土台を作るためのマニアックＳＥＯ対策

Recommended

Recommended

More Related Content

Featured

Featured (20)

Googleに強い土台を作るためのマニアックＳＥＯ対策