2021年3月 Archives

SEO対策においては被リンクの獲得が重要になりますが、オーソリティーサイトからリンクをもらうと検索順位が上昇するといわれています。

逆にいえば、リンク元のオーソリティー性が重要になるわけですが、オーソリティーであるならば、最低限、そのサイトにはアクセス数が発生していることが絶対条件となります。そのため、アクセス数の全くないサイトから被リンクを受けていてもあまり意味がありません。

また「被リンク=アクセス数」の関係において、そもそもアクセス数の少ない状態では被リンクの発生しようがないという原因もあります。

人はリンクをする際、そのページを認識していなければなりませんが、そもそも検索結果で表示されていない状態では認識のしようがありません。

つまり、検索結果で上位表示されるからリンクされるのであり、月間10万ページビュー程度でもあれば、黙っていても月に100本、200本程度の被リンクは増えていくものです。

富める者はますます富み、貧しきものはますます貧しくなる、インターネットはそういった悪循環の仕組みになっているわけです。

それではどうすればよいのかといえば、最低限、ある程度のページビュー数が発生するまでは自力でそこまで持っていかないと、検索経由のアクセス数自体が発生しないという状況に陥ってしまいます。

ただし、一旦、上位に表示されれば、そのあとのサイト運営は比較的、楽になっていくものと思います。

個人的には、この負の悪循環を止めるためにも、検索アルゴリズムにおいて補正すべきと考えていますが、現状では上位表示したもの勝ちの状態になっているものと思います。

<HEAD>タグ内には、<title>や<meta>、CSSなど様々なタグがありますが、これらの順序はどのように記述すべきでしょうか?

まず一番最初に記載すべき要素についてですが、やはり<title>タグが最初と考えてます。大手メディアなどを参照しても一番先は<title>となっているケースが多いですし、一番最初に書くべきは<title>でほぼ間違いはないでしょう。

この<title>タグに対して、<meta name="description"や<meta name="keywords"などについては無くても機能しますので、titleタグよりも重要度ははるかに劣るものと感じています。特にmetaキーワードについては、各国の主要な検索エンジンでは利用されているケースもあるかもしれませんが、Googleについては既に意味はなくなっているため、記載してもあまりメリットはないかもしれません。

また、descriptionについては、serpで表示された際の使い方がメインになりますし、インデックスが更新されるまでは検索結果では反映されないため、今すぐ直ちに必要なわけでもないはずです。

気をつけるべきはJavascriptですが、先頭の方にこれを書いておくとそこで読み込みが止まるため、できるだけ後の方に持っておくのが一般的かと思います。

また、CSSについては同時に並行して読み込まれますが、ダウンロードするまではレンダリングが始まらないため、今すぐ必要な緊急性という面で考えると、descriptionやkeywordよりも先にCSSを記載すべきとも感じています。また、もしCSSを記載するならば、そのCSSよりも前に<link rel="preload"や<meta name="viewport"の方を先に記載すべきかもしれません。

そのため、個人的にはtitle→viewport→preload→CSS→description→keywordの順番でもありかと思います。

ただ、この「titleとdescription、keyword」の3つについては、昔からセットで記載されてきましたので、「title、description、keywordの3セット」→「viewport、CSS」といった順で記載するのがぶなんかもしれません。

次に、OGPタグを記載するのもデファクトスタンダードとなりつつありますが、こちらも今すぐその場で必要というわけでもありません。

シェアされてからタイムラインで表示されるのに数秒遅れるぐらいでは何の影響もないでしょうし、そもそもシェアされるかどうかも分からないため、OGPタグについては一番最後に記載しておけばよいでしょう。

また、OGPタグの"og:url"についてはURLのカノニカルタグになるため、本家のrelカノニカルの「<link rel="canonical"」については、OGPタグより前に記載するべきかと思います。

また、<link rel="canonical"を記載するならば、その次にAMPページの<link rel="amphtml、ガラケーページの<link rel="alternate" media="handheld"と続けてまとめて記載するのがスマートかもしれません。

まとめますと、「title、description、keyword」→「viewport、CSS」→「canonical、amphtml、handheld」→「OGP関連のタグ」→「Javascript関連」といった順序がよいのではないかと考えてます。

迷いがあるのは、<link rel="icon"ですが、ChromeデベロッパーツールのPerformanceで確認する限り、こちらはonload後の読み込みとなっていたため、レンダリングや読み込みが完了した後で参照されるものと感じています。

アイコン画像はブラウザのタブなどにも表示されるため、その場で直ちに必要ではあるものの、CSSほどの緊急性はないのかもしれません。そのため、CSSの後でカノニカル正規化タグの前あたりがぶなんかなと感じています。

当サイト運営者の場合、サイトのダウンロードサイズは広告関連でのスクリプトの負担が転送量の大部分を占めています。

特にアドセンス広告の読み込みの容量が大きく、概ね数百KB程度となっている傾向があります。

ひと昔前なら画像が主な負担になっていましたが、最近は画像よりも広告関連のスクリプトの負担の方が大きいです。

例えば、ヤフーのトップページをチェックしてみますと以下のようになっていました。

Script:36リクエスト:「583.4 KiB」
Image :38リクエスト:「391.1 KiB」

合計で約1MB(1,000KB)程度のダウンロードサイズですが、すべての合計サイズは概ね1,000KB程度に抑えるべきと考えています。

この1,000KBのうち、どの程度までをWEBフォントに使えるのかでいえば、当サイト運営者の場合は300KB以内までと決めています。

WEBフォントは外部サービスからダウンロードするのだから、除外してもいい気もしますが、WEBフォントもサイトのサイトの転送量には入ります。

「バナナはおやつに入りますか?」みたいな議論になってしまいますが、訪問者にとって、それがサードパーティーのものであるか、そのサーバーからの配信であるかは関係なく、実際にかかる転送量が問題になります。

その点、なかにはWEBフォントのみで1MB程度、すべての合計で3MB以上を使用しているケースもありますが、これはモバイル環境のユーザーにとって負担になるはずです。

理想としては、WEBフォントのサブセット化で300KB程度におさえ、画像を300KB程度使用し、その他の広告やテキスト、CSSもろもろで200KB、合計で800KB程度のサイトに抑えるのがベストではないかと考えています。

PCサイトの場合、シェア的にはWindowsユーザーが多いため、私はデフォルトのメイリオではなく「Notoフォント」を使用することが多いです。

その一方で、モバイル端末のスマホサイトの場合、iPhoneユーザーのシェアが多く、この場合はサファリになるため、綺麗に表示される「ヒラギノ角ゴ ProN W3」を使うことができます。

この「Noto」と「ヒラギノ」を天秤にかけた場合、フォントの美しさという点では互角か、もしくはわずかに「ヒラギノ」に軍配が上がると感じています。そのため、あえて転送量が大きくなるWEBフォントの「Noto」をモバイル端末向けに使用する必要性はないと考えており、モバイル端末ではWEBフォントを無効にしています。

大手サイトを閲覧しても、おおむねWEBフォントは使用されていないことが多く、基本的にはメイリオが使用されています。個人サイト等でWEBフォントを使用しているケースも多いですが、それがかえって読みにくくなっているのではないかと感じることもあります。

そのため、個人的にはサイトでWEBフォントを使用する必要はないと感じており、モバイルサイトでは上記の理由でなおさらないと考えてますが、もし使用するなら、PCサイトでのみ表示されるようにするとよいでしょう。

フォント専用のCSSを作成し、 media="screen and (min-width:480px)">などと指定して、PCサイトでのみ読み込む形にすると最適化できると思います。