Google Search Consoleでクローラのクローラエラーの箇所を見ると「404 Not Found」が出ていることがある。これは文字通りファイルがありませんという意味のもので、ファイルが無かったからGoogleがペナルティを与えるという類のものではありません。しかし放置すると確実に順位に影響が出てきます。

通常は、「修正済み報告」ボタンでエラーが出た箇所をポチポチやってGoogleに認識させるのですが、エラーが消えたものが頻繁に先祖返りする傾向があります。少ない場合は無視するのですが、大量にあるお客様の場合は間違いなくGoogleの誤検知なのですが直す手立てが無いものかと実験を行っていました。

404エラーは通常放置すると、その状態が長く続くとGoogle側がファイルが存在しなくなったのでインデックス情報から消去するというプロセスになっています。企業や商売している者にとっては１ヶ月単位で消去する記事は当然存在します。キャンペーンや売出し情報、季節の商品だったら短いタームで終える記事（ページ）はあるのは当然です。そうすると大量にクローラーエラーのところに404 not found情報が堆積します。そこで無くなったのが正しい場合の場合どうするかですが、通常静的ページだとWEBサーバが404のhttpコードを返却しスムーズにクローラが認識しエラーは収まります。

一方、プログラミング言語で作った仕組みの場合、ソフトウェア「404 Not Found」を出力するページを生成して配置します。しかし、この仕組みが欠如してる確率が多く、ユーザビリティを考えて他のページに転送したり、そのページで検索できるようにしているケースが多いです。ユーザビリティ考慮だけではなくGoogleのクローラ考慮も実際には必要であることに気づいていません。

つまり、ソフトウェア「404 Not Found」の場合、大多数がhttpコードの404を吐き出していないケースがあります。この場合httpコードの404ヘッダーを返すようにソフトウェア「404 Not Found」を作ります。

WORDPRESSやPHPのプログラムでできている場合の404コード返却

phpの場合、ヘッダ関数を使用します。

これをWORDPRESSなら404.phpの先頭に挿入すればOKです。オリジナルでPHPや他言語で作っているならNot Found処理用のページテンプレートに該当言語のヘッダ関数を使用して「http 404 not found」含めてください。これでGoogleが認識してくれる確率があがります。

それでも404エラーが消えない場合

このケースは実際のところ多いです！　解消するためにはどうするかなのですが410を返却するという方法があります。調べてみると過去に鈴木謙一さんのブログでGoogleは404と410を区別するというのがあり、実験してみると410を返すようにしたところ404 エラーの先祖返りがなくなりました。

410と404の違い

鈴木謙一さんのブログを抜粋すると

404と410はどちらもページが表示されないことに変わりはないのですが、厳密に言うと意味が違います。


404は“Not found”でファイルが「見つからなかった」ことを表します。
たいして410は“Gone”でファイルが「なくなった」ことを表します。


404はURLの打ち間違いやファイルのうっかり削除で意図しないエラーかもしれません。
一方410はサイト管理者が意図してページを削除したときに返すエラーになります。

ホームページからメールを送信する仕組みを作る場合、専用サーバで構築するとよくありがちなissueは、「permission denied」が出ること。つまりsmtp送信非許可ということなのですが、通常このようなエラーはsmtpプロトコルでは発生しません。これがでたらセキュリティの何かに引っかかる問題があるということが推測できたら正解です。ずばりインストール直後のLinuxはSELINUXが有効になっているはずで、望ましいのはこれを有効にしたまま許可を出す設定をする事です。SELINUXではWEBサーバからメールを送信する処理に制限がデフォルト値OFFで入っています。

エラーの例

ターミナルからrootで下記を実行しOFF設定になっていたらONになるようフラグを立ててください。

以上で再度試行して頂ければ動作するはずです。めでたしめでたし！

アノテーションとはなんぞや！という方もおられるでしょう。グーグルのSEO上、最大の関心どころは重複行為です。同じコンテンツを大量に作ってかさ増しする輩が多かったため重複を重要視してチェックをしています。その中で重複の中の１つの基準にPCコンテンツとスマホコンテンツの関係があります。

PCをメインインデックスとした旧メタタグアノテーション設定

つまり、PCコンテンツとスマホコンテンツが独立して存在するなら、同じ内容のデータが２つ存在することになります。何もしなければ重複とみなされ評価が低くなるのです。それを回避するために設定を行うのですがそれをアノテーション設定と呼んでいます。

例）PC URL：https://www.example.com、スマートフォンURL：https://www.example.com/mobile/の場合

【PC側】

【スマートフォン側】

アノテーション設定は片方にはこちらが本家本元のコンテンツ、もう片方には付随するコンテンツという感じでメタタグを埋め込みます。

今まではPCコンテンツには付随するURLとしてスマホのURLを案内していました。一方スマホにはPCが本家本元のコンテンツですよということでPCのコンテンツURLを案内していました。

ところが、一昨年からグーグルがMFIを実施するということで、世の中のアクセスの主体がスマホになってきたのでインデックス情報はスマホの方から抽出すると言うことを宣言したのです。その猶予期間が今年２０１８年なのですが今までゆっくり進めてきたのが２月の後半で拍車をかけるようなアナウンスがあり早く対応しないといけない状況になってきました。

モバイルファーストインデックス対応

つまり、今までのアノテーションの設定をPCとスマホ逆にしないといけなくなりました。付け替えが一杯あると大変ですね。
でもレスポンシブでサイトを作っている方は安心です。何をする必要もありません。PCもスマホも同じコンテンツで変形するから同一としてGoogleから見えます。尚、下記はモバイルファーストインデックスにするためにメタタグのアノテーション設定を逆にした例です。

※2018/03/26追記：最終的には、GoogleとしてはMFI対応を認識していないユーザを救出するためかと思われますが、MFIでPCとモバイルが別ページの場合、alternateとcanonicalは従来の形のままで内部的に置換処理をしてくれるようです。本来は逆になるべきですが、既存の形のままで正規化して置換をGoogleのDB側で行うため何もしなくても良いようです。ただ、現在その処理は施行されていないので早くから順位のアドバンテージを取るならやはり置換はやったほうがいいのかもしれません。

例）PC URL：https://www.example.com、スマートフォンURL：https://www.example.com/mobile/の場合

【PC側】

【スマートフォン側】

WORDPRESSでPCコンテンツのみの方はアプローチ方法が２つあります。レスポンシブ化を進める方法とデバイスプラグインでレスポンシブのように処理をする方法があります。デバイスプラグインはテーマを２つスイッチする方法でレスポンシブのようにコンテンツを同一視させることができます。
いずれかの方法を選択して対処を行いましょう。

【参考：デバイスプラグイン】

https://ja.wordpress.org/plugins/multi-device-switcher/

注意事項

モバイルファーストインデックスは単純にメタタグをリバースするだけでは不十分なケースもあります。というのもPCのコンテンツとスマホのコンテンツがイコールのページを保有しているとは限りません。よくあるケースはスマホのほうがページ数が少ない場合があります。そのような場合はどうするべきか対策が必要ですね。足りないページを作るというのが正解なのかもしれませんが、sitemap.xmlでスマホ用とPC用で分けて作るというのもありかもしれません。