Yahoo seo Google > Google Search Consoleとseo > ソースと一緒にインデックス送信出来るのはFetch as Google

ソースと一緒にインデックス送信出来るのはFetch as Google

新しいSearch Consoleの「インデックス カバレッジ」から「インデックスに送信」して送れるのはURLだけである。
Yahoo seo Googleで行った検証実験で、ソースと一緒にインデックスに送信出来るのはFetch as Googleである。
サイトマップの「保留」とインデックスの関係を検証するため、「」の記事で実験を行った。
その実験とは、本文中からリンクしたURLはFetch as Googleで送信しなくてもインデックスされるのか?というものであった。
具体的には「サイトマップとはインデックスさせたいURLのリスト」の記事本文から以下の画像のようなリンクをした。
2018年4月10日取得の2018年2月アーカイブページへのリンク画像
記事でも触れた通り、この2018年2月のアーカイブページはFetch as Googleで送信していない。
そして記事本文から内部リンクしたらどうなるのかを検証する目的でリンクを発した。
結論から報告すれば、私が望んだ形ではインデックスされていない。
つまり<構造化データ>にも表示されなければ<内部リンク>データにも未だ表示されていないということだ。

現状、このアーカイブページは今も「インデックス カバレッジ」において「有効」とされ、他のウェブページからの被リンクによってプライマリ インデックスされている証としてGooglebotが定期的にクロールしてキャッシュを更新させている。
seo的には何の問題もないインデックス状況である。
しかしサイトマップが「保留」である限り、私が望んだような形でインデックスされることはないだろうと推測している。
そのように推測するのは、Fetch as Googleで送信することの意味が理解出来たからである。

新しいSearch Consoleが出来て、インデックスに送信する方法は2つになった。
1つ目は旧来からあるFetch as Googleを理洋氏てインデックス送信する方法。
そしてもう1つが、「インデックス カバレッジ」からインデックス送信する方法である。
2018年4月10日取得「インデックス カバレッジ」のFetch送信画像
この2つのインデックス送信について、私は何の違いも感じていなかった。
だからFetch as Googleを選択せず、「インデックスに送信」からインデックス送信することが度々あった。
だが、ある時から、「インデックスに送信」を通じてインデックス送信したウェブページのキャッシュがなかなか更新されないようになった。
そこで更新されないページに限って再度Fetch as Googleを利用して送信すると、即座にキャッシュが更新されるのを確認した。
そこでようやく2つのインデックス送信の違いに思いが至ったのである。
それはウェブページのソースをインデックス送信させるのがFetch as Googleであり、「インデックスに送信」はウェブページのURLをインデックスに送信させるため、ということである。

本来、「インデックスに送信」を使用するのは、「インデックス カバレッジ」で「クロール済み - インデックス未登録」とされたウェブページに対してであろう。
何らかの原因でインデックスされなかったウェブページに対し、ウェブマスターが「インデックスさせたい」と考えるページを送信する際に使用する。
Search Consoleヘルプのにはこう書かれている。
クロール済み - インデックス未登録: ページは Google によりクロールされましたが、インデックスには登録されていません。今後、インデックスに登録される可能性がありますが、登録されない可能性もあります。この URL のクロールのリクエストを再送信する必要はありません。
重要なのはこの URL のクロールのリクエストを再送信する必要はありませんの部分だ。
つまり、そのURLには既にGooglebotがクロールしてソースをキャッシュしているので、再度、ソースのクロールをリクエストする必要はないということだ。
だからこの「インデックスに送信」を通じて送られるのはページのURLだけなのである。

実際に「インデックスに送信」で検証をしてみた。
「クロール済み - インデックス未登録」とされたウェブページを「インデックスに送信」で送信すると、次回の更新で「有効」に転じた。
しかしクロール日時は「クロール済み - インデックス未登録」にあった時と変わらず、キャッシュ内容も更新されていなかった。

送信されたのがURLだけであれば、そのURLが<構造化データ>に表示されないのは当然であろう。
<構造化データ>はウェブページのソースに記述されているからである。

ここで先のアーカイブページで考えてみる。
既にGooglebotにクロールされソースもキャッシュされているURLがなぜ、<構造化データ>に表示されないのか?
それはサイトマップが「保留」されていること、さらに今までに1度もそのアーカイブページをFetch as Googleで送信したことがないからであろう。
実際、サイトマップが「保留」であっても、SSL化してからエントリーされた記事ページはFetch as Googleで送信することによって、<構造化データ>に表示されるからだ。
サイトマップが「保留」されている状況下で、Fetch as Googleを利用してURLを送信することは、サイトマップにそのURLを記載するのと同様の意味合いがあるのだろう。
つまりウェブマスターがインデックスさせたいURLを明確にするという意味である。

明確にするのは他に存在するURLから差別化するためである。
つまり「インデックス カバレッジ」で「有効」とされたURLは物理的リンクである。
そのドメインでアップされたウェブページに記載されたリンクから、リンクとして「有効」と判断されたURLが表示されているだけである。
その物理的なリンクに対し、ウェブマスターが検索対象とさせたいURLと、それに対するリンクこそseo的リンクと呼べるだろう。
こうしたリンクを私は“リンクの輪”として書いてきた。(参考記事「」)
だが今は“リンクの輪”とは呼ばず、これこそがエンティティなのだと理解している。
つまりseo的リンクで結ばれることによって、そのドメイン全体はあるエンティティによって包括されることになるのである。

」の記事に則せば、Yahoo seo Googleは“seo”のエンティティで包括されるだろう。
そしてこの“seo”のエンティティで包括されるためにも、インデックスされるべきURLは選別されなければならないのである。
「ソースと一緒にインデックス送信出来るのはFetch as Google」の関連記事リスト

コメント

非公開コメント