SSL証明書を購入するときに注意をしないといけないのは「www]付きのドメインなのか否かである。SSL証明書発行局のブランドにより１つの証明書で「www付き」と「www無し」をサポートしてくれるものが中にはある。申請時点でwww.xxxx.comのようにコモンネームにwwwをつけた場合（あり・なしを双方サポート）するパターンがあるので申請時にどのコモンネームにするかはよく考えたほうが良い。以前はwww.xxxx.comだったがサーバ移転のタイミングでSSLにしてwww無しで行こうと考える場合は一番注意が必要だ。

つまりwww無しにしたとして、旧ドメインはwww付きであるためユーザの中には旧ドメインでアクセスしてくるものもいるだろう。それを取りこぼししないようにmod_rewriteを使ってwwwで来たものを無しに転送するといった手法は古くからある。しかし、SSLが絡んでくると複雑な状況になる。というのもSSLが付いているサーバアクセスではブラウザー側の挙動が転送処理をチェックする前にSSLのチェックを先に実施するパターンがあるからだ。

ここで発生する問題はwww無しでSSL取得したが、以前はwwwが付いていたのでそれをどうやって取りこぼしをしないように統合するかである。結論を先に言ってしまうと残念ながらSSL証明書はwww付きとwww無しの双方をサポートするSSL商品を購入するか、www付きとwww無しを個別に２つ購入するしかない。

その理由はブラウザー側にあり、SSLでアクセスするモードでは転送処理より優先してSSLチェックが発生するからである。chrome,opera,vivaldi等では転送前にSSLチェックは生じないがedge,safari,firefoxではSSLチェックが転送より先に発生するのである。つまり転送処理をいくら入れてもwww付きSSLがなかったり、wwwドメインがサイトに存在しないと「セキュリティに問題があるサイト」という判定になってしまうため転送まで行き着かないのである。

私ごとで恐縮ですが、たまたまフランスからコンタクトフォームからスパム投稿があった。
なんだろう？なぜだろう？と思いながらホームーページを調べていたら設定していたはずのGoogleのreCAPTCHAは効かなくなっている。

どうしてだろう？と思い調べてみるとContactForm7の最新版プラグインはreCAPTCHAのバージョンが上がっており、プラグインを更新した際に 以前のreCAPTCHA(v2)が使えなくなっていた。つまりreCAPTCHA(v3)を使いなさいということです。

どうやら再度、新規登録をGoogleのreCaptcha登録サイトで行わないと利用できない。そこで登録した際の「サイトキー」と 「シークレットキー」が発行されるのでそれをContactForm7に登録しないといけないようになっている。

またGoogleのreCaptcha登録サイトで案内されてるJavascriptの埋め込みコードを自サイトへ２種類登録する必要がある。 コンタクトフォーム７で作成したそれぞれのプロファイルの入力HTMLコードの先頭に埋め込んでおけば良いだろう。下記の様なものを埋め込む。

実は、もう一つ盲点があってContactForm7にGoogleのreCaptchaのチェック画像が以前はあったと思うが、今回のリリースで不要になった。 そのためreCaptcha(v2)で使っていたContactForm7の埋め込みタグは不要になりました。 知らずに、どうやったらreCaptcha(v3)が使えるのか１時間ほど悩んでしまった。そのかわり右下にGooglenoの安全マークアイコンが出るように なりました。

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で入っています。

例えばWORDPRESSやフレームワークで送信用プラグインを導入しコンタクトフォームを作ろうと思った時に直接のローカルサーバのSMTPではなく外部のメール送信サーバを使うような場合はこの問題に遭遇するかもしれません。

エラーの例

ターミナルから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用で分けて作るというのもありかもしれません。