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

カテゴリー「SEO関連」の記事

ホームページの高速化手法 GZIP圧縮、コンパイルキャッシュ。画像圧縮、その他コンテンツ圧縮

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


WEB高速化まとめ

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

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

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

とりわけSEOとして考えていくなら第一にホームページの表示速度が重要で尚且つ、スマホの表示速度を優先度上げて考えるべきだ。理由として今の一般ユーザのアクセスの大半はスマホから来ているからなのです。 高速化の作業優先度を挙げるとしたら以下のような感じになるでしょう。
  1. スマートフォンの高速化
  2. 画像の圧縮
  3. javascriptの圧縮
  4. CSSの圧縮
  5. コンテンツがphp言語ならOPcacheを使ってコンパイル済みを共有メモリへロード
  6. DNSの応答高速化
  7. サーバのキャッシュと転送の圧縮処理
  8. ホスティング高速化
  9. HTTP/2を使ったWEBサーバへ切り替え。もしくはフロントをHTTP/2で置き換え。バッックエンドはHTTP/1.xでもOK。

スマートフォンの高速化

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

画像の圧縮

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

【JPEGの圧縮ツールの導入】

【PNG圧縮ツールの導入】

【圧縮ツールの使い方】

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

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

コンテンツがphp言語ならOPcacheを使ってコンパイル済みを共有メモリへロード

PHPはスクリプトであるためリクエストごとにコンパイルをします。しかしこれだと時間がかかってしまいます。スクリプトを読むことなくパフォーマンスの向上を図るため、OPcacheを使うことで一度コンパイルしたコードをメモリー上に共有し再利用します。

phpinfo() Or php -v によるZendクレジットで導入が確認できる

Opcache導入が成功すると下記のクレジットが表示されます。 WEBサーバは再起動してください。コマンドラインではphp -vで確認できます。 ☆CentOSのバージョンによっては/etc/php.d/配下にxx-opcache.iniでopcache.soを指定するかもしれません。
☆Opcacheはphpの低いバージョンはダメ。おそらくphp5.6前後以上と思われる。

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

Apache WEBサーバの転送はgzipで圧縮して転送を行うことが可能です。Apache2.4以前のバージョンではmod_deflateモジュールとを使ってAddOutputFilterByTypeでmimeフィルターする方法が途中まで主流でしたが既に廃れたやり方と言われています。
つまりdeflateモジュールをmod_filterを使ってmimeフィルターかけて圧縮することが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

chrome68アップデートの影響?順位大幅に変動

 / SEO関連, トピックス


chrome68アップデート以降 順位に変動が大きく出ています。振れ幅は平均18.3位で大変動ですね。ナマズで調べました。


ナマズ順位変動

影響の高い分野)

  • 美容、ファッション
  • IT、引っ越し、転職、就職
  • 旅行関連、医療

やはり、自分で検索しても全体的にSSLページが優遇されていると感じます。Googleさん、これはまだ序の口でいきなり厳しくしてしまうと困るサイトも有るため甘々にしているようですから9月の中頃か後半にもありそうですよ。まだまだブラウザーはここ直近で進化する予定があるようです。

Google Analysticsと他WEB解析ツールでの統計差異を考察してわかったこと

 / SEO用語集, SEO関連, トピックス, ノウハウ


複数のWEB解析ツールでサマリーの統計情報として基本的なPVや訪問数、滞在時間、直帰率がツールの種類で大きく異なっているケースが多い。これを調べてわかったことはGoogleはよくも悪くもすべての母数で平均値をとっている。それに対してGoogle以外の解析ツールはもう少し高度な事をしていることがわかった。つまり集計に値しないものは母数に入れていない。言い換えると人間目線のマーケティング思考で集計されている。

例えば、平均滞在時間があったとしよう。この中には(not set)等の怪しいリファラーSPAMが大部分占めている可能性がある。202レスポンスで戻ってくるDoS攻撃もあるだろう。どうやらこのような怪しい(not set)を積極的に統計情報の中に取り込んで統計除外対象に組み込んでいるのが読み取れる。

気づいたきっかけ

セキュリティ攻撃を受けている時の統計グラフの数字の差異がGoogle Analysticsと他WEB解析ツールとの差が激しく出たからだ。こう考えると、改めてWEB解析ツールは複数使う必要があると感じたし、どこを比較して見たらより正確な状態をつかめるかも理解できた。実勢にあっていないところもあるがやはり全体像を掴むためGoogle Analysticsの素の情報も必要だと感じる。

キーワードに出てくる分かりにくい表記を理解してより正確な実態像をつかもう

  • (not set) キーワード計測不能な状態のケース(URL直アクセス、リダイレクト、ブラウザ起動時のタブオープン、他の検索エンジン、たまたまタイミング的に拾えなかった、攻撃によるもの)
  • (not provided) 殆どは検索エンジンがhttpsで暗号化されているのが常だからキーワードがわからない状態です。GoogleならGoogleSearchConsole連動で明確にできますが他エンジンは連携していないので不明となります。
  • (other) Googleが一日のディメンジョンに格納できる量が限られているため、それを超えたものはotherで集計される。
  • (content targeting) Adsense埋め込みの場合
  • (remarketing / content targeting) AdSense広告由来のアクセスで、リマーケティングによる表示からのアクセス

Google Search Consoleの404エラーに潜む謎とセキュリティアタックの実態

 / SEO関連, トピックス, ノウハウ


Google Search Consoleの404エラーはSEO上重要なファクターです。Googleは404エラーは評価無視扱いとされ、色々な説がネットで流れていますが結果論から言ってしまうとエラーの割合が多いと順位が確実に下がります。つまり直接理由ではなくて間接的な要因から順位が下がってしまいます。ここには隠された謎があります。というのは通常404エラーは検索結果のリンク表示をクリックしたときに「ファイルがありません」というものを表すのですが、実はそれだけでは無いのです。ここをじっくり見ると攻撃の跡が見られます。つまり、隠されたページやバグを見つけようとして、あの手この手で存在していないURLを作り出してアクセスしてきていることがわかります。GSの管理画面でクロール>クロールエラー>URLエラーの項目を是非チェックして見てください。おかしいなと思うURLがあるはずです。ほぼそれが攻撃の形跡だと思います。


404エラーは一見すると無害のように思えて、有害の場合もある。

先に述べたように有りもしないページは勝手にアタックさせておけばと考えるのですが、意外と短い時間で連続アクセスされるとサイトによっては重くなる要因です。ページが重くなったら機会損失ですし、今は表示速度は評価の一つです。その他404エラーは間接的に色々なファクターを持っており、Googleがインデックスを刷新するタイミングを作る意味もあります。いい意味でコンテンツの切り替えがあって404エラーになってしまう場合もあります。これは健全な404エラーで全く問題ないのですが、ここにさらにページの生存期間が加わってくるとややこしいことに。

1ヶ月程度でネタが更新されてゆくサイトはページのURLが変わってしまうと損。

ページがきちんとGoogleに認識するまでの期間は意外と時間がかかります。私の感覚では更新ページが少なければ1日、2日で認識されるのもありますがページ数が多いと2週間から1ヶ月弱までかかる場合も多い。それで1ヶ月程度でネタが更新されてゆくともうお分かりでしょうが認識されず生涯を終えるページもあるわけです。

評価してもらうにはできるだけ長くインデックスにエージングしてもらう構造が必要。

つまり新しい記事ネタでもページURLは変わらずページBODYのみ定期的にダイナミックに変わるものが最も有利な構造と言えます。最初からデータベースでBODYコンテンツをダイナミックに作ればよいのでしょうが、図体のでかいサイトは簡単に変更できません。今はスクレイピングの技術やJavascriptの技術があるから置換したり局所的にはめ込みを更新するのは簡単なことです。私は実験で自分自身が持っている幾つかのサイトを完全ファイル構造を変えて刷新することをやってみましたがやはり全てのGoogle検索サーバが完全同期するまでには半年以上かかりました。その間は何度もGoogle Search Consoleの中で重複や404エラーの先祖返り評価を表示されることがあり、改めてGoogleの検索サーバの同期はものすごい時間がかかるので、ディレクトリ構造やファイル名をあんちょこにコロコロ変えるのは得策ではないとわかりました。

404エラーはゼロになる必要はないが、定期的にエラーをチェックしエラーの原因を掴みましょう

エラーはサイトの健康のバロメータであることはわかったかと思います。エラーが少ないにこしたことはありません。多いということはそれだけ無駄が潜んでいたり、セキュリティアタックを受けてたりと色々なことがわかります。セキュリティアタックなら攻撃パターンが分かれば対処は難しくありません。意外なところで便利な404エラーですね!皆さんも要チェック!

セキュリティとWEBマーケティング「認識し難い攻撃と統計情報ああー勘違いの巻」

 / SEO関連, セキュリティ日記, トピックス, ノウハウ


セキュリティとWEBマーケティングは一見すると互いに結びつかない知識のように感じる人も多いだろうと思う。現実的には今のネットワーク社会では犯罪の裏にネットワーク上の攻撃や詐欺が蔓延しており、WEBマーケティングに対する脅威は日々増え根拠は十分にあると言えます。


例えば、アメリカで起きているセキュリティ攻撃には相手企業を陥れるためのネットワーク攻撃があります。相手企業のWEBサーバがダウンすれば、影響を受けて当然、2番手、3番手の企業の売上は伸びることでしょう。しかしこの手の攻撃は攻撃する側も足がつかないようにするために、リスクに備えるための準備と攻撃基地を作るのにコストがかかる。まず日本ではかなり法整備やプロバイダー、警察の連携が大分整ってきたため足がつきやすいのは間違いない。よって日本でこのような事をやろうとしたら、海外にホスティングを借りて尚且、足がつかないホスティング業者や国を選択することになるだろう。また攻撃契約者とも足がつかないようにするのだと思います。


サイレントな攻撃パターン

以上の攻撃パターンは今までの典型的な攻撃の説明ですが、一番怖いのはサイレントな気が付きにくい攻撃だったりします。気が付きにくい攻撃とはさて何でしょうか?幾つか例をあげてみたいと思います。

  1. サイトを殺さない程度に負荷をかけるDoS攻撃
  2. サイトに侵略しても改ざんもウィルスも設置ぜず、攻撃ステーションとして利用する。
  3. コンテンツの見かけの改ざんはせずに、サイト転送処理を行ってアクセスを散らす
  4. わざと404エラーを大量発生させる。
  5. わざと1ページ離脱を大量発生させる。
  6. WEBの slow loris 攻撃でゆっくりと攻撃。WEBサイトをチアノーゼに追いやり、正常アクセス減、しかもセキュリティブロックを回避する。
  7. 大量のコピーサイトを作成する。これによりオリジナルサイトが判定の勘違いで下げられてしまう場合も少なからずある。

以上のパターンが有名なところだろう。この攻撃パターンはGoogleの検索順位に確実に影響を与えます。しかもWEB担当者が攻撃されていることに気づかないため改善策を講じないからどんどん評価がゆっくり悪くなる。

検索順位に関わるSEO評価基準の例

  • サイトの表示速度は順位に影響する
  • 大量の404エラーは順位に影響する。
  • 重複サイト、重複ページは著しい低評価を与える。尚且、何が正しいか判断もつきにくい
  • 不用意なリダイレクトは評価を下げる

マーケティング統計情報の嘘と勘違い

どのWEBサイトにも、今は何かしらの計測用の埋め込みがされているのが普通では無いでしょうか?いちばん有名なところではGoogle Analyticsだと思います。この計測値は全てが本物のアクセスカウントだと思ったら大きな勘違いだと断言します。その理由は次にあげたいと思います

  • 攻撃のアクセスは必ずしもエラーにならず、HTTPレスポンスで通常の「200 OK」ステータスも取れる攻撃はかなり多い。
  • DoS攻撃は「200 OK」ステータスで攻撃が基本。シャットアウトされないように攻撃するのがセオリーだ。
  • マーケティングで良い評価になるよう攻撃し、油断&勘違いさせてサイトの向上努力をさせない。

今はスレイピング技術が各種プログラミング言語で発達しているため、高度な人間がクリック、入力したような動作をシュミレーションすることが出来ます。すなわちこれを応用して高度な攻撃が可能です。

セキュリティを向上させるとアクセス数が減る?

これも原因が2パターンあります。一つは例えばSSL化するとセキュリティの向上につながる事があります。つまり今までの攻撃が無効になることで、アクセスカウントに変換されていた攻撃がなくなるので、一見するとアクセス数が減ったように見えるというものです。ただし、セキュリティが強くなったからRejectされたのではなく、攻撃者がhttpsで攻撃する頭がなかった(笑 からhttpsにすると攻撃スクリプトがhttpだから弾かれるわけです。私の経験上の統計ではどのサイトも平均して20%~40%の攻撃カウントがアクセス数に含まれています。つまりSSL化したタイミングでアクセス数が激減するのは正常なカウントだけになったからなのです。攻撃カウントがゼロにはなりませんが、大幅にカウントが減るため皆導入後に躊躇します。こういう事が原因だったんですね。


2つ目は、セキュリティが強く効きすぎて正常なアクセスが遮断されるというものです。クッキーやセッション絡み、あるいはWAFの誤検知などがあげられます。これが様々な条件で生じるためテストの段階ではすり抜けてしまい結果的にエンドユーザ側で生じてしまうというケースです。

TOPへ戻る