【多言語・多地域サイトを初めて制作する方へ】サイトの国際展開で抑えておくべきSEO要件
お客様よりWebサイトの海外展開についての質問があり、検索エンジン向けの多言語処理について改めて整理を行いました。今回はその内容についてブログにまとめたいと思います。現在日本含め10か国に展開されている当社のアプリ情報サ […]
タグ: サーバー
非エンジニア向けSSL解説：OpenSSLの脆弱性「HeartBleed」とは？
GoogleのMatt Cutts氏が「SSL（https）のサイトを優遇するかも」のような発言をしたことや、4月にはOpenSSLの致命的な脆弱性についても話題になりました。今回の記事では、非エンジニア向けにSSLや、指摘されている脆弱性「HeartBleed」について解説します。開発室の坂田による執筆です。
2014年は”SSL”が何かと話題に
以前からGoogleが強制的にSSLで接続するようになったり、2014年に入り、GoogleがSSLのサイトを優先しようか検討している、といった話が出てくるなど、SEO関係者の中でもたびたびSSLが話題に出てくるようになりましたね。
今年の４月ごろ、SSLでの通信を可能にしているOpenSSLというソフトウェアに、個人情報などの通信内容がサーバーから流出する重大な欠陥（脆弱性）が見つかったことが話題となりました。
この脆弱性は、サーバーからの情報流出が、心臓(Heart)から出血(bleed)するほど深刻に捉えられたため、「Heartbleed」と呼ばれています。
どんな形であれ個人情報を扱うようなサイトはセキュリティを担保することが求められます。今回は、SSLの仕組みを改めて理解していただいた上で、この脆弱性「Heartbleed」について解説します。
編集者注：冒頭の「GoogleがSSLのサイトを優先」の話は、Googleでも検討が始まったばかりの未確定事項
SSLの役割と仕組み
SSLは、主に２つの機能を提供しています。１つは、信頼性を担保することです。SSLを使用しているウェブサイトはSSLの証明書を有しています。
この証明書は、第三者機関である認証局(CA)によって発行されています。この証明書により、利用者が、ウェブサイトを信頼できることが保証されています。
もう１つは、暗号化により安全性を担保することです。通常のウェブサイトを表示するために使用するhttp通信は暗号化されていません。そのため、第三者に通信が見られた際、通信している情報が容易に読み取られてしまいます。
ここでいう情報の中には、IDやパスワードなどの会員情報や、住所や名前など、お問い合わせの内容など個人に関わる重要な情報が存在します。
こうした情報を第三者に読み取られないように、暗号化する必要があります。SSLは、通信情報を暗号化する機能を有し、安全な通信を確立する役割を担っています。
OpenSSLの脆弱性「Heartbleed」とは
OpenSSLとは、実際にこの暗号化を行っているプログラムの一つです。SSLを可能にしているソフトウェアはOpenSSLの他にもNSSやGnuTLSといったプログラムの存在しますが、OpenSSLは非常に高いシェアを占めています。
ところがこのOpenSSLの脆弱性が先日指摘され話題になりました。それがHeartbleedです。
SSLに限らず、サーバーは通信を行うと、メモリに通信内容を一時的に記録します。本来メモリに記録されたデータは、通信が終了すると破棄されます。
ところがHeartbleedという”バグ”により、メモリ上のデータが破棄されず、サーバー外部に流出してしまう場合があります。この流出したデータの中に、個人情報が含まれていると、個人情報の流出といった事態になります。
Heartbleedはサーバーの秘密鍵が流出する場合もある
ここで大きく問題なのは、Heartbleedによる影響は、通信データの一部流出にとどまらず、「サーバーの秘密鍵」の流出の恐れがある点です。
詳しい解説はここでは割愛しますが、SSLでは、共通鍵暗号方式と公開鍵暗号方式の２つの暗号方式を利用して安全性を担保しています。
SSLでサーバー送信した情報は、これらの方式を用いて暗号化されます。この情報は、サーバーの秘密鍵という鍵のみで復号化することが可能です。逆に言えば、この「秘密鍵」さえあれば、第三者でも容易に通信内容を読み取ることができます。
サーバーはひとつの秘密鍵を使用しているため、一度秘密鍵が流出してしまうと、ウェブサイトの利用者の通信内容を継続的に読み取られる可能性があります。例えるなら、隣の人にパソコンのパスワードを知られてしまった状態です。
対処法
実際の作業はサーバーなどの環境に依存しますので、具体的には触れませんが、以下の手順を取るとよいでしょう。
Heartbleedかどうか調べる
まずは、OpenSSLのバージョンを調べます。この際、以下のバージョンに当てはまる場合、Heartbleedの脆弱性があります。
またこれらのバージョンに該当しなくとも、古いOpenSSLを使用している場合は、他の脆弱性やバグが存在している可能性もあるので、最新のものにバージョンアップすることをおすすめします。
- OpenSSL 1.0.1 から 1.0.1f
- OpenSSL 1.0.2-beta から 1.0.2-beta1
Heartbleedを取り除く
OpenSSLのバージョンを確認し、Hearbleedの影響を受けている場合は、早急に取り除くましょう。最も簡単な方法は、OpenSSLのバージョンを最新のものにします。
また、レンタルサーバー等OpenSSLの設定を変えることのできない場合は、サーバーの管理会社に連絡し、この脆弱性を解消してもらう必要があります。
証明書を再発行し、以前の証明書を失効させる
OpenSSL脆弱性を直したら、SSLの証明書を再発行します。主なSSL発行会社は、無償での再発行を受け付けています。証明書を再発行したら、その設定をサーバーに反映させます。最後に、SSL発行会社を通じて古い証明書を失効させましょう。
まとめ
SSLは、個人情報を取り扱うウェブサイトを安全に運営していく上で、重要な役割を担っています。ウェブサイトの利用者が安心して利用できる環境を整えるためにも、SSLだけでなく、利用している技術やその仕組みを理解し、脆弱性やバグに柔軟に対応していくことが重要です。
最後に、私たち開発室もブログを書いておりまして、技術トピックを中心に、幅広い内容を紹介しています。こちらも参考にしてください。
Catcher in the tech – ヴォラーレ株式会社開発室ブログ
ヴォラーレ株式会社 坂田
SEOに有利？不利？エンジニアが見るHTML5とSEO
弊社はSEOのサービスを提供している関係上、直接コンサルティングには直接携わらないエンジニアでも、時折SEOに関する質問をされる機会は少なくありません。なかでもしばしば尋ねられるのが、SEOとHTML5の話題です。いまさらという感は否めませんが、本記事ではHTML5とSEOの関係についてざっくりと述べてみたいと思います。
HTML5とは
「HTML5」と言う場合、単純なマークアップ言語としてのHTML5をさす場合と、その関連技術を含む広義のHTML5をさす場合があります。
狭義のHTML5は、HTML4.0、XHTML1.1などと同列の、テキストを構造化するマークアップ言語です。要素の追加や変更、新たに導入された概念などの違いがあります。ただし既存の(X)HTMLとの互換性もある程度維持されており、本質的にはこれまでの(X)HTMLと大きな違いはありません。
一般的にHTML5といった場合、単純なマークアップ言語としての側面だけでなく、WebStorage、WebSocketなどのAPIも含めてHTML5と言われることが多いと思います。文脈によってはCSS3やSVG、WebGLといった技術も含めてHTML5と呼ばれることもあるようです。
本記事では、初めにマークアップ言語としてのHTML5について述べ、後半ではAPIの話題にも軽く触れておきたいと思います。
マークアップ言語としてのHTML5とSEO
マークアップ言語としてのHTML5を見たとき、HTML5にはどのような特徴があるのでしょうか？主な特徴として以下のようなものがあると考えています。
- コンテンツ・モデルとカテゴリーの導入
- 要素の追加、廃止と意味付けの変更
以上の点を、以下で少しだけ解説します。
コンテンツ・モデルとカテゴリーの導入
HTML4.0で定義されていた要素には、ブロック要素とインライン要素があり、インライン要素の中にブロック要素を入れてはいけないなどのルールが存在しました。例えば、インライン要素であるa要素を、ブロック要素であるdiv要素の中には入れることができないといったルールです。
このルールに従った場合、例えば以下のようなマークアップは認められません。
<a href=“http://www.seohacks.net/”><div>SEO HACKS</div></a>
例. HTML4.0における間違った要素の配置
HTML5では、このブロック要素とインライン要素に代わり、カテゴリーとコンテンツ・モデルという概念が定義されました。
カテゴリーとは、その要素が定義された目的を示すものです。例えば、body要素の中に設置できる要素はフロー・コンテンツというカテゴリーに属しますし、文章の章や段落を定義する要素は、セクショニング・コンテンツというカテゴリーに属します。
それぞれの要素で、中にどのカテゴリーの要素を含めてもよいか？というルールを表したのがコンテンツ・モデルになります。例えば、section要素のコンテンツ・モデルはフロー・コンテンツとセクショニング・コンテンツなので、このいずれかのカテゴリーに該当する要素を中に含めてよいことになります。
要素の追加、廃止と意味付けの変更
HTML5では、新たに追加された要素、廃止された要素、そして引き続き存続し続けるものの、意味付けの変更されているものが存在します。
追加された要素としては、article、section、header、asideなど文章構造を表現する要素や、embed、video、audioなどのインタラクティブな要素を表すものなどが追加されています。こうした要素の追加により、より文章の構造的意味を明確に示すことができるようになったり、インタラクティブなページの構成ができるようになりました。
一方で廃止された要素もあります。廃止された要素は、big、center、fontなどの見た目を定義していた要素や、frame、framesetのようなフレームに関する要素などです。これらの要素はCSSを使用したり、他の代替候補となるタグをすれば問題ないでしょう。
b、iなど、廃止ではないものの、以前のバージョンのHTMLから、意味付けが変更された要素もあります。例えばb要素はこれまで太字を現す要素で、かつ太字で現すという意味での仕様は非推奨とされていますが、HTML5では他と区別して表記すべきフレーズを示す要素となりました。
具体例 – hx要素のマークアップ
さて、HTML5によって変わる具体的な例として、SEO上も重要といわれる見出し要素のマークアップを考えてみましょう。見出しを表すh1〜h6要素はHTML4.01の場合、1〜6という数字でそのランクを示します。
<h1>見出しレベル１</h1>
<div>
<h2>見出しレベル２</h2>
<div>
</div>
<h2>見出しレベル２</h2>
<div>
</div>
</div>
例. HTMLの見出しレベル分け（HTML5でも有効）
最上位の見出しであるh1要素はSEO上、1つの文書内で1度しか利用できないというルールがありました。HTML5の場合も、このルールに従っていれば何ら問題はありません。
一方でHTML5の場合、新たに追加されたsection要素のようなセクショニング・コンテンツの深さを使ってセクションを表現することもできます。以下のようなケースでは、h1要素を複数使用されていても、それぞれのセクションにおける見出しのレベルを区別できるようになっています。
<section>
<h1>見出しレベル1</h1>
<section>
<h1>見出しレベル２</h1>
</section>
<section>
<h1>見出しレベル２</h1>
</section>
</section>
例. HTML5ではこのような見出しの使い方も認められる
とはいえ、HTML5では既存の方法によるマークアップも可能です。当然の疑問として、どちらの方法を使うのが良いか？ということになりますが、上述の２つの例に優劣はありません。単に選択肢が増えただけなので、使いやすい方を選べばよいでしょう。
HTML5はSEOに有利なのか？
ここまで、HTML5におけるマークアップ言語として変わった点をごく簡単に記載しました。HTML5はSEOに対してどういった影響を与えるのでしょうか？結論だけ先に述べますと、HTML5の使用は、SEOに有利とも不利ともいえないと考えています。
確かにHTML5を使用することで、以前のバージョンのHTMLに比べ、より文章構造を明確することができ、サーチエンジンにとってもより文章の示す意味を解釈しやすくなったのは事実です。また、HTML5に追加されたインタラクティブ・コンテンツや、後述するAPIを利用すれば、よりリッチなコンテンツを記述することができます。
しかしながら単なるフォーマットの違いです。XHTMLで記述していた文書が、HTML5になることによって、ページそのものの価値が高くなったりすることはあるでしょうか？利用するサイトがHTML4.01なのかHTML5なのか、を気にする一般ユーザーはほとんどいないはずです。
新規でサイトを作る場合や、サイトのフルリニューアル時にHTML5を選択するのはありだと思います。しかし、SEO目的で既にHTML4.0やXHTMLで構成されているサイトをそのままHTML5に書き直すといったことは全く必要ないでしょう。
Web周辺技術としてのHTML5
HTML5のカバーする領域は非常に幅広く、マークアップ言語の側面のみならず、JavaScriptを介して扱うAPIや、WebSocketなどの関連技術もその範囲に含まれます。例えばWebStorage、WebSocket、Paging APIといったものが該当します。非常に幅広い領域のAPIが定義されており、全てを紹介しきることは到底できませんので、少しでもSEOに関係のありそうなAPIを簡単に紹介させていただこうと思います。
表示速度を計測する「Navigation Timing API」
Webサイトを見るときには、リンクをクリックしたり、アドレスバーにURLやキーワードを打ち込んだりすると思います。大抵のサイトでは、１秒〜せいぜい数秒の内にページが表示されるはずです。利用するユーザにとっては一瞬のできごとですが、ブラウザ上で見たいページをリクエストしてから実際にWebサイトが表示されるまでには、いくつかの段階を経ています。Navigation Timing APIとは、一言で言えばこの”いくつかの段階”として示しているものを共通化して、表示速度の記録・参照が可能なAPIです。
W3Cから拝借したNavigation Timing APIについてのドキュメント図では、以下のようなフェーズに分けられています。
Navigation Timing API
このAPIは、通常のWebサイト上で利用するものではありませんが、Chromeのデベロッパーツールなどではこのフェーズを閲覧することができます。またGoogle Analyticsの「サイトの速度」で表示出来る時間も、このNavigation Timing APIにより測定されているものだと思います。
SEO上は小さなファクターであるものの、ユーザーエクスペリエンス的な側面も考えると、サイトの表示速度は決して無視できるものではありません。
以前、別の記事でWebサイトの高速化に関するトピックを紹介しました。このAPIを利用すると、こうした高速化による改善状況などを定量的に計測することができます。具体的な利用例としては、弊社開発室のブログでNavigation Timing APIを利用したツールでパフォーマンス測定を自動化するというトピックを紹介しておりますので、よければそちらも参照ください。
より詳しい解説は外部のサイトに譲りますので、このようなAPIも利用できることだけ知っていただければ十分です。
画面遷移せずに履歴を操作する「History API」
いわゆる“Ajax”を多用したサイトでは、画面の遷移なくコンテンツを書き換えたりすることが行われます。一方で、クローラーは１つのURLを１ページとして認識するため、このようなサイトのコンテンツを意図通りにインデックスさせることが困難でした。
上述のようなAjaxを使用したページをインデックスさせる方法として、Googleは#!(hashbang)を使ってAjaxアプリケーションをクロールさせる方法を提示していましたが、複雑な仕様で誰しもが利用できる仕様とはいえませんでした。
これを代替する手段として、近年はpushStateの利用を推奨しているようです。
pushStateは、HTML5で定義されているHistory APIの機能の１つで、画面遷移せずにブラウザの履歴にURLを追加することができる機能です。画面遷移をせずにAjaxを使ってコンテンツの書き換えを実現したい場合、pushStateを使えばコンテンツの書き換えと同時にURLも変更することができます。
もちろんAjaxを使わずとも閲覧できるサイトのほうが検索エンジンライクなのは間違いないと思いますが、必ずしもSEOが最重要のファクターである、というケースばかりではないと思います。検索エンジンには独立したページとしてインデックスさせたいといったニーズがある場合、利用を検討してみるのも良いのではないでしょうか？
まとめ
本記事では、HTML5の概要や、HTML5とSEOとの関係、HTML5に含まれるAPIの一部を紹介しました。すでに述べた通り、HTML5を使うことそれ自体がSEO上特別有利になるとか、不利になることはないと考えています。
とはいうものの、HTML5について正しく理解しておくことや、HTML5で何ができるか？を知っておくことは、誤った使い方によるリスクを避けたり、取りうる選択肢を増やすという意味で重要と言えるのではないでしょうか。
ヴォラーレ株式会社 若松
WordPressって何？という人が読んでも5分で何となく分かる記事
今回はこのブログでもお世話になっているWordPressについて解説します。WordPressって何？という人向けの記事です。
WordPressとは？
WordPressはCMS（Contents Management System）というものの１種です。直訳で「コンテンツ管理システム」です。
通常、Webサイトを作成・公開するためにはHTMLやCSSの知識が必須ですが、WordPressに代表されるCMSを利用すればそのような専門知識などをもっていなくとも文章や画像といったコンテンツさえ準備する事が出来ればWebサイトを作成・公開する事が出来ます。Webの専門知識がない人でもブログなどでWebに記事を公開できるのは、そういう仕組みがあるからですね。
しかし一口にCMSといってもめちゃめちゃ幅広いものです（ Google検索「CMS 種類」 ）。
そのたくさんあるCMSの中でも特に多くのシェアをもっているのがWordPressなんです。
WordPressが使われる理由
WordPressには他のCMSと比較して以下のような特徴を持っています。
情報が豊富
ユーザが多いので情報が豊富です。WordPressに関する書籍は数え切れないくらい出ていますし、何か困った事が起きてもGoogle検索で大体の事が解決できます。
Webサイトの基本的な構造が作りやすい
トップページが有り、カテゴリページが有り、タグページが有り・・と言った基本的なWebサイトの構造をHTMLをいっさい触らずに作る事ができます。
プラグインが豊富
プラグインというのはWordPressに追加機能を簡単に付与させる事ができる仕組みです。サイトの表示を高速化するものや、サイトのバックアップを助けてくれるものなどたくさんのプラグインが有ります。「こんな機能があったらいいのにな・・・」と思う機能はだいたいプラグインを探せば有ります。
テーマが豊富
テーマはWebサイトの着せ替え機能みたいなものです。記事や画像、カテゴリやタグなどの情報はそのままに、サイトの見た目部分を変更する事が出来ます。
WordPressはテーマを作成して公開、利用する仕組みがよく整えられていて、世界中のデザイナー、デベロッパーが作成した様々なテーマが無料で公開されています（有料のものもあります）。ユーザはそれらを自由に利用する事ができ、自分でテーマを作成して使用する事もできます。
つまるところ、WordPressが多くのシェアを獲得している理由としては、
- 数あるCMSの中でもすごくポピュラーで情報がたくさんある事
- HTML、CSSなどの詳しい知識が無くても大丈夫なお手軽さ
- プラグインやテーマなどが自由に使える拡張性の高さ
というところかなと思います。
WordPressの仕組み
さてここからは、WordPressというCMSが、どのような（技術的な）仕組みで動いているのか？管理画面から投稿した記事や画像が、どのようにWebサイトとして反映されているのか？ということにも触れていきたいと思います。
WordPressのサイトにアクセスしてサイトが表示されるまでの流れ
WordPressでは、ユーザが投稿した記事やそれに対するコメントなどが直接HTMLのファイルを生成する訳ではありません。
WordPressは「PHP」というプログラミング言語で構築されており、コンテンツの管理には「MySQL」というデータベースを利用して、CMSとしての機能を実現しています。
WordPressで作成されたWebサイトにアクセスした時、ブラウザあるいはブラウザの向こう側で一体どういう事が起きているのでしょうか。サイトが表示されるまでのざっくりとした流れは次の通りです。
1. ブラウザはサイトに見たいページの情報を送ります。
2. サーバサイトにアクセスがあるとPHPが動作し、MySQLから記事やコメントなどのデータを取り出してHTMLを生成、送信します。
3. 送信されてきたHTMLを、ブラウザがうまく変換して表示します。
WordPressを動かすPHPと、データを保存するデータベースが分かれており、連携して1つのページを表示させるというのがポイントです。
コンテンツの管理にデータベースを使う理由
WordPressではコンテンツの管理にデータベースを利用していると説明しました。
このような仕組みを取る事で「コンテンツ」と「Webサイトの器（≒テンプレート）」を別々に管理する事が出来るようになっています。
例えば、MySQLを操作するためのSQL文が書ければデータベース中のコンテンツを一斉に扱う事が出来ますし、HTML、PHP、CSSが書ければ自由なレイアウト、デザインでコンテンツを展開出来ます。
また、Webサイトの見た目をテーマによって簡単に切り替える事が出来たり、プラグインによる拡張が容易に行えたりといった機能を提供できるのも、コンテンツ管理にデータベースを利用しているおかげです。
コンテンツをデータベース化し、表示をプログラムで作るという仕組みがWordPressの汎用性、拡張性の高さを支えているのです。
SEOから見るWordPress
WordPress自体にSEO効果があるという情報をよく見ますが、それは正しいと言える側面もある一方、捉え方次第では誤解を招きそうなので、SEOに関することも最後に解説しておきます。
別にWordPressを使ったからといってSEO効果があるわけではない
SEOとは「Webサイトが検索エンジンから正しい評価を受ける事が出来るように最適化する事」です。SEOを正しく行う事でWebサイトはその存在を正しく検索エンジンに理解・評価してもらう事が出来ます。そうする事でWebサイトは適切なキーワードにおける適切な順位に登場する事が出来るようになるのです。
ですので、WordPressを使ったからといってそのサイトが検索結果のより上位に表示されるかというと、そんな事はありません。それを踏まえた上で、WordPressはSEOとどういった相性にあるのか考えてみます。
SEOを行うには都合が良いという点はある
WordPressを使っただけでSEO的に何か効果があるかといえば全くそんな事は無いという話は先にしました。ただし、SEOを行う上で都合が良い点はあると言えます。
例えばプラグインを使って簡単に記事毎のmetaディスクリプションやキーワードを設定出来たり、カテゴリ、タグ構造を用いた内部リンクの調整やアイキャッチ画像の設定がやりやすかったりと、サイト訪問者がサイト内を迂回してくれるような仕組みが作りやすかったりします。
つまり、WordPressそれ自体にSEO効果は無いですが、SEOを比較的やりやすいのがWordPressだ、という認識で良いと思います。
全体まとめ
まとめると、
- WordPressは最も使われているCMS（コンテンツ管理システム）の1つ
- WordPressは文章やコメント、画像などのオリジナルなコンテンツと、サイトそのものの構造や見た目を切り分けて管理できる。
- だから、コンテンツをそのままにサイトの構造やデザインを容易に調整できる。
- 情報の豊富さ、ユーザの多さからWordPressにまつわる大体の事がググればなんとかなる。
- WordPress使えばSEOばっちりかと言えばそんな事無い。
- ただし構造の変えやすさ、SEOを助けるプラグインの存在などから、SEOはやりやすいと言える
という感じです。どうでしょう。WordPressがどのようなものなのか、ざっくりと伝わったでしょうか？この記事で少しでもWordPressに興味をもっていただけると嬉しいです。
ヴォラーレ株式会社 工藤
おすすめの記事
Webサイト高速化・表示速度改善のために知っておきたい基礎知識
Webサイトを高速化をする事によって得られるメリットは様々あると思いますが、ユーザーエクスペリエンスの改善といった話とは別に、個人的にはサーバの台数が減らせるというのも大きなメリットだと思っています。サーバサイド側のエンジニアとしてはやはりサーバの台数が減ればコストも下がるし、運用も楽になりますので、SEOに関わらず努力したいところではありますね。
しかしながら、「高速化しよう」「表示速度を改善しよう」といっても、実際にどういうところに高速化を阻害するような要因があるのか、ということを知っていなければそもそもどう取り組んで良いか分かるはずもありません。
ということで今回は、技術者の方でなくともサイト高速化のポイントがある程度理解できる（多分）ように、最低限「こんなことがあるのね」というポイントを大まかにまとめてみました。
高速化のための基礎知識
高速化という言葉の中には、大きく分けて２種類の概念が存在します。
- フロントエンド側での高速化
- サーバサイド（バックエンド）側での高速化
フロントエンドとは
ここで定義したいフロントエンドとは「HTML・CSS・JavaScriptなどの技術」と解釈してください。噛み砕いて言えば、「ページがブラウザに表示される」という部分に関する部分がフロントエンドということです。フロントエンドの領域では、ある程度HTMLが書ける方ならポイントさえつかめれば誰でも高速化する事が可能です。
サーバサイド（バックエンド）とは
サーバサイド（バックエンド）側、というのは文字通りサーバー側での最適化なのですが、状況によって見るべきポイントが異なりますし、ある程度は専門的な知識が求められるので、誰でも簡単に高速化、というのは難しいことも場合と思いますので、今回はいくつかの要素について掻い摘んでお話しようと思います。
フロントエンドの高速化
これに関しては様々な方法があると思いますが、シンプルに考えて以下の3つを注意した上で高速化を行っていけばいいと思います。
- サーバーへの通信の回数を減らす
- サーバーへの通信量を減らす
- レンダリングの速度を低下させない
1.サーバーとの通信の回数を減らす
まず、普段ウェブサイトを表示する時のブラウザの動作を考えてみましょう。ウェブページにアクセスする際には、ブラウザに「http://xxxx.○○.html」などといったURLを入力したり、リンクをクリックしたりすると思いますが、このサイトを開く場合にサーバへのアクセスは何回になるか？
と聞くと、意外に「１回しか通信しない」と思っている人も多いのではないでしょうか。
実は「http://xxxx.○○.html」を開いて中のHTMLを確認するまで、実際に何回サーバーとの通信が発生するかはわかりません。
なぜ開くまでわからないのか？といえば、それはHTML書かれている内容によって通信回数が異なるからです。通信回数はHTMLの中に記述されている、画像、外部CSSファイル、外部Javascriptファイルの数によって変わってきます。
単純に考えて画像の数だけ、CSSの数だけ、Javascriptの数だけ通信が発生していまします。
※304を返す場合は通信は発生しません。ステータスコードに関しては「よく見るHTTPステータスコード一覧とその意味を理解する」を参照してもらえればいいのかなと思います。
通信回数が多いということは、その分だけ表示が遅れることにつながりますので、なるべく少ない通信回数で表示が完了できるようにするという事がまず大切です。もちろん、決して「通信を１回に押さえろ」というわけではなく、あくまで無駄な通信をしないということです。
2. サーバーへの通信量を減らす
通信の回数、ではなく「通信量」を減らすということをイメージすると、例えば画像ファイルの容量を減らすことが思い浮かぶ方が多いと思いますが、そういうことです。画像や動画ファイルはファイルサイズがとても大きいので、通信量が増えます。
この点では、本当に基本的な事かもしれませんが、読み込むファイルのサイズを減らすということが重要になります。一番多くのサイトに関係があるのはやはり画像ファイルだと思います。
「これ以上は画質を荒くしたくない」という事情は多々あると思いますので、そんなときは、画質を落とさずにファイルサイズを減らす「画像の最適化」を行います。
通常の画像データにはウェブページとしては不必要なデータが含まれている事があります。それらを排除することで、ファイルサイズを軽くする事が出来ます。画像によっても変わってきますが、相当ファイルサイズが減るのでおすすめです。
最適化する際は専用のソフトウェアがあるので、そちらを使いましょう。
ちなみに、余力があれば、CSSとJavascriptのファイルサイズも少なくした方が良いと思います。もともと、画像に比べたらファイルサイズは小さいのですが、それでも軽量化をするべきだと私はを思います。
ある程度ウェブサイトを長年運用していると、CSSやJavascriptが徐々に追加され、気づいたら容量が増えていたなんてことがあります。また、簡単に軽量化できるので、導入しやすさもあります。
ただし、不必要なJavascriptやCSSは削除してしまえばいいんじゃないの？って思う方もいるかもしれませんが不必要だと思ってたら、必要だったCSSの記述だとか、使っていないと思っていたJavascriptの関数を削除してしまったり…と、もちろん不必要な記述は削除するべきですが、現実的にはなかなか難しいと思います。
そんなときは「ファイルの圧縮」を行います。不必要な空白や改行を削ってCSSファイルや、Javascriptファイルを軽量化する手法です。
もちろんエディタ等の置換機能を駆使して、消していく事もできますが、何千行なんてCSSやJavascriptファイルだった場合はとても大変なので自動で変換してくれる便利なツールがたくさんあるのでそちらを使いましょう。
- YUI Compressor
- Compressor
- Closure Compiler(javascriptのみ)
- ProCSSor - Advanced CSS Prettifier(CSSのみ)
3.レンダリング（≒HTML解析～ブラウザ表示）の速度を低下させない
ブラウザの表示速度を遅くしてしまう要因は通信だけではありません。HTMLの記述のしかた一つでブラウザの表示速度も下がってしまう場合もあります。
例えば一昔前はよくJavascriptをheadタグのなかに記述している事が多かったと思いますが、最近ではbodyの閉じタグの直前に記述するのが主流です。（ただし、Google アナリティクスの計測用コードなどはhead内に記述したほうがより正確な計測が出来るといった事情もあるように、必ず・全てということではありません。）
headタグ内への記述を推奨されない理由は、ブラウザの表示速度が低下してしまうからです。たとえばheadの中に外部Javascriptの読み込みがあると、その時点でJavascriptの読み込み、実行がされてしまいます。その間ブラウザは表示に関する処理は止まってしまうので、ユーザーに取ってはその分表示されるのが遅く感じてしまいます。
そこで、先にブラウザに表示できるものを表示させて、あとからJavascriptの処理をさせるという順序にすれば、体感的にユーザーに遅さを感じさせないようにすることができます。
もちろん1つ2つの処理であればそこまで影響が出ることは無いと思いますが、大量にJavascriptファイルがある場合などは大きな影響が出る可能性があります。
サーバサイド（バックエンド）側での高速化
さて、ここからは簡単にサーバサイド側の高速化の話を軽く触れていきたいと思います。どうしても技術よりの話題になりますので普段全く技術に関わらない方はナナメ読みで良いと思います。
サーバサイドは本当に様々な条件によって変わってきますので、状況によって高速化の手法はバラバラです。Ruby、Python、NodeJS、Perl、Java、PHPなどプログラミング言語によってももちろん違いますし、BtoCなウェブアプリケーション、BtoBなアプリケーションなど、ターゲットによっても変わります。また、サーバのスペックなどによっても変わってしまいます。非常に複雑で、ある程度以上の専門的な知識が必須になります。
とは言っても、高速化に関してサーバサイドで重要な事は、突き詰めていけばたった一つだけ。「ブラウザに返すレスポンスの速度を上げる」ということです。
特に速度が遅くなりやすい部分、アプリケーションによるデータベースの扱い方について私が意識的に注意している部分に関して簡単に掻い摘んで説明します。
使わなくてよい物はDBを使わない
Webアプリケーションではほとんどの場合、何かしらのデータベースが使われています。データベースは非常に強力なソフトウェア（ミドルウェア）ですが、アプリケーションから使い方を間違えると速度の低下につながります。
ついつい、データベースで何でも管理したくなってしまいがちですが、データベースに入れなくていいデータを入れるのはやめましょう。特にセッションデータをデータベースに入れているケースをたまに見かけますが、なるべく控えたほうがいいです。
このセッションデータと呼ばれる物は、ユーザーがアクセスする度にデータを取得して、更新して書き込むということが発生します。リクエストが発生する度に、データベースへの書き込み処理、読み込み処理が発生してしまうので、データベースに不要な負荷を与えてしまいます。
キャッシュを活用する
当たり前の事かもしれませんが、データベースは呼ばれれば呼ばれるほど、速度が低下します。小さい事かもしれませんが、比較的変更の少ない固定されているデータ「商品マスタ」「ユーザー情報」などはキャッシュしておくべきです。ユーザー数やアクセス数が多いサービスにはかなり有効な方法です。
※ただし、キャッシュを多様しすぎると、正しくないデータがブラウザに表示されてしまうなんて事もあるので使用する際は注意してください。
実行しているSQLの最適化
データベースを使う場合に、本当に最適なデータベースの使い方をしているのか見直しましょう。データを取得する際にSQLを使用しますが、その際に実行されているSQLが意図としたSQLになっているのか？見直してみると無駄がある事も多いので、ここは慎重に確認するべきです。
データベースのインデックスの見直し
データベースの高速化の技術の一つにインデックスという物が存在します。本で言うところの「索引」と同じような物ですが、このインデックスの設定の仕方で速度が何倍も変わってきます。
良いインデックスというのはデータベースの設計やアプリケーションによって変わってきますが、インデックスがしっかり使われているかを確認しましょう。
非同期処理でデータを保存する
データベースにデータを保存する際に、「保存しました」というレスポンスをデータベースから帰って来るのを待っていると速度が遅くなってしまいます。書き込む量が多くなれば多くなるほど速度は遅くなってしまいます。
大切なデータに関しては同期的に対応するべきですが、そこまで重要じゃないデータに関しては非同期で保存するという方法は有効です。
不必要なデータは保存しない
データベースはデータ量が多くなれば多くなるほど、速度が低下してしまいます。不必要なデータを保存するのは避けた方がいいです。
分割を意識した設計
データ量が多くなってしまうデータベースでは、データベースやテーブルが分割されても大丈夫なような設計をするべきです。
、、など、見るべきポイント、高速化を阻害する要因というのは様々あります。
まとめ
ウェブサイトの高速化というと例えば「CSSスプライトを使いましょう！」などのフロントエンド寄りの話が話題になりやすいですが、こういったサーバサイドでもしっかりと対応するために、どの程度のユーザーが使うのか、どの程度の規模のサービスなのか？といったあたりも意識しながらウェブサイトを設計・構築することが重要です。
サイトの高速化について大まかに掻い摘んで書きましたが、まだまだやらなければ行けない事はたくさんあります。今回紹介したポイントを意識して最適化することにより、確実に高速化できるのではないでしょうか。
ヴォラーレ株式会社 望月
おすすめの記事
2013.4.26 SEOセミナー開催レポート：「理解していれば回避できるはずの問題は予め回避しておくが吉」
さて、最近セミナー報告ばかりになりつつある当ブログですが、今回は4月26日（金）に開催しました制作や開発に関わる方向けのSEOセミナーのレポートです。前回と同じくtwitterで内容お伝えしていたのでそれもまとめてあります。
twitterまとめ：Webサイト設計に関わる無料SEOセミナー セルフまとめもいいとこ
今回はマーケティングとかリンクとかコンテンツとか検索エンジンアルゴリズムといった話題にはあまり触れず、Webサイトの設計・制作にあたりどういったことを予め考慮しておかなければならないのか、という内容で予定では120分のところ150分くらいに渡りお伝えしました。
諸注意として予めお伝えしたこと
本題の前に皆さんに事前にお伝えしたこととして、
- 検索エンジンが評価したいのはコンテンツ＆リンク
- 検索エンジンは「正しく作られたWebサイト」を評価したいのではない
- 正しく作られたWebサイト≠高く評価されるWebサイト
というのがまず原則としてあります。ですので、ここではあくまでSEOの観点から、という話にしますが、例えば実際にHTMLのマークアップを行う方がいくらそれらを美しく記述したところで、それ自体はSEOの完成ではなく、むしろSEOを行う土台を整える作業のうちのごく僅かな要素の一つ、というところでしかありません。
しかし、それでも尚、「（ある程度）検索エンジンを考慮してサイトを作る」ということはとても重要なものであるという認識でおり、サイト規模が大きくなる、とか長きに渡ってコンテンツを配信していく、というサイトであればあるほど、運用に入る前、設計の段階でどこまでSEOが考慮されたか、によって運用後の検索トラフィックには大きな差が出ます。
「クローラーの仕組みやランク付けアルゴリズムを研究して完璧なSEO設計をする」とかそういうことではなく、ある種の「普通に回避できるはずだった問題」を予め回避することが出来るのであれば、それは事前に対処して回避しておくのが吉じゃないですか（実際には、普通に回避できるはずだった問題点を回避できてなくて色々損してるケースがあまりに多く勿体ない）、ということが今回の本旨です。
セミナーコンテンツ
詳細はボリュームが多いので（スライド150枚以上）概要をラインナップとして並べます。
※実際のプレゼンで使用したスライド一覧
1.検索エンジンの基礎知識
今回はかなりサラッと流しましたが、これはどの回でも必ず行います。最低限、裏でどんなものがどのように、何のために動いているのかは理解しておかないとその先の話が通じなくなってしまいます。
- 検索エンジンの仕組み
- 検索エンジンの収益モデル
- 検索結果が返されるプロセス
2.企業がSEOに取り組む意義と得られるもの
今回はメインの話題がサイトの作り方の部分だったりもするのでここも流してしまいましたが、目的と手段を混同しないように、ということと、最終的にどのようにSEOを通じて検索トラフィックが獲得されるのか、ということに簡単に解説しました。
- 企業がSEOを行うメリット
- SEOのWebプロモーション上の特性
- SEOの運用と目標達成までのプロセス
3.SEOの取り組み内容とその分類
例えば内部対策と外部対策とか、コンテンツとリンクとか、ユーザビリティとクローラビリティとか、まあ色んな確度からそれぞれの要素が様々分類されて対比されます。まずはどういう要素がSEOには存在していて、それぞれがどういう分類をされるのか、みたいなことをかなりザックリまとめてお話しました。
- 機械（検索エンジン）を考慮したサイト設計
- キーワード/コンテンツ/リンク
- 制作・開発担当者が直接SEOに貢献できる事
- 内部と外部 / 機械と人間
4.制作者が行えるSEO
メインはこの部分です。事例を交えて、サイトのデザインや機能の実装にあたり最低限、少なくとも知っておかれたい、或いは気にされたい部分を約100枚くらいのスライドで駆け足で解説しました。
限られた時間の中で、なのでこういうお話を新情報として聞かれる方もいらっしゃったと思いますが、もちろんボリューム的には一つ一つについて網羅できるはずもないので、まずは「なるほど、こういうことも気にしておかないといけないのね」ということだけでも理解して頂ければ良いかなとは思っています。
- 検索キーワードと流入口ページの確保
- テキスト情報の独自性の担保
- 重複コンテンツ問題
- クロール・インデックス
- ページレイアウト
- サイトの速度
まとめ
今回お話した内容は、一つ一つの項目としては取り立てて珍しい話ではないというかごく基本的なことの確認、おさらいのような感じでしたが、しかし基本的であることと皆さんがそれを満遍なく理解しているということはイコールではありません。
実際に、少なくとも全体から見れば一部を除いた多くのWebサイトは、SEOに適しているとはとてもではないが言い難い、というような作り方をされていると思います。
少なくとも、HTML構文チェックで100点を目指すこと自体のSEO的な価値というのはほぼ皆無だと思っておりますが、そういう類の「最適化」を求めるのではなく、最低限、作成するコンテンツの内容や得られたリンクが漏れ無く無駄なく評価される、ということがSEOの前提ですので、こうした認識は、Webの制作や運用に関わる皆さんにやはり最低限以上は知っておいて頂きたいなと感じる所存です。
次回開催のお知らせ
アンケートやTwitter上での反響は割と良かった方だったので、僕個人の省エネも兼ねて5月にもう一度同じ内容のセミナーをすることになりました。
詳細：Web制作・開発に関わる方向けのSEO設計基礎セミナー(第二回)
Web制作会社の方や社内のWeb担当者の方をメインターゲットとしていますが、マーケティング担当者の方とかまあ色々要は基本的にはご興味がありましたらご参加頂ければと思います。
当日は事前に簡単なレジュメ（?）をお配りして、プレゼン資料とかは終了後にお持ち帰り頂けるようにしていますが、今回は資料印刷ミスりました。細かな誤字チェックとかは複数人でやったのにも関わらず表題だけが作成当初のまんまになってました。
※内容は本番でした。
ということで5月のセミナーも告知前からちらほらと参加お申込み頂いている企業様もいらっしゃり大変有難い状況ではありますが、今後のセミナーも機会とご興味とお時間ありましたら是非ご参加下さい。
ヴォラーレ株式会社 土居
おすすめの記事
よく見るHTTPステータスコード一覧とその意味を理解する
404や503、301・302など「ステータスコード」とか言われるものをよく見るけど実はその意味はよく分かっていません、という方は意外に多いんじゃないかなと思ったので、よく見るものを一覧でまとめて解説してみました。このあたりの話題にそこまで詳しくない方でなくとも理解できるように解説しているつもりです。
Webブラウザやクローラーが情報を受け取る仕組み
私たちは普段、FireFoxやChrome、SafariなどのWebブラウザを通じてURLにアクセスしてWebコンテンツを閲覧しています。この「URLにアクセスする」ときに、Webブラウザは「リクエスト」を送り、Webサーバーが「レスポンス」を返す、というやり取り（通信）が行われています。
リクエストを送る側は、「サーバー（提供者）」に対して「クライアント（依頼者）」と呼ばれます。Googleのような検索エンジンのクローラーもブラウザと同じくクライアントという扱いになります。
HTTPステータスコードとは？
WebブラウザやクローラーがURLにアクセスしようとするとWebサーバーからどのようなレスポンスを受け取っているのか？というのは例えばGoogleのウェブマスターツールの基本機能「Fetch as Google」などを使って知ることができます。
※図の中の赤枠以下の情報を受け取っています。
少し見づらいですが、通常通りアクセスできてコンテンツの情報が得られる場合にはブラウザやクローラーはこのようなデータをWebサーバーから受け取っています。
ここで少しだけ專門用語を使うと、上の図にあるようなレスポンスは「ステータスライン」「レスポンスヘッダ」「メッセージボディ」の３つから成っています。
レスポンスヘッダとメッセージボディについては今回本題から外れますが、折角ですので合わせて簡単に解説します。
ステータスライン
ステータスラインは一番上に記述されている「HTTP/1.1 200 OK」や「HTTP/1.1 301 Moved Permanently」等のようなもので、「レスポンスの状態」を表します。この中の「200」や「301」といった３桁の数字が今回の話題となる「ステータスコード」です。「OK」「Moved Permanently」は「説明句」というもので、その名の通りステータスコードの内容説明をするものです。
クライアント（WebブラウザやGoogleBot）はWebサーバからどのステータスコードが返ってきたかによって、その中身を見なくとも次にどんな処理を行えばよいかを判断することができます。
レスポンスヘッダ
レスポンスに付与するメタ情報が記載されている部分です。ここでいうメタ情報とは、「（受け取った）データに関する補足情報」のようなものと思って下さい。例えば、URLが転送（リダイレクト）されている場合に転送先のURLの情報を「Location」として付与する、などの情報です。
メッセージボディ
いわゆる”本文”にあたるもので、Webページに問題なくアクセスできた場合にはHTML情報がここに記載されます。私達が普段見ているWebページはこのHTMLテキストをブラウザが解釈して表示したものです。
さて、本題のHTTPステータスコードについて話を戻します。
HTTPステータスコード
ステータスコードは本来ブラウザやクローラーが処理するために付与されているものなので、普段私達がブラウザ上でWebページを見ている際に見ることはありませんが、時々エラーでこんなのをお目にかかることはありますね。
また、Google Chromeに標準搭載されているDeveloper Toolsや、Firefoxのアドオン（Live HTTP headersやFirebug等）を使えばレスポンスに含まれているHTTPステータスコードを確認することができます。今回はその使い方は割愛させていただきますが興味の有る方はお試しください。
それでは次節からは本題であるステータスコードについてお話をさせていただきます。
ステータスコードの大まかな分類と意味
さて、ステータスコードは大まかに分けて5つに分けられます。
- 100番台 : 処理中
- 200番台 : 成功
- 300番台 : リダイレクト
- 400番台 : クライアントエラー
- 500番台 : サーバエラー
このようにそれぞれの番台によって異なる意味を持っています。個別のステータスコードの前に、まずここでは各番台について簡単にその意味を説明しておきます。
100番台
100番台はクライアントからのリクエストを処理中であることを示すステータスです。
Webサーバ側からクライアント側に対して「もうちょっと詳しくやってほしいことを教えてくれ」とか「今、頼まれたことをやってるんだけども時間かかるわ」という内容のレスポンスを返します。これらのステータスコードが使われている場面はあまり見かけません。
200番台
200番台はクライアントからのリクエストが受付に成功したというステータスです。私達がWebページを見ているとき、多くが200番のステータスです。
300番台
300番台は「リダイレクト」と書きましたが、厳密には「リクエストを達成するためには、ブラウザ側で追加の処理を実行する必要がある」というステータスです。
その追加の処理が301では例えば「別URLへの移動」になります。301番、302番のコードについては「301リダイレクト」「302リダイレクト」などサイトURL変更の際の転送処理として聞いたことのある方が多いのではないでしょうか。
400番台・500番台
400番台、500番台のコードはエラーコードであり、正常にリクエストされたものが返せない状態のときに使用されます。そのうち400番台はクライアント側に原因があるエラー、500番台はWebサーバ側が原因のエラーです。
それぞれのステータスコードについて
ここまででざっくりとした分類をお話ししたので、本節ではそれぞれのステータスコードについてお話します。今回は普段の業務を行う中で比較的頻繁に目にすることの多いメジャーなものに絞りたいと思います。
200 OK
リクエストは問題なく受理され、要求に従ったレスポンスが返されます。私達がWebページを正常に閲覧している際、大抵このステータスとともに返ってきたレスポンスの内容を見ています。
301 Moved Permanently
リクエストで要求された情報の中身が別の場所に移動したことを示します。
この移動は一時的なものではなく、恒久的なものです。サイトの引越しを行ったりしてアクセスするURLが変更され、ずっとそのURLを使用していく場合にこのステータスコードを返すようにしておく必要があります。
googleからの評価を新しいURLに引き継がせるためにも301を設定しておきましょう。また、あるページへのアクセス経路を一本にまとめる、いわゆるサイトの正規化を行う場合にもこの301リダイレクトを使用します。
302 Found (※Moved Temporarily)
こちらもリクエストで要求された情報の中身が別の場所に移動したことを示します。301と異なるのは、その移動が一時的なものであるという点です。
たとえばメンテナンス等で一時的にサイトを別の場所に移さなければならないが、また元の場所に戻す場合はこの302番のステータスを返すように設定しておきましょう。GoogleBotもそれが一時的な移動であることを読み取ってサイトの評価を移動先のURLに移すことはしません。
※302は昔の規格(HTTP/1.0)では説明句が「Moved Temporarily」でしたが現行の規格(HTTP/1.1)になって「Found」に変更されました。一時的な転送、という以外でも利用されることが多かったためのようで、現在別の307という比較的マイナーなステータスコードで「Temporary Redirect」が割り振られていますが、実際の使用例は見たことはありません。
304 Not Modified
これはリダイレクトではありませんが、補足的に説明をしておきます。
304は「未更新」を表します。私達が正常にWebページを見れているとき、多くは200ステータスが返ってきているのですが、実際には304ステータスのコンテンツが混じっていることもあります。このときWebサーバからはメッセージボディ、つまりコンテンツが返ってきません。ブラウザ側では304を受け取ると、ブラウザ内のキャッシュに残っているコンテンツを使ってWebページを表示しています。
403 Forbidden
サーバ側で外から見えないように設定してある領域へのアクセスをリクエストしたときに返ってくるステータスコードです。簡単に言えば立ち入り禁止です。
見せたいページでこのエラーが出ているときはアクセス制御の設定が間違っている可能性がありますので設定ができる方は確認してみましょう。
404 Not Found
リクエストしたページが見つからない場合に返されるステータスコードです。
ウェブマスターツールではGoogleBotが検出した404エラーをレポートしてくれていますが、特に404エラーが多いからといってgoogleからのサイトの評価が下がることはないと言われています。サイト内からリンクされているページが404エラーになっている（＝リンク切れ）のは問題ですが、そうでない限りは放置しても良いかと思います。
他サイトから多くのリンクを受けているようなページを404エラーとしてしまうと、折角サイトが得られた被リンクの恩恵を逃してしまうことになります。何かしら代替のコンテンツを用意してそのページを残しておくか、近い内容を持つページに301リダイレクトするなどでリンク資産をサイト内に残せる処理をするのが一般的です。
410 Gone
404と同じくリクエストしたページが見つからない場合に返されるステータスコードです。404と違う点は、そのリクエスト先のページが「消滅した」という意味合いがあることです。
こちらの記事によると最近はGoogleBotは404と410を微妙に区別しているとのことですが、記事でも書いてあるようにそこまで神経質になる必要はほとんどないと思います。
補足：ソフト404エラー
ブラウザ上ではそのページが存在しない旨のメッセージが表示されているにも関わらず、ステータスコードとしては404や410を返していない（つまり正常なレスポンスとして「200 OK」が返されている）パターンが存在します。これを「ソフト404エラー」などと呼びます。
どういうときに発生するかというと、例えばサイト運営側で独自にエラーメッセージ表示用のコンテンツを作成して、想定していないURLに対してリダイレクトをかけてそのコンテンツに飛ばすというケースが考えられるでしょうか。
Webページを見ているユーザに対してページがないことが伝わっても、機械的にHTTPステータスコードを読み取るbotに対しては伝わりません。このようなソフト404ページが存在するとGoogleBotがクロールのリソースを無駄に消費することになりますので、存在しないページにアクセスしたときはステータスコードとして404もしくは410が返されるように正しく設定するべきです。
500 Internal Server Error
サーバ側の何らかのミスによってリクエストに応えられない場合です。例えばシステム開発中にバグを混入させてしまうとこのエラーを起こすことがあります。
503 Service Unavailable
Webサーバの過負荷状態で一時的にWebページが表示できないときなどに発生します。例えばTwitterがクジラを表示させている状態、とでも言えばイメージが沸きやすいでしょうか。
メンテナンスでサービスをストップさせている際に意図的に503を返すように設定することもありますが、基本的にはサーバー負荷の問題ですので頻発するようであれば、サーバーの変更を検討するか、サイト側での負荷軽減などの手を打つ必要があります。
まとめ
ここまでHTTPステータスコードについてのお話をさせていただきましたがいかがでしたでしょうか。表には出てこない部分ではありますが、こうした部分まで意識してみることができれば、今よりもクローラにとって優しいサイトが作れるかもしれません。
特に一般の方（技術に関わりのない方）にとってはこうした話というのはあまり重要視されにくい話題と思いますが、SEOの観点では、サイトが検索エンジンに正常にクロールされ、正しく検索インデックスに登録してもらえるための基本的な作法として、サイトを制作・管理する方には皆さまに理解していただけると嬉しいです。
文責：ヴォラーレ株式会社 西村