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

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

CentOS7/CentOS6 共通h2o Web サーバのインストール with WORDPRESSで動かしてみる。

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


h2oサーバの導入の動機

h2oを使ってみようと思った理由はHTTP/2.xで通信できることかな。最近のGoogle検索順位は早さも大切な評価ウェイトをしめているためサイトの速度アップは重要なことです。
このHTTP/2.xのプロトコルはHTTPS通信において表示速度を向上させ並列してリクエストを処理できるため、表示速度が向上します。
Nginxも早いのですが、H2OはそのNginxを凌ぐ早さで表示できるようです。

h2oのレポジドリーの追加

h2oのインストールはCentOS7/CentOS6で共通です。基本はyumのレポジトリーに以下の記述を追加し保存するだけでyum経由でレポジトリー からのインストールが可能になります。

h2oのインストールと起動

h2oを実際にyumを使ってインストールし、起動する手順になります。

ユーザh2oの作成とドキュメントルート作成&WORDPRESSの設置

SSL & WORDPRESSを動かす際のコンフィグレーション例(h2o.conf)

今回はSSLを使ってh2o環境でWORDPRESSを動かすケースのh2o.confを挙げてみたいと思います。
let’s encryptを使ってSSLライセンス取得し、実験してみました。Let’s Encrypt取得のやり方はここ
ドキュメントルートに/opt/html/content1として、実行ユーザはh2oユーザを新たに作り設定しています。
nginxにも似ている書き方にも感じますが、インデントで設定の範囲がきまるので注意しましょう。

おまけ:ソースからのh2oコンパイル

CentOS6.10のデフォルトのgccバージョン(4.4.7)では宣言エラー(同じ関数名で異なるタイプ宣言)が出てしまいました。しかしHomebrewで導入しているgccのバージョン(5.5.0)では 問題なくコンパイルが完了しました。gccバージョン毎のプロトタイプ宣言の解釈と処理の違いがあるようです。

ホームページの高速化手法

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



ホームページの高速化の意義

現在のグーグル検索順位を決定する基準の一つにホームページの高速表示は不可欠だ。表示が遅くて待たせることはユーザビリティとして適切ではないとグーグルは考えている。その他にも見た目のデザインやコンテンツの確かさ、有益な情報が入っているかが重要な順位を決める要因になりうる。

ホームページ高速化の優先順位

とりわけSEOとして考えていくなら第一にホームページの表示速度が重要で尚且つ、スマホの表示速度を優先度上げて考えるべきだ。理由として今の一般ユーザのアクセスの大半はスマホから来ているからなのです。 高速化の作業優先度を挙げるとしたら以下のような感じになるでしょう。
  1. スマートフォンの高速化
  2. 画像の圧縮
  3. javascriptの圧縮
  4. CSSの圧縮
  5. DNSの応答高速化
  6. サーバのキャッシュと転送の圧縮処理
  7. ホスティング高速化

スマートフォンの高速化

スマートフォンの高速化は第一に画像の調整につきます。PCでは画像のサイズを気にせずとも、スマホでは様々な場所へ移動してしまうため、回線状態の悪いことも想定して遅い速度でも閲覧できるよう画像の最適化は重要です。
画像はサイズも大切ですが画像形式、圧縮の技術を考慮するべきです。さらに画像のサイズをPC、スマホ、タブレットで変えて準備すると高速に表示できるはずです。レスポンシブならmetaタグでviewportを指定してサイズに合わせたCSSを読み出すか、あるいはcssファイル側で@media only screen and (max-device-width : 480px)のようにデバイスのスクリーン幅に合わせて変形を決めることができます。
WORDPRESS等のCMSではこのような画像を自動で間引いたり、最適にCSSを調整してくれるpluginがあります。このようなプラグインを使ってPC用画像とスマホ用画像を別々に分けて作るのは大変良いことです。

画像の圧縮

主な画像最適化プラグインを下記に案内します。導入して使ってみてください。無料で使えるものもかなりありますが、概ね数に制限があります。ページ数だったり、画像の数などです。
また重要なのは、設定の際に他のプラグインでやっている機能を重複しないようにしてください。同じ処理を2回、3回やっても無駄なので。むしろ遅くなります。またキャッシュも設定を変更したら 一度キャッシュクリアしてから速度を測定しましょう。そうしないと古いキャッシュで速度測定することになります。
  1. Compress JPEG & PNG images
  2. WP Smush
  3. EWWW Image Optimizer

主なキャッシュプラグイン

キャッシュだけではなくHTML,CSS,Javascriptを圧縮したり、統合化をしてくれるものもあります。
  • Autoptimize
  • Powered Cache
  • W3 Total Cache
  • WP Fastest Cache

サーバの転送の圧縮処理とキャッシュ制御技術

Apache WEBサーバの転送はgzipで圧縮して転送を行うことが可能です。Apache2.4以前のバージョンではmod_deflateモジュールを使ってAddOutputFilterByTypeでmimeフィルターする方法が途中まで主流でしたが既に廃れたやり方と言われています。
つまりmod_filterを使って圧縮することがApacheからも推奨されています。尚コンテンツ圧縮は転送量が減る反面、CPUの処理は増えるため、ボトルネックがCPUの処理能力の場合は逆にレスポンスが低下します。また、Apache2.4バージョン以降ではmod_filterを使うことが大前提でアナウンスされています。
結論を言ってしまうとどちらのバージョンでもmod_filterでFilterProviderでコンテンツタイプをフィルターして使うのですが若干記述に違いがありますので注意が必要です。
双方の処理ではDeflateCompressionLevel による圧縮レベルが指定できますが現実には、一番低いレベルの”1”で十分であります。レベルを上げても圧縮率が大して変わらないためCPUに余計な負荷を与えてしまい全体でみるとマイナスになってしまうからです。

Apache2.4以下の場合(つまりApache2.2)

Apache2.4以上の場合

上記を短くまとめると以下のようになります。

<<注意点モジュールの確認>>

下記のモジュールが予めコメントが外れていることを確認しましょう。 以上の記述とチェックが終わったらWEBサーバを再起動して圧縮の確認を行ってください。 WEBサイトの圧縮レベルを確認するサイト

キャッシュの処理

ブラウザ側にキャッシュをさせるタイマーをサーバー側で設定できるのがmod_expireになります。あくまでもキャッシュなので 必ず1回目のページアクセスは遅いということを理解しておきましょう。タイマーが切れたタイミングでWEBサーバにコンテンツを取りに行きます。
尚、予めmod_expireモジュールのコメント外れていることを必ず確認してください。

DNSの高速化とサーバホスティングの高速化

最近のクラウド、VPSなどの専用サーバホスティングは高速DNSサーバを備えているケースが多く、自前でDNSを用意するよりもいいかもしれません。インターネット上のジオメトリック的にDNSが有利にキャッシュされ盥回しされるため応答が早くなる可能性が高いと思います。
また、VPSもクラウドも専用サーバホスティングの世界ではHDDタイプとSSDタイプに選択肢が別れているものも当たり前になってきています。ネットワークの太い回線帯域を持っている方が圧倒的にサイトの表示は早いのでサーバスペック(コアの数)よりは回線の太さが重要かもしれません。また処理によって書き込みが多いのならばSSDも良いと思います。
以前はSSDの信頼性も?がついてましたがかなり安全であることがわかってきました。流石に大容量はHDDにかなわないのですが、容量がそれほどいかないサイトならSSDで十分とも言えます。
過去に使って見てよかったホスティングをとりあえず案内します。
  • Amazon EC2 Amazon Lightsail
  • Azure
  • Google Cloud
  • Conoha  
  • Kagoya VPS
  • Web Arena Suite Prov4

SSLサーバ移転に注意すべきこと(転送mod_rewriteが効かない場合の考察)

 / Wordpress, wordpressテクニカル, トピックス


昨年(平成30年)からSSL仕様にする流れが大きくサーバトラブルの要因となるケースが発生している、特にサーバ移転や表示ドメインの変更時に注意が必要だ。これは何を意味しているかというと、概ね以下の問題点が出てくるためである。


SSLでサーバ移転で生ずる問題

  1. 旧httpドメインでのアクセスを取りこぼしたくないから転送処理を導入するが期待通りに動作しない
  2. SSL証明書をwww付きで取得するか、無しで取得するかでWEBサーバ設定やmod_rewrite等が影響を受ける
  3. 転送のキャッシュ、証明書のキャッシュは「強制リロード」、「履歴の削除」、「キャッシュの削除」では消えない場合がある。

SSL証明書を購入するときに注意をしないといけないのは「www]付きのドメインなのか否かである。SSL証明書発行局のブランドにより1つの証明書で「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無しを個別に2つ購入するしかない。


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

GoogleのreCAPTCHAのバージョンがVersion3になってチェックが不要に。

 / Wordpress, wordpressセキュリティ, wordpressテクニカル, トピックス


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



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



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

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



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

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はサイト管理者が意図してページを削除したときに返すエラーになります。

TOPへ戻る