こんにちは。

Googleのインデックスがcanonicalに従わないことがあるのはあるのですが、今回のケースは従って欲しいですよね。

まずは「?page=1468467000」のパラメータが付いてしまっている原因を特定する方が良いと思います。

プラグインやカスタマイズで心当たりありませんか？

もしくは計測関係で設定されたり、内部リンク、外部リンクにパラメータ付きのリンクがありますでしょうか？

Google検索で調べてみましたが、事例がないですね・・・。

「パラメーター付きのアドレスがインデックスされるのはおかしい」と正しいのかは別として聞いたことがあるので気になりました。

ページネーションなので、影響が少ないとは思います。これが記事本文だと、影響が出てきそうです。

Search Console　の　URLパラメーターで何か対処出来そうな気もするのですが、素人がいじくると危険な気もしまして・・・

確かに難しいですね・・・。ミスすると、危険もあります。

まずはパラメータが付いてしまっている原因を特定したいです。

今気づきましたが、httpでもアクセスできますね・・・。

これも今回の件とは関係なさそうですが、http→httpsに301リダイレクトをした方が良いです。

▼ここのトピックスで設定方法が書かれています。

https://wp-cocoon.com/community/cocoon-theme/%e3%81%b2%e3%81%a8%e3%81%a4%e3%81%ae%e3%82%b5%e3%82%a4%e3%83%88%e3%81%a7%e3%81%af%e3%81%a7%e3%81%8d%e3%82%8b%e3%81%ae%e3%81%ab%e3%82%82%e3%81%86%e3%81%b2%e3%81%a8%e3%81%a4%e3%81%ae%e3%82%b5%e3%82%a4/

教えていただいてありがとうございます。

まず「http→httpsに301リダイレクトをした方が良いです」の方がすぐに対処できそうなのでやってみようと思いますが、

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

を、Xサーバーのhtaccess編集に追記するだけで大丈夫でしょうか？

パラメーターが付いた理由は何もしていないのでどうしたらいいか悩んでいます。

重ね重ねすいません。

ページャーにパラメーターが付いたのは引っ越す前の「はてなブログ」の時から既にあったと記憶しています。

なので、プラグイン等ではなく計測関連でしょうか・・・・という考えは間違ってますか？

ただアナリティクスで特別に何か設定した記憶もありません。

変更したと言えばAMPのアイキャッチ画像を1200×675のサイズにすべてではありませんが変えたことぐらいです。

パラメーターが付いた原因を調べる方法が分からない場合はGoogleさんに「こっちですよ」と強引に正規URLしてもらう方法などございますか？

僕もあまり詳しくないのですが、

RewriteEngine On

がいるのではないでしょうか。

（僕もXサーバーを使ってますが、別の書き方をしています。）

必ずバックアップを取るのと、あと最後の行は改行しておいてくださいませ。

ページャーにパラメーターが付いたのは引っ越す前の「はてなブログ」の時から既にあったと記憶しています。

なるほど。はてなブログでは、パラメータが付くのでしょうか？

引っ越す前にインデックスされていたなら、そうなる可能性がありますね。

パラメーターが付いた原因を調べる方法が分からない場合はGoogleさんに「こっちですよ」と強引に正規URLしてもらう方法などございますか？

リスクもありますし、どうしてもやる場合は、Search ConsoleのURLパラメータか、301リダイレクトですね。

ありがとうございます。

リスクがあるなら止めといた方がいいですよね（涙）

困りました。どうしましょう。

原因を探る術もないので静観するしかなさそうです。

評価ががた落ちになる気もするので、パラメーター付きPageアドレスをインデックスさせなくてもいいのではないかと思ったのですが・・・

今日一日、同じような例はないかと朝からずっとネット上で捜していたんですがたなかまさんがおっしゃるとおり事例がない（涙）

もうちょい頑張って探ってみます。（質問じゃなくてすいません）。

ページャーにパラメーターが付いたのは引っ越す前の「はてなブログ」の時から既にあったと記憶しています。

これの、「はてなブログ」のURL例はありますか？
僕ははてなブログを使ったことがないので、詳しくは知らなくて。

パラメーターが付いた原因を調べる方法が分からない場合はGoogleさんに「こっちですよ」と強引に正規URLしてもらう方法などございますか？

それに対応するのがcanonicalです。
ただ、Cocoon自体canonicalがデフォルトで入っているのですが、Googleが採用しない場合もあります。
canonicalがしっかりと入っているか、実際の該当ページのソースコードを見ても、入っているようなので、ちょっとどうしようもないかも。

とりあえずですけど、パラメーターのついたページが倍ほどになって、サーバー側でエラーやら何らかの影響が出てますか？

GoogleBotが500番台を出してる。みたいなこと。

評価ががた落ちになる気もする

これもよく分かりませんが、クロールがうまくいっているかのほうが大事な気もするんですけど。

それっぽい参考リンクも置いておきますね。

Googlebot のクロール頻度の変更 - Search Console ヘルプ

https://support.google.com/webmasters/answer/48620?hl=ja

あとエラーログをチェックしたらいいと思いますけど、もしGoogleBotのIPが必要であれば、検索したら出てくると思います。

その結果も踏まえて、以下参考になりそうな詳細の案内ページリンクも置いておきますね。

重複した URL を統合する - Search Console ヘルプ

https://support.google.com/webmasters/answer/139066

パラメータ化された重複コンテンツのクロールをブロックする - Search Console ヘルプ

https://support.google.com/webmasters/answer/6080548?hl=ja

あと思いつくのは

https://twitter.com/jumpingknee

金谷さんのツイッターですけど、そこのリンクからGoogleの人に相談してみるのも良いかと思いますよ。

わいひら様、かうたっく様、たなかま様、ありがとうございます。

はてなブログはすでにすべて消去しているので例がなく申し訳ありません。はてなブログだったときに同じようなのを見た記憶があるだけで勘違いかも知れません。

canonicalが的確に入っているので、これは「Search ConsoleのURLパラメータ」をいじくるしかなさそうですね。

サーバー側でのエラーはありませんでした。

ただ、「Search ConsoleのURLパラメータ」をいじくる条件には満たしているのですがブロックする方法を読んでもさっぱり分からない（涙）

無知なもので最初の「いいえ」「はい」どちらを選択しいいかも分からず・・です（涙）。

もうちょい頑張ってみます。

無知なもので最初の「いいえ」「はい」どちらを選択しいいかも分からず・・です（涙）。

コンテンツは変わらないので「いいえ」になりますが、その前に、かうたっくさんがおっしゃる通り、オフィスアワーで聞いた方が良さそうです。

正規URLが選ばれない事例を社員の方に伝えることができます。（調べてもらえるかもしれない）

サイトのURLと、事例が起こっているパラメータ付きのURL、パラメータを付けた覚えはないが、はてなブログから移行している、検索結果に悪い影響があるか？　などを聞くと良いと思います。

個人的には、ページネーションということもあって、そこまで悪い影響はなさそうと思っています。

ただ、重複コンテンツが無条件に悪いと思い込まれている人もいるので、人それぞれですね。

あと、クロール バジェットがどのくらい大規模なら影響するかどうか分からないので、何とも言えない感じです。（この規模だと影響しない気がします）

▼クロール バジェットについて

https://webtan.impress.co.jp/e/2017/01/27/24899

たなかま様、

ありがとうございます。

根気よく頑張っているのですがやはり理解出来ないでいます。

先ほど、ウェブマスター オフィスアワーで質問させていただきました。

回答があることを願っています。

専門用語が多くて難しいですよね・・・。

ただパラメータでトラブルがあれば、その分パラメータについて理解ができるようになるので、知識が得られるメリットにはなると思います。

僕もパラメータ付きURLがインデックスされたことがあるので。

オフィスアワーは、いずれ回答があると思います。（直してもらえるかもという淡い期待も込めて）

https://www.youtube.com/channel/UCWf2ZlNsCGDS89VBF_awNvA

「追記」

最初、間違ってオフィスアワーではなくコミュニティの方で質問してしまいました。

Googleさんに怒られなければいいですが^^;

気長に待ってみたいと思います。ありがとうございました。

解決次第すぐに書き込みたいと思います。

ちなみにこのパラメーターはやはり「はてなブログの時、または、はてなブログからWordPressに引っ越した際に付いたもの」で間違いないようです。

ただ、他の人はみんな「除外」になっているんですけどね^^;。

コミュニティフォーラムの方でも、（具体的なアドバイスが得られるので）URLの提示が必要ですね。

コミュニティの方で

rel="canonical" は正しいのですが、rel="next"/ "prev" で指定している URL に ?

page=1557225900 が付与（実際には page パラメータをそのまま引き継ぐ設定が）されています。rel="next"/ "prev" 自体を削除するか、正規 URL で指定するように修正してください。

との回答をいただきました。

この場合はどうしたらいいのでしょうか、よろしくお願いします。

さすがですね・・・。

Cocoon設定のSEOタブに

分割ページにrel="next"/"prev"タグの追加

というのがあるので、外してみてください。（添付画像）

あと、SEOプラグインなどを使っていたら出てくる可能性があるので、HTMLソースのチェックが必要となります。

コミュニティの回答に変更がありました。

hrefも変更って書かれてましたね。

ちょっと僕にはページネーションでパラメータを除外する方法が分からないです・・・。

「rel="next"・rel="prev" 」と「次のページリンク」のURLクエリを削除するようにしてみました。
------------------------------------------------
https://github.com/yhira/cocoon
最新ファイルをダウンロードする場合は、上記ページのダウンロードボタンからzipファイルをダウンロードしてください。

FTPでのアップデート方法はこちら。
https://wp-cocoon.com/ftp-update/
------------------------------------------------

ただ、出来ればソースコードをエディターで見やすくするために、右クリック禁止プラグインを使っている場合は、無効にしておいていただけると助かります。

ページのrel="next" と rel="prev" に関しては、添付画像のようなパーマリンク形式にも対応する必要があるため、とりあえず元に戻しました。

サラッと見ましたが、SearchConsoleのフォーラム的なところで案内を受けて、インデックスされているかどうか。クロールされる条件が膨大でサーバーが500番台：アクセスが多すぎてアップアップして、サーバに負荷をかけている状態：になってないか。って事は平気ですかねぇ？？

ちょっと私も意味が分からない点があるので。一応。

結果的にindexされた状況：クロール数がそれで減っていればいいかもしれない。的な感じで思っただけですが

そもそも問題ないならそれはそれで、現状は平気なのかもですね！　？？？

質問内容をチェックされたわいひらさんが修正してくれてますね。

その結果がどうなるか、多少でも気長にチェックしてもらえたら、安心っぽいですね❦

トピック主さんの返信にて

ちなみにこのパラメーターはやはり「はてなブログの時、または、はてなブログからWordPressに引っ越した際に付いたもの」で間違いないようです。

なぜそう思われてますか？

はてなブログに聞いてみても良いとおもいます。

というのもインデックスされているhead内にある　タイトルタグ　ChromeやスマホのブラウザのタブにあるタイトルまでCocoonは反映されるので。

Cocoon設定あたりで設定されるものですが、それもインデックスページのタイトルにパラメーター付きタイトルになってたんですよね。返信時に確認したものです。

URLを検索すればでてきます。ただ、そんな検索は一般的にサイトを見る人は誰もしないとおもいますけど。

わいひら様、かうたっく様、たなかま様、今日は朝からずっと相談に乗っていただいてありがとうございます。

すいません。

いろんな専門用語を聞いて頭がパニクってしまい何て返事していいのか分からなくなってきてしまいました。「はてなブログ」と言ったのは同じPageパラメーターURLを見かけると全員（見かけた人前提ですが）が同じようにはてなブログから引っ越してきた人だったからです。軽はずみに発言してしまい申し訳ありません。

//*/a[@class="pagination-next-link key-btn"]/@href および rel="next" と rel="prev" で指定している URL に ?page=1557225900 が付与（実際には page パラメータをそのまま引き継ぐ設定が）されています。

っと結論付け、

「rel="next"/"prev"タグの追加」のチェックを外して最新ファイルをダウンロード」という対処方法で合ってますか？

出来れば以下のようなことをやっていただいて状態を見せていただけると助かります。

1. コピープロテクト（右クリック禁止）プラグインを無効にする
2. 高速化機能でソースコードを縮小化している場合は解除（HTML・CSS・JS縮小化の解除）
3. 「rel="next"/"prev"タグの追加」機能は有効化
4. GitHubのテーマファイルで親テーマをアップデート

わいひら様、ありがとうございます。

1. コピープロテクト（右クリック禁止）プラグインを無効にする
2. 高速化機能でソースコードを縮小化している場合は解除（HTML・CSS・JS縮小化の解除）
3. 「rel="next"/"prev"タグの追加」機能は有効化

こちらは簡単にできました。

GitHubのテーマファイルで親テーマをアップデート

無知な私にはすんなりできませんでした。m(_ _)m

23時から仕事ですので申し訳ありませんが明日試みたいと思います。申し訳ありません。

GitHubのテーマファイルで親テーマをアップデート

これなんですが、動作確認してみると「rel="next"/"prev"」でも「インデックスページネーション」でも、URLクエリを削除してしまうと、不都合が出てしまう恐れがあるので、双方とも元に戻しました。
なので、アップデートしなくても大丈夫です。

出来れば、こちらのページはまだ右クリックできないので、キャッシュプラグイン等のキャッシュがクリアになっていないのであればクリアしておいていただければ幸いです。
https://blog.netabare-arasuji.net/page/83/

僕も明日、以下と双方の動作をソースコードから確認してみようと思います。
https://blog.netabare-arasuji.net/page/83/?page=1468467000

//*/a[@class="pagination-next-link key-btn"]/@href および rel="next" と rel="prev" で指定している URL に ?page=1557225900 が付与（実際には page パラメータをそのまま引き継ぐ設定が）されています。

なるほど。そういうことでしたか。

あとパラメータがついたページのページネーションのリンク

a class="page-numbers" href="/page/83/?page=1468467000&paged=84"

なぜか、パラメータが増えてて謎（page=1468467000とpaged=84）。通常ページはそのようになってないので。

タグマネージャ・アドセンス（など設定ではなくidとかの文字列のみ）は問題ないようでしたが、ついでにオカシイ物を見つけてしまって。

otherアナリティクスのところ

script
src="h　ttps://pagead2.googlesyndication.com/pagead/js/r20191205/r20190131/reactive_library.js"

パラメータ付きだと。reactive_library_fy2019.js　となってる

src="h　ttps://pagead2.googlesyndication.com/pagead/js/r20191205/r20190131/reactive_library_fy2019.js"

ほかshow_ads_impl_fy2019.js

src="h　ttps://pagead2.googlesyndication.com/pagead/js/r20191205/r20190131/show_ads_impl_fy2019.js" id="google_shimpl"

相違点まで見てませんけど。謎すぎる。どまりです。（コードタグ追加編集）

https://blog.netabare-arasuji.net/page/83/

https://blog.netabare-arasuji.net/page/83/?page=1468467000

右クリックのコピーを禁止するjavascriptがcanonicalの上に書かれています。

このコピー禁止関係のプラグインが、Googleクローラーのレンダリングを邪魔している例を、何回か見たことあります。

不思議なことに、パラメータ付きのURLはコピー禁止が効いていません。

コピー禁止がレンダリングを邪魔している可能性が結構高いかも。

すでに解除したとのことですが、僕の環境ではまだ出てきます。

Cocoon設定のキャッシュ削除を試していただけますでしょうか？

わいひら様、たなかま様、かうたっく様、ありがとうございます。

「分割ページにrel="next"/"prev"タグの追加」はチェックを入れ、

右クリック禁止プラグインを解除し、

高速機能の縮小化も解除しました。

かうたっく様ご指摘の件はレベルが高すぎでさっぱりで申し訳ありません。どこかでおかしな設定をしているのかな・・・

Google Tag Managerの解析タグ（タグマネージャーID、AMP用）、

Google Analyticsの解析タグ

Google Search Consoleのサイト認証タグ

すべて設定してますけど、それは問題ないですよね^^;

私のはわいひらさんがチェックするとき、ついでに。って感じです。

アドセンス・タグマネージャのidをチェックしたのは、そこだけゴニョゴニョして悪さをしてるかチェックしただけです。でも大丈夫でした。

たなかまさんの

右クリックのコピーを禁止するjavascriptがcanonicalの上に書かれています。

このコピー禁止関係のプラグインが、Googleクローラーのレンダリングを邪魔している例を、何回か見たことあります。

これはまたわいひらさんが良い感じで画像をアップしてくれるかも？ ? ? ? 
ちゃうか…。。

ってか、該当プラグインを停止されてるので、みえないですね？？

どこかでおかしな設定をしているのかな・・・

Google Tag Managerの解析タグ（タグマネージャーID、AMP用）、

Google Analyticsの解析タグ

Google Search Consoleのサイト認証タグ

パラメータを付けるような設定をしたのかな？十も思ったんですが、正規ページは問題ないので謎なんです。

ちなみに

Google Tag Managerの解析タグ（タグマネージャーID、AMP用）、Google Analyticsの解析タグどちらか1つで大丈夫ですよ。2重カウントされるかと思います。

上まで行ってみるのが面倒なので
確認用アドレス

https://blog.netabare-arasuji.net/page/83/

https://blog.netabare-arasuji.net/page/83/?page=1468467000

すみません、キャプチャを取り忘れていました。

canonicalの上にコピー禁止のスクリプトが入っていました。（おっしゃる通り現在は取り除かれています）

sharonさん、Search Consoleからサイトマップの再送信をお願いします。

Google Tag Managerの解析タグ（タグマネージャーID、AMP用）、Google Analyticsの解析タグどちらか1つで大丈夫ですよ。2重カウントされるかと思います。

あわわわ、そうだったのですね。ありがとうございます。

Search Consoleからサイトマップの再送信をお願いします。

再送信しました。

右禁止プラグインは常にチェックしていて大丈夫だったんですが急になる事もあるのですね。

プラグインが邪魔しているだけだったら・・・それが原因だったらと思うと本当にお騒がせして申し訳ないと冷や汗かいてます。。。

?page=1468467000とつくことで、タイトルまで変わってしまうんですね。
https://blog.netabare-arasuji.net/page/83/?page=1468467000

ちなみに通常ページだとこんな感じ。
pageオプションに値が入っていると、WordPress自体そのようになる仕様っぽいですね。
タイトルが変更されてしまうので、重複ページとしても処理されないのかも。
https://blog.netabare-arasuji.net/page/83/

プラグインが邪魔しているだけだったら・・・それが原因だったらと思うと本当にお騒がせして申し訳ないと冷や汗かいてます。。。

それって、検証してみないと分からないと思います。

他にも似たプラグインを使っている人はいると思うので、まだ冷や汗まで行かないかも知れないですね。

その前にSearchConsoleサイドで質問した結果をチェックして様子見　するのが良いかもしれませんね。

その後、うんちゃらかんちゃら…検証してみたり…なのかもです。

って事で
Cocoon設定・seoタブにある　rel…
たなかまさんの案内をして様子を見るのが一番良いカモですね。

それ以外はインデックス←検索結果に出さない。ってのが現状良い気もします。

わいひらさん、チェック。感謝です！もしかしたら、わいひらさんの言う通りなのかも、しれないですね。
話を変えてしまってゴメンナサイでした(*- -)(*_ _)ペコリ

わいひら様、かうたっく様、たなかま様、

いろいろとアドバイスありがとうございました。感謝しています。

ここだけの話、パニクって涙を流しながらいろいろと調べていましたから。

「分割ページにrel="next"/"prev"タグの追加」チェックを外して

しばらく様子を見て何か変化がでたら書き込みたいと思います。

これで何も変化がなかったら、かうたっく様がおっしゃるとおりPegeパラメーターURLをインデックスさせないようにしてみようかと思いますが・・・。その時はその時でまた相談させていただこうと思います。

まずはコピー禁止のスクリプトを停止したことで、改善される可能性があるので、様子見ですね。

▼鈴木さんの記事によると、こちらはシンジケーションの話でちょっと違いますが、最初にクロールしてしまったことで、canonicalに従わないことがあるみたいですね。

https://www.suzukikenichi.com/blog/ex-googler-explains-why-google-ignores-rel-canonical-for-syndication/

hrefを修正すれば治ると思いますが、なかなか技術的に難度が高いですね。

もし、クローラーが悪い影響を起こすようでしたら、かうたっくさんがおっしゃるようにnoindexにするのもアリかもしれません。

この場合は、2ページ目以降のアーカイブが検索結果に出てきません。あまり2ページ目以降のアーカイブページに検索から来るのは少ないと思いますが最終手段ですね。

ただし、noindexでもクロールはされます。（頻度が減ります）

Cocoon設定・seoタブにある　rel…
たなかまさんの案内をして様子を見るのが一番良いカモですね。

 

それ以外はインデックス←検索結果に出さない。ってのが現状良い気もします。

自分で書いておいて何なんですけど

とりあえずcanonicalを有効にさせよう。その後はそれから考えてもいいんじゃないか。って話です。

でないと、原因がわからなくなるから。って意味で。

書き込んだあと、別のことをしていてふとした時、
勘違いされる文になってるかも。って思ってましたが、案の定。失礼しました。

「それ以外はインデックス←検索結果に出さない。ってのが現状良い気もします。」
これは正規URLのみインデックスされるんじゃないか。
正規ではないパラメータ付きのURLはGoogleがcanonicalを読んで理解してくれてインデックスされなくなる！気がするので試してみるのが一番❦って話です。

パラメータ付きをnoindex発言のように見えましたよね。その意図は全く持ってないです。現状は。って事でした。ゴメンナサイ。すぐ書き込めばよかったよねぇ…わたしっ ? ? ? 

「それ以外はインデックス←検索結果に出さない。ってのが現状良い気もします。」
これは正規URLのみインデックスされるんじゃないか。
正規ではないパラメータ付きのURLはGoogleがcanonicalを読んで理解してくれてインデックスされなくなる！気がするので試してみるのが一番❦って話です。

 

パラメータ付きをnoindex発言のように見えましたよね。その意図は全く持ってないです。現状は。って事でした。

すみません、僕の方がnoindexのことだと勘違いしていました。

現在、sharonさんのサイトのcanonicalは有効になっていて、それをGoogleが従ってくれないようです・・・。

どちらにしても、ちょっと様子見ですね。

たなかまさんに

僕の方がnoindexのことだと勘違いしていました。

いえ、私もオカシイと思ってたんです。トピック主さんがnoindexのチャレンジまで考えてたので、これは今スルーしてるほうが良いのに、時期的にもワチャワチャするのに、やっちゃった…って思った感じで

しばらく様子を見て何か変化がでたら書き込みたいと思います。

クロールされて認識できたら正規化されるはずだと思います。けど書き込み待ちっと❦

わたしがおかしな書き込みをしたせいで申し訳ありません。

クロールされてどうなるかまずは確かめたいと思います。

「分割ページにrel="next"/"prev"タグの追加」のチェックは外していいのですよね？

すいません、分からなくなっちゃって・・・・

いえいえ、こちらこそお騒がせしました。

「分割ページにrel="next"/"prev"タグの追加」のチェックは外していいのですよね？

これは、わいひらさんがチェックされているかもしれませんね。

1. 「rel="next"/"prev"タグの追加」機能は有効化

rel="next"/"prev"は、現在URLの発見には使われていないはずなので、どちらでも良さそうとは思います。hrefは確実にURL発見に使われています。

https://www.suzukikenichi.com/blog/google-no-longer-supports-rel-prev-or-rel-next/

https://www.suzukikenichi.com/blog/google-is-preparing-best-practices-for-pagination-without-rel-prev-next/

ベストな方法が分かっていても、WordPressの技術的な問題によって、なかなか実装が難しい状況です。

どこかで落としどころを見つけるため、引き続き見ていきましょう。

わたしがおかしな書き込みをしたせいで申し訳ありません。

クロールされてどうなるかまずは確かめたいと思います。

 

「分割ページにrel="next"/"prev"タグの追加」のチェックは外していいのですよね？

すいません、分からなくなっちゃって・・・・

誠実なご対応ありがとうございます。

SearchConsoleのフォーラム的な案内のあと、たなかまさんのがCocoonでやるべきを事をかいてくれてました。

そこのことはおっしゃる通りです！

外さないと始まらない。って個人的に思ってたんですけど、引用するのを端折った。確認しなかったので混乱になったかも。

ゴメンナサイです ? 

「分割ページにrel="next"/"prev"タグの追加」のチェックは外していいのですよね？

これは、わいひらさんがチェックされているかもしれませんね。

チェックが終わったのだと思ってました＾＾；

わかんないですけど、私が別件をついでに。、とタイトルタグなどついで要素を入れたんで、そうなったのかも。

アレコレ書き込みして、サクサク書き込みチェックをしていると、書こうと思ってた事を書き忘れしちゃんですよ。

rel="next"/"prev"は、現在URLの発見には使われていないはずなので、どちらでも良さそうとは思います。hrefは確実にURL発見に使われています。

SearchConsoleの案内間違いでしょうか？？？

今はないのであれば、面倒かも…

とりあえず、様子見て的な感じかな？？

個人的に思った状態と違った書き込みをしたので、ややこしくなってますが
今書き込みを休もうと思います。

めったにない、自分だけの時間をもてる数日間なので、誰もができる小さな事をやってをたまにはやってみたいと思います。

とりあえず、もとはといえば「?page=1468467000」のクエリ形式でどこかからリンクが来てるのが問題かと思います。
なので、添付画像のような形式のURLだった場合は、クエリを取り除いたURLにリダイレクトするという処理を書いてみました。
以下のコードを子テーマのfunctions.phpに追記する形で貼り付けてください。

//?page=1468467000といったクエリがある場合はクエリ削除URLにリダイレクト
add_action( 'wp',function () {
  $requested_url = get_requested_url();
  $removed_url = get_query_removed_requested_url();
  //pageクエリがある場合はリダイレクト
  if (preg_match('/\?page=\d+$/', $requested_url)) {
    redirect_to_url($removed_url);
  }
}, 0 ); 

※上記のコードは、Cocoonで定義している関数を利用しているので、Cocoonでしか利用できません。

PHPで処理を書く以外にも、.htaccessのリダイレクト設定でもやろうと思えば出来るのかもしれません。

上の返信のコードを子テーマのfunctions.phpに貼り付けた状態で、一度動作を見せていただければと思います。
もし、エラー等が出る場合は、記入した部分を削除すると元に戻ると思います。

わいひら様、かうたっく様、たなかま様、

本当にありがとうございます。

Cocoon Child: テーマのための関数 (functions.php)

に、以下を貼り付けました。21日からクロールがきていないのでそろそろきてくれるかな^^;

変化があったらすぐに書き込みたいと思います。

ありがとうございます。

//?page=1468467000といったクエリがある場合はクエリ削除URLにリダイレクト
add_action( 'wp',function () {
  $requested_url = get_requested_url();
  $removed_url = get_query_removed_requested_url();
  //pageクエリがある場合はリダイレクト
  if (preg_match('/\?page=\d+$/', $requested_url)) {
    redirect_to_url($removed_url);
  }
}, 0 ); 

コードまでいただけるなんて・・・とても勉強になります。m(_ _ )m

こちらのコードでリダイレクトされれば、この問題は解決すると思います。

僕のWordPressに対するスキル不足もあり、いろいろと提案がブレてしまいました。

分かりづらい部分もあったと思いますので、申し訳ないです。

一応補足として、僕は前回提示したコードは、以下の画像のパーマリンク形式だと、投稿・固定ページのマルチページなどで、不具合が出る恐れがあります。

上記パーマリンク形式以外の場合に、ご利用ください（URLクエリーを利用していないパーマリンク形式でご利用ください）。

たなかま様、

何をおっしゃいますか、アドバイスいただいて感謝していますしいろいろと勉強になりました。

これからもよろしくお願いします^^;

わいひら様、

パーマリンク設定でカスタム構造「/entry/%postname%/」にしていますので大丈夫だと思います。ご丁寧にありがとうございます。

いまのところまだ変化はありません。待ち遠しい^^;