Yahoo seo Google > Google seo 2016年10月~ > データの逆戻り現象はパンダアップデートの更新が原因ではないか?

データの逆戻り現象はパンダアップデートの更新が原因ではないか?

<データ ハイライター>でYahoo seo GoogleのURL調査を継続しているが、データが逆戻りしているかのような現象を発見した。
この逆戻りはパンダアップデートの更新が原因ではないだろうか?
調査しているのは旧フィーチャーフォン用URLである。
より具体的には「」にある画像で紹介した、旧フィーチャーフォン用の“form”“res”“tb”のURLである。
これらのURLは1月14日辺りから調査を開始し、“form”“res”“tb”のURLも「」で紹介したように3つのタイプに分類された。
正規URLのコンテンツを表示させるケース。
改造された旧フィーチャーフォン用のコンテンツを表示させるケース。
改造前の旧フィーチャーフォン用のコンテンツを表示させるケースである。

再調査を開始した理由は、これらのURLがどう変化しているかを知ることであった。
期待した結果は、「URL が見つかりません」と表示されることであったが、実際は期待した通りになったURLは少なく、それよりも愕然とさせられたのが前回調査との相違であった。
それは「改造された旧フィーチャーフォン用のコンテンツを表示させていた」筈のURLが「改造前の旧フィーチャーフォン用のコンテンツを表示させる」からであった。
つまりは改造後のデータを表示させていたものが改造前のデータに逆戻りしているということである。

この逆戻りがもたらすマイナスは、旧フィーチャーフォン用URLを再出現させてしまうことだ。
前回調査で「改造前の旧フィーチャーフォン用のコンテンツを表示させる」URLはFetch as Googleで送信し、データを改めた。
つまりその時点でYahoo seo Googleブログからは旧フィーチャーフォン用URLを一掃した筈だった。
それにも関わらず、今回調査で発見した逆戻りで、再度、旧フィーチャーフォン用URLを出現させてしまった。
だからこそ<データ ハイライター>で調査をし、そうしたURLを発見次第、Fetch as Googleで送信している。

この単調な作業を行いながら「なぜデータが逆戻りするのか?」を考えていた。
その時、ふと思い出したのが下にある私のツイートである。日本時間で1月23日の朝、Search Consoleで上記スナップショットの相違を確認したのである。

何度も書いて恐縮だが、パンダアップデートやペンギンアップデートが導入されてFC2は対応を何度も変えた。
その詳細は「パンダアップデートの解決に二転三転してはいけない」で書いた通りである。

この対応には殆ど全て301リダイレクトが絡んでおり、それはパンダアップデートの白黒をハッキリ付けさせる目的のものであった。
そのパンダアップデートの白黒つける対策が結果となって現れたのがSearch Consoleのスナップショットだとしたら、どうだろうか?
つまり1月23日のパンダアップデートのインデックス入れ替えが起こる以前に<データ ハイライター>調査で見たデータは入れ替えにより消えてしまった。
言い換えればデータが逆戻りしたのではなく、インデックスが入れ替えられたために「消えてしまった!」というのが、私の推測なのである。

実際このYahoo seo Googleブログはドンドンと<内部リンク>データに表示されるURLが減少していった。
その主たる原因は「」で報告したFC2の仕様変更である。
これを境に<内部リンク>からURLが徐々に消えていった。
つまりデータが消えてしまったのである。

これと同様に先の旧フィーチャーフォン用コンテンツの逆戻りを考えた時、逆戻りではなく、更新されたデータが消失したという考え方が芽生えた。

<内部リンク>のデータ喪失に301リダイレクトが絡んでいるとすると、旧フィーチャーフォン用コンテンツの件も301リダイレクトが絡んでいるのではないか?
その時、先のツイートのスナップショットが思い出された。
“net”と“us”のトップ画面が同一なのは同一のコンテンツを有しているからだろう。
それに対し“com”が異なるのは異なるコンテンツであるからであり、スナップショットを取得した時の日時が“net”や“us”と異なるからである。
現在のFC2のレスポンスは“net”→301リダイレクト→“com”と、“us”→301リダイレクト→“com”であり、それから考えると“net”と“us”のトップ画面が同一になるのは考えられないのであるが、実際は同じなのである。

これ以前のスナップショットは“com”と“net”が同一で“us”だけが異なっていた。
つまり“com”と“net”のコンテンツが同一だったわけである。
それを当てはめて考えてみると、「改造された旧フィーチャーフォン用のコンテンツを表示させていた」筈のURLが「改造前の旧フィーチャーフォン用のコンテンツを表示させる」のは“com”と“net”のコンテンツが同一ではなくなったからではないか?
「改造された旧フィーチャーフォン用コンテンツ」は“net”ドメインのもので、“com”のものではなかった。
だからこそパンダアップデートのインデックス入れ替えによって“com”から“net”のコンテンツが消え、まるで逆戻りしたかのように“com”のコンテンツが改造前のコンテンツを表示させるのである。

もう1つ、このように推測した事例を紹介しよう。

この旧フィーチャーフォン調査に先立って既存の記事URLをFetch as Googleで送信していた。
しかし週辺りの制限でリクエストを拒否されたので、幾つかのURLをを利用して送信した。
するとそうやって送信した「」の記事が“net”ドメインのサイトコマンドで表示されたのである。

この記事が書かれたのが2011年1月20日であり、書かれた当時はパンダアップデートやペンギンアップデートのない、穏やかな時期であった。
だがパンダアップデートやペンギンアップデートが出現以降でいえば、先の「パンダアップデートの解決に二転三転してはいけない」に即せば、この「ソースの記述は絶対パスが良いらしい」は“net”から“com”にリダイレクトされた筈である。
というのもFC2のリダイレクトを一番最初に報告したのが「」であり、つまりはこの記事の書かれた2013年1月27日以前の記事は“net”と“com”で重複していたからである。
つまり「ソースの記述は絶対パスが良いらしい」の記事は“net”と“com”で重複したからこそ問題だったのであり、だからこそ301リダイレクトで重複の解消を図ったのである。

今回、この記事が“net”のサイトコマンドに表示された原因はどこにあるのか?

この「ソースの記述は絶対パスが良いらしい」の記事は、Yahoo seo Googleブログの中でも評価された記事の1つである。
そのため、外部からのリンクも有り、この記事は“com”ドメインのURLで統一され<内部リンク>データにも記録を取り始めて以降欠かさず表示されている。
だからこそ“net”ドメインのサイトコマンドに表示されたのは、以前、“net”から“com”にリダイレクトされたという履歴が原因だろうと思われた。(参照記事「」)
履歴が表示されたのはパンダアップデートの更新で“net”と“com”が分離されたからである。

この関係は妊娠中の母子をイメージすると分かりやすい。
子供が母親の胎内にいる時は母子は一体である。
だが子が生まれ落ちた時から、母と子は分離され一体化は解消される。
別人格を持った2人の個体を考えれば“net”と“com”の関係は理解しやすいのではないだろうか?

“net”のサイトコマンドに表示された「ソースの記述は絶対パスが良いらしい」の記事は、URLは“net”ドメインであったが、キャッシュは“com”であった。
そして表示された4日後には“net”のサイトコマンドから消えた。

ここでパンダアップデート更新とスナップショットの件に再度触れておこう。
先に「“net”→301リダイレクト→“com”と、“us”→301リダイレクト→“com”であり、それから考えると“net”と“us”のトップ画面が同一になるのは考えられない」と書いたが、「」で報告した通り、Googleによるリダイレクトが実際に知られている。
つまりSearch Console内のスナップショットが同一になるのはGoogleによってリダイレクト処理されていることが想像出来る。

現段階では全てが推測である。

検索結果が逆戻りしたかのような現象は実際に逆戻りしたためだろうか?
それともパンダアップデートの更新によって逆戻りしたかのように見えるだけなのだろうか?
とにかく、これがスパムに関係した処置であることだけは確かなように思える。
「データの逆戻り現象はパンダアップデートの更新が原因ではないか?」の関連記事リスト

コメント

非公開コメント