ネット上のアクセスボリュームをUPさせ効率の良い集客をご提案します。

カテゴリー「wordpressテクニカル」の記事

GSで「404 Not Found」が消えない場合の対処。410を使う。

 / SEO関連, Wordpress, wordpressテクニカル, トピックス, ノウハウ


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



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



404エラーは通常放置すると、その状態が長く続くとGoogle側がファイルが存在しなくなったのでインデックス情報から消去するというプロセスになっています。企業や商売している者にとっては1ヶ月単位で消去する記事は当然存在します。キャンペーンや売出し情報、季節の商品だったら短いタームで終える記事(ページ)はあるのは当然です。そうすると大量にクローラーエラーのところに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はサイト管理者が意図してページを削除したときに返すエラーになります。

WEBからメール送信(SMTP)する際に「permission denied」が出たときの対処

 / Linux Tips, Security Tips, Wordpress, wordpressセキュリティ, wordpressテクニカル, テクニカル, トピックス, ノウハウ


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

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


エラーの例

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

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

アノテーション設定(モバイルファーストインデックス対応)を設置

 / SEO関連, Wordpress, wordpressテクニカル, テクニカル, ノウハウ


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



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

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

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

【PC側】

【スマートフォン側】



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



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



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



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

つまり、今までのアノテーションの設定を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コンテンツのみの方はアプローチ方法が2つあります。レスポンシブ化を進める方法とデバイスプラグインでレスポンシブのように処理をする方法があります。デバイスプラグインはテーマを2つスイッチする方法でレスポンシブのようにコンテンツを同一視させることができます。
いずれかの方法を選択して対処を行いましょう。

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

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

注意事項

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

サイトの設定情報をhttps仕様に変更 WORDPRESS (ログイン情報、メニュー情報、プログラムのパス等)

 / SEO関連, Wordpress, wordpressテクニカル, テクニカル


サイトは必ずしも静的ページで作られているわけではありません。プログラムで構成されていればその中にもファイルやリンクのパス名が入っています。それらを書き換えないとhttps化の動作ができない場合もあります。やはり、WORDPRESSもhttps化を設定やデータベースの中身のレベルで書き換えが必要です。フレームワークも同様ですし、オリジナルのプログラムもそうなると思います。作業を行う前に必ずコンテンツ、プログラム、データベースをバックアップして切り戻しができるようにしてから作業を行いましょう。

尚、今回はWORDPRESSでのhttps化に特化して説明したいと思います。

WORDPRESSのhttps化方法

https化する方法としてざっくり3種類考えられます。どの方法がいいか!?というよりもどれが最短でできるか?という観点で私はやっています。

  • https化プラグインを使う。設定の中にあるパス名を書き換える。
  • WORDPRESSのデータベースの中をhttpからhttpsに置換する。
  • DB置換もしくはxml形式で記事をエクスポートして、新規にhttpsでWORDPRESSを設置してからインポート、設定をやり直し。

上記の方法では、間違いなくhttps化プラグインが一番簡単です。でも、正直いうとどの方法も完璧ではないので最短でできる方法から試して駄目だったら次の方法という感じでやっています。



https化プラグインで有名なのは「Really Simple SSL」です。これは簡単にいうとプラグインで内部のhttpを正規化表現か何かで引っ掛けhttpsに置換しているのだと思います。複雑なプラグインやテーマを使っているならまずは、これでやってみて様子見がいいと思います。



2つ目のDBの中を置換する方法ですが、これは私がよく使っている方法です。直接MySQLでクエリー行で置換を行うケースとSQLファイルにして吐き出したテキストを置換する場合があります。サイトのプラグインやテーマ、カスタマイズの状況を把握してやり方をチョイスしています。

【置換SQLサンプル】

下記の3つのテーブルを置換すると良いと思います。



DB置換ではwp_postsとwp_optionsに限定して置換をかけたほうが良いです。その他のテーブル置換を行うと概ねWidgetやテーマ、プラグインの設定が飛んでしまうケースが多いです。置換後にSSL化でWEBサーバ起動し、その後にWPへログインし設定パネルへ移動しhttpをhttpsに手動修正してゆく方法だとうまく処理できる場合が多いです。DB上で変換しないで、管理画面>ツールにあるエクスポート機能で投稿、固定ページ、カスタムポストタイプのデータを事前に取っておいてインポートする方法があります。カスタムポストタイプだけ特殊な場合があり、うまくエクスポートできない事もありますが、事前にデータベースをバックアップしておけばやり直しができるので安全に試行してください。



3つ目の方法は無難な方法です。確実に再構築できると思います。https仕様でWORDPRESSを新規インストールし、後から記事データをDBレベルで流し込むかxml形式で流し込みます。widgetやプラグイン、サイトの設定は予めレプリカサイトを作り閲覧しながらコピーするやり方、もしくはテキストに設定をコピペしてそれを流し込んでゆく方法があります。時間が多少かかりますが確実な方法です。

https化で出てくる問題(https化した途端にmod_rewriteが効かなくなってしまう)

 / Linux Tips, Wordpress, wordpressテクニカル, トピックス, ノウハウ


Google Chromeの7月リリースバージョンでいよいよサイトのALL SSL化が始まる。
これによりhttpに対応していないサイトは「このサイトは安全でない」の画面が出てしまう。今でも
稀に見ることがある画面ですが、あの画面がでてしまったら当然誰もクリックor タップしないでしょう 。

ということでSSL化をしなければ行けないわけだけど、もう一つこれには考慮が必要なことに気づいた。
スマホとPCコンテンツを分離して作成している場合はアノテーション設定が必要だが、モバイルファーストインデックスも
開始宣言(2/21)が出ているし、何よりもアノテーション設定でURLをhttpsに変更しなければならない。

※レスポンシブで制作している場合は気にする必要はありません。WORDPRESSでデバイスプラグインを使っている人も問題なし

ということでSSL化をやってみると色々な新規顧客である特有の問題が出た。
一番ハマったのが、「https化した途端にmod_rewriteが効かなくなってしまう。httpのときにはmod_rewrite使えたのに!」という現象のサーバが幾つかあった。
つまりWORDPRESSなどではカスタムパーマリンクが使えなくなってしまう現象に遭遇しました。

原因を調べるために、約1日考え込み実験をしまくりました。
や~、これは気が付かなかった。httpd.confを普段触らずVirtualHostでサイト定義するから頭がそちらに向かなかった。
なんとhttpd.confを調べたら下記のようになっているではないですか! なるほど、それではTOPからその設定になっていると
下位で設定したコンフィグは無視されますね!

httpd.conf 修正前)

httpd.conf CentOSの場合修正後)

apache2.conf Ubuntuの場合修正後)



apacheを再起動してめでたくmod_rewriteがSSLで使えるようになりました。
上記の設定はDirectoryディレクティブを使用しているため、適切に範囲設定をその環境内で
望ましい設定を厳密には行う必要があります。上記のケースでは”/”でAllowOverride Allにしているためセキュリティを
高くするためにはフォルダーの範囲をもう少し狭めたほうが良い場合もあるので実験して良いバランスの設定を考慮スべきと思います。

他にも、https化で出てくる作業が多いのでメモをしておきます。

https化で遭遇する付帯作業

  • Google Search Consoleにhttpsでサイト登録が必要
  • 旧httpアドレスがインデックスされたり、他サイトと連携している場合はhttpアドレスからhttps転送設定が必要
  • 転送設定をjavascriptでやる場合は注意が必要。コンバージョンが拾えなくなる可能性がある。リファラーを追加する設定が必要かも
  • Google Analysticsの管理画面でプロパティ、ビューのURLをhttpsに切り替える。ビューのコンバージョンURLも変更。
  • sitemap.xmlをhttpsのアドレスになっているかチェック、なっていなかったら作り直し
  • WORDPRESSのプラグイン経由でanalysticsを設定、取得している場合は再設定が必要になる場合が多い

TOPへ戻る

AGA 成長因子