どうもダメ人間です。
この記事ではSEO対策に触れて「意外！」と思ったこと、そしてたまたま見た楽天Infoseekなるものが10記事読むだけでなくに10秒以上の滞在でポイント配布している、という条件提示をみて、しみじみとした気持ちになったので、記録してみました。(結局サイトの離脱率、滞在時間とSEOの関連性については１ミリも触れられていない)
SEO対策として大切なGoogleSerchConsoleやAnalitics以外でできる内容を記載しています。
振り返ると、自分がやったことは「SEO対策」よりは「読み込み速度改善」寄りです。
目次
I. 意外だった７個のこと
1. metaの中にKeywordはいらない
2. (ベタだけど)h1タグは1ページに１回だけ！！！
3. 意外とパンくずリストが大事だった件について
4. 写真のレスポンシブに「pictureタグ」を使うべし！
5. robots.txtは(大規模でなければ)意味(があるわけでも)ない。〜クローラーさんのクロール力の賜物〜
6. 「コアウェブバイタル」という概念 〜Webページも健全さが測られている〜
7. 随時改訂されている！ 【2024年3月にコアウェブバイタル改訂など】
II.実際使った4個のこと 〜読み込み速度改善偏重案件〜
1. 画像形式の変換
2. 画像の遅延読み込み 〜widthとheightがないとSEOのコアウェブバイタルであるレイアウトシフトにズレだと認識される〜
3. cssの遅延読み込み
4. descriptionの設定
意外だった7個のこと
1 metaの中にKeywordはいらない
Google はウェブ ランキングにキーワード メタタグを使用しません
https://developers.google.com/search/blog/2009/09/google-does-not-use-keywords-meta-tag?hl=ja
くっ。公式からそうきちゃっていたってことでしたか。
「SEO対策をやる=キーワード選んで、盛り盛りやるぜ、(ゴゴゴゴゴ🔥)(cv.子安武人)」という認識を持っていたダメ人間。
大打撃を受けました。(ゴーン)
色々な会社のHPのkeywordを確認しにいったものの、結構スルーされていました。
個人的には白背景に白文字詰め込む意気込み、好きだったんだけどなぁ。(古い)
2 (ベタだけど)h1タグは1ページに１回だけ！！！
Google先生によると、"どのテキストがメインタイトルか、を明確にすることが重要"とのこと。
「h1タグがたくさんあるから減点」、というわけではないようだ。
「一番伝えたいこと」、がh1タグの乱立によって、ユーザーにもクローラーにとっても不親切になってしまう===SEO的にも良くないということなのだろう。
Google は、ページ上でメインとなる大見出しや他、見出し要素、その他の大きく目立つテキストなど、タイトルリンクを作成する際のさまざまなソースに注意を払います。
Google 検索では、大きくて目立つ見出しが複数あることを検出すると、最初の見出しをタイトルリンクのテキストとして使用することがあります。
https://developers.google.com/search/docs/appearance/title-link?hl=ja
調べてみると複数回使われているサイトが意外とあるある！で逆にびっくりした。
おそらく保守開発やらなんやらの追記などで増えてしまったのかもしれない。知らんけど。
※Googleの拡張機能で簡単に表示できる↓
https://chrome.google.com/webstore/detail/seo-meta-in-1-click/bjogjfinolnhfhkbipphpdlldadpnmhc?hl=ja
3 意外とパンくずリストが大事だった件について
名前が謎すぎる「パンくずリスト」(breadcrumb navigation)。
サイトのパンくずリストはカラスも人間も食べられない、全然、何ーも、何ーらおいしくない存在。
その「迷わせないでいさせてくれる」という概念的な意味合い(?)から、童話「ヘンデルとグレーテル」の「パンくず(breadcrumb/s, breadcrumb navigation)」が由来とされているようです。
Google先生は「内部リンクの最適化」、またリンクの構造化という観点からパンくずリストをおすすめしています。
パンくずリストとは、ページの上部か下部にある内部的なリンクの行です。
訪問者はパンくずリストを使って、前のセクションやルートページにすばやく戻ることができます。
パンくずリストを表示する場合は、パンくずリストの構造化データのマークアップを使用することをおすすめします。
https://developers.google.com/search/docs/fundamentals/seo-starter-guide?hl=ja#usebreadcrumbs
「パンくずリスト」という名前を考えた人の思考回路がメルヘンすぎて見習いたいと感じました。
(複数の文献をあたってみたものの、明確に「誰が」「breadcrumb」という呼び方を決めたのかという決定打は見つけられず。)
食べられない物に食べ物っぽい名前をつけるのは反則です。
(米派だが焼きたてのパンが食べたくなる。)
なんにせよ！
Google大先生が Google公式SEOスターターガイド の項目の一つとして用意し、説明してくれている、という事実に尽きます。
鬼退治にはきび団子。SEO対策にはパンくずリスト！
4 写真のレスポンシブに「pictureタグ」を使うべし！
これが今回のSEOに向き合った中で一番後悔していること。
とてつもなく簡単そうなのに、実は使えず。悔しさが残る逸品。
画面幅ごとのwidthとheightを指定すればいいものの、「地震・雷・火事・カラム落ち」(ダメ人間的コーディングコーディング4凶のためにスキップしてしまった。(殴)
次回以降、写真を使うwebサイトをコーディングする機会があればズェッタイに使います(確信)
Google先生の言及は以下の通り。
ウェブページでは、 要素や、img 要素の srcset 属性を使用してレスポンシブな画像を指定します。
https://developers.google.com/search/docs/appearance/google-images?hl=ja#responsive-images
picture 要素は、1 つの画像ソースに複数の密度が存在する場合や、レスポンシブ デザインで画面の種類によって画像が若干異なる場合に使用します。video 要素と同様に、複数の source 要素を含めることができるため、メディアクエリや画像形式ごとに異なる画像ファイルを指定できます。
https://web.dev/articles/responsive-images?hl=ja
<picture>
<source media="(min-width: 800px)" srcset="head.jpg, head-2x.jpg 2x">
<source media="(min-width: 450px)" srcset="head-small.jpg, head-small-2x.jpg 2x">
<img src="head-fb.jpg" srcset="head-fb-2x.jpg 2x" alt="a head carved out of wood">
</picture>
5 robots.txtは(大規模でなければ)意味(があるわけでも)ない。 〜クローラーさんのクロール力の賜物〜
今回SEOのことをggっていて初めて知った「robots.txt」。
これ使ったらなんかカッコよくね？と思った。
Google先生のドキュメントを読む限りでは、トラフィックの制御や、無駄なクロールの回避などを防げる優れものだと捉えられると思います。
Google のクローラからのリクエストによってサーバーが過負荷になっていると考えられる場合に、ウェブページ（HTML や PDF など、メディア以外で Google が読み取れる形式）に対して robots.txt ファイルを使用することで、クロール トラフィックを管理できます。また、サイト上の重要でないページや類似したページのクロールを回避することもできます。
https://developers.google.com/search/docs/crawling-indexing/robots/intro?hl=ja#what-is-a-robots.txt-file-used-for
特に数百ページ以内のサイトであればサイト状況にもよりますが、クロール、インデックスは問題なくされることが多いです。
当然、robots.txtを設置するだけで、順位が上がるなどの裏技があるわけでもないので、クロールの制御を行う必要のないサイトでは、無理に設置しないでください。
https://www.seohacks.net/blog/965/
クローラーによるサイト内の各ページへのアクセス管理を行なった方が良いのは、ページ数が1,000を超える中・大規模なサイトです。小規模なサイトであればクローラーの最適化は基本的に不要です。
サイトの成長に合わせ、必要になったときにrobots.txtファイルを作成し、SEO対策に役立てましょう。
https://emma.tools/magazine/robotstxt/#robotstxt-4
「効果あるよ。ただし、大規模ECサイトレベルの規模感に限る✋」、といったところだろうか。
クローラーさんたちは数十ページなんてヨユーでクロールでき、「ここはクロールしなくていいよ」と伝えようが伝えまいが、大体クロールしてくれる為、効果があるとしたら「年末年始のお知らせ」などのあまり力を入れていないニュースページを意図的にクロールさせない、などのことだろうか。
だが、必要なページがクロールしてもらえない、といった悲劇を防ぐためにも、中小サイト規模であるならばあまり必要性が感じられないものにはなっているように感じた。
6 「コアウェブバイタル」という概念 〜Webページも健全さが測られている〜
これは”サイトのユーザーの体験の良し悪しを測る指標”ということらしい。
医療ドラマとかで耳にする「バイタル、安定してます！」のバイタルは、
バイタルサイン、つまり脈拍、呼吸、血圧、体温等の測定
https://www.mhlw.go.jp/seisakunitsuite/bunya/hukushi_kaigo/shougaishahukushi/kaigosyokuin/text.html
(参照：厚生労働省、平成24年度 喀痰吸引等指導者講習事業（第三号研修指導者分）資料)
Googleが定義するバイタル(コアウェブバイタル)は・・・
コアウェブバイタルの指標となるのが「LCP」「FID」「CLS」の3つ
https://developers.google.com/search/docs/appearance/core-web-vitals?hl=ja
◼︎ LCP(Largest Contentful Paint):読み込みパフォーマンスの尺度。
👉意) ページ早く表示してね(圧)
◼︎ CLS(Cumulative Layout Shift):視覚的な安定性を評価する指標
👉 意) 読み込み後の位置ずれでユーザーに変なボタンとか押させることがないように(圧)
◼︎ FID(First Input Delay):インタラクティブ性の尺度
👉 意) そっちがクリック・タップさせるんなら、サクサク表示させてね(圧)
※「100ms以内で表示できればめっちゃいい評価あげるよ」とGoogleは言っている
Webサイトは「高血圧」や「熱出ちゃった。。」ということはないだろうが、
Google的には「ページ速度がゴミ遅なので表示順位下げて休んでくださいね(はぁと)」だったり、
「画像初回読み込み時からズレを検知！誤操作を招く！下位表示に評価！！(キリッ)」といったところだろうか。
7 随時改訂されている！ 【2024年3月にコアウェブバイタル改訂など】
i. コアウェブバイタルの改訂
※発表自体は2023年5月にされており、この記事公開時点では約半年前の古い情報であることを予めご了承ください。
2024 年 3 月に、FID の代わりに新たに採用される INP が Core Web Vitals の指標の一つとなります。
(2023 年 5 月 10 日（水曜日）)
https://developers.google.com/search/blog/2023/05/introducing-inp?hl=ja%3C&authuser=0#what-this-means-for-google-search-consoleINP は、ユーザーによるページへのアクセスの全期間中に発生するすべてのクリック、タップ、キーボード操作のレイテンシをモニタリングすることで、ユーザー操作に対するページの全体的な応答性を評価する指標です。
https://web.dev/articles/inp?authuser=0&hl=ja#what_is_inp
というわけで。
「最初の読み込み」だけではなく「ページ全体の読み込み」へとGoogle先生の要求が高まりました、という情報でした。
ii. SEO対策の姿勢基本の基本
あまりにも基本の基本すぎることなのかもしれないが、「鮮度」が意外と大切だった。
多くの人に利用される検索エンジンを最適化するためには、Google先生が公表しているドキュメントを味方につけるのが一番！！！！！
（常に技術が向上していて、「あんなことできたらいいな」がハイスピードで実現されまくって、高みを目指してGoogle先生がPDCAを回しまくっているため）
だがしかし。
このドキュメント、
<<<トッテモヨミヤスイィィィ、、>>>
とは言えないのではないだろうか。
(by 公式ドキュメント苦手芸人)
そのため、公式ドキュメント苦手芸人の方は、検索上位のまとめ的なものを懐疑的に読みつつ、(たまに間違ったことが「SEOサイト」を名乗る検索上位サイトの記事の中にもあった(ソースは自分))
Google公式のドキュメントで脆弱性の補強をするのがいいのではないかと感じた！
実際使った５個のこと 〜読み込み速度改善偏重案件〜
書き出してみてわかったのは「当たり前のことしただけじゃぁないか。」「SEO対策というよりは読み込み速度に全振りしてただけじゃぁないか。」(cv.子安武人)ということ。
はい。タイトル詐欺です。自分には無理でした。。。。。。。。
でも。
ページ速度もSEO対策の一つとしてゴニョゴニョ...(もっといい感じの対策を是非講じてください(ダメ人間))
また、書きようによっては「逆にJS増えてね？」だったり、画像フォーマットであれば、SVG形式だと新しいフォーマット(今回試したのはWebP)にしたとて、数KB増えてしまったりもした。(SVG以外はそういったことはなかった。)
1 画像形式の変換
「サクサク」見れる、ストレスなく表示できる、というのはユーザーの体験向上させる重要なポイントで、たった画像形式一つでファイルの大きさがマージで変わってサクサクになる！
今回、JPGやPNGから、ブラウザ対応範囲の広い「WebP」に変換したところ、かつやのトンカツ衣に負けないくらいサックサクになった。
Google先生は「良質で高速な画像を使ってね」と言っている
最新の画像最適化技術やレスポンシブ画像技術を使用して、良質で高速なユーザー エクスペリエンスを提供するようにしてください。
https://developers.google.com/search/docs/appearance/google-images?hl=ja#:~:text=Google%20%E6%A4%9C%E7%B4%A2%E3%81%A7%E3%81%AF%E3%80%81%20BMP%E3%80%81GIF,%E3%82%92%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88%E3%81%97%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%80%82
また、「最新の画像最適化技術」のリンク先の一つである「WebPを利用する」の項目では(最終更新日 2018-11-05ではあるものの)以下のように記載されている
WebP 画像は JPEG や PNG よりも小さく、通常はファイルサイズが 25 ～ 35% 削減されます。これにより、ページサイズが小さくなり、パフォーマンスが向上します。
https://web.dev/articles/serve-images-webp?hl=ja
2 画像の遅延読み込み 〜widthとheightがないとSEOのコアウェブバイタルであるレイアウトシフトにズレだと認識される〜
強気な名前の「loading="lazy"」。
ファーストビュー画像には使わない方がいい、などあるが、適用ブラウザも多く、
本当に「loading="lazy”」と書くだけ。
ダメ人間でも書けた。
そしてGoogle先生オススメの一手でもある。
重要でないコンテンツや非表示のコンテンツの読み込みを後回しにすることは、一般に「遅延読み込み」とも呼ばれ、パフォーマンスおよびユーザー エクスペリエンスに関する一般的なおすすめの方法としてよく行われます
https://developers.google.com/search/docs/crawling-indexing/javascript/lazy-loading?hl=ja
画像に width 属性と height 属性がないと、Cumulative Layout Shift への影響が大きくなります。
https://web.dev/articles/browser-level-image-lazy-loading?hl=ja#the_loading_attribute
※画像が多い場合、一つ一つ全てに記載するとなると、効率面や本末転倒な事態になりかねない可能性も。
JSを使う、まとめて指定する、など色々な記載方法があるため用途に合わせて使いたい。
【例１】読み込み中の画像表示の前に動画が実装されているサイトの例１
特にお気に入りなのは「笑うメディアクレイジー」さんのクマ(?)がたぬきの被り物をするGif。ぴょこぴょこ動いて、待ち時間をさほど苦に感じさせないように思った。遊び心があり、心理的効果もあるのかも。
もちろん
参照：「顔は絶対に触らせてくれないネコ」のディフェンス力が高くて笑ったｗ
by笑うメディアクレイジー
【例2】読み込み中の画像表示の前に動画が実装されているサイトの例2
ずっと気になってたzozoのギターマン。取り入れたのはzozoの遊び心から来ているらしい。(参照：zozo採用サイト)
こちらはimgタグ内ではなく、JavaScriptで・・・(圧縮されているため見つけるのに手間取った)
また、画像をたくさん使うECサイトでもloading="lazy"は使われている、はず、、、
と流れで書きたいところではあったのですがしかし。
ZOZOさんには「loading="eager"」が仕組まれていた。。。
eager
既定の動作で、 eager は要素が処理されたらすぐに画像を読み込むようにブラウザーに指示します。
https://developer.mozilla.org/ja/docs/Web/API/HTMLImageElement/loading
Qiitaのおすすめ記事に loading属性の落とし穴から学ぶ、機能拡張と初期値・デフォルト挙動の話という、めちゃくちゃ役立ちそうな記事があり、
loading="lazy"の記事を書くなら読まなくては。。と思いつつ、結構濃ゆくて読めていなかったのが運の尽き(殴)
著者様はまとめ部分で
Chromeでは、loading属性を全く書かずに従来通りimgやiframeを書いたとしても、暗黙にデフォルトでloading="auto"が指定されたものとされ、ネットワーク環境次第で意図せずloading="lazy"の挙動を起こしてしまい、ページ全体のonloadがあてにならなくなってしまうという落とし穴がある。それを防ぐには、明示的にloading="eager"を指定せねばならない。
https://qiita.com/spaceonly/items/9d9b3fe46e43524a535a#%E3%81%BE%E3%81%A8%E3%82%81
とおっしゃられている。
まさに落とし穴ハマる前にすっ転んでいる状態じゃあないか。
(すでにこの記事に相当な時間がかかっておりこの記事で解決する気が起きていない。。)
参照：ZOZO公式HP
まあ。
ブラウザによって挙動が違う落とし穴については熟知しつつloading="lazy"を使ってユーザー目線の実装を心がけたいと感じた所存です。。。
3 cssの遅延読み込み
複数のcssを読み込んでいる場合(ライブラリのcssなど)、重要でないcssの読み込みに適用した。
のように、media="print" onload="this.media='all’”を付け足すだけ。cssの遅延読み込みについては複数あり、rel=preloadを使う方法、JSやjQueryを利用する方法などがある。
それぞれ適用ブラウザなどの制限があるものの、特段デメリットなどは把握できなかった「media="print" onload="this.media='all’」を利用させていただいた。(甘い根拠)
・rel=preloadを使う方法
preload は 要素の rel 属性の値で、その HTML の
の中で読み取りリクエストを宣言し、ページのライフサイクルの早期の、ブラウザーの主なレンダリング機構が起動する前に読み取りを始めたい、すぐに必要なリソースを指定することができます。
「rel=preload」、 MDN公式
・その他JavaScriptを用いて遅延読み込みする方法についてまとめて書いていただいているサイト
を参照されたい。。
(自分も参照して比較検討したいと思います。)
4 descriptionの設定
意外と書かれていなかったり、同じ内容がコピペされていたりするdescription。
keywordが無視される今、descriptionに色々ぶち込むのがいいのではなかろうか。
Google先生は以下のようにおっしゃっている。
Google は、表示する個々のサイトのスニペットを手動で変更することはできませんが、できるだけ関連性の高いものとなるよう常に努めています。表示されるスニペットの品質を高めるため、質の高いメタ ディスクリプションを作成するためのおすすめの方法に沿ってページを構築してください。
https://developers.google.com/search/docs/appearance/snippet?hl=ja
meta descriptionの内容についてはサイトには表示されない文章になる。
関連性のない内容については避けたいものの、description内にロングテールキーワードを入れてみたり、簡潔かつスニペットに表示しても遜色ない文言を挿入することについては推奨される事象なのではなかろうか。
(やっとこの記事書き終わった。)
まとめ
参考にした記事
Google先生の
SEO記事に関するSEOをめちゃくちゃ頑張ってる
海外のSEO対策サイト
読んでいたSEO関連記事の中で、専門性が高く、最新情報も随時UPDされていて参考になると個人的に感じたサイト
感想
SEO対策とは、本当に「いかにユーザーがサクサク有益な情報に巡り合えるか」を重視しているのだ、とGoogleの熱を感じた。
また、真剣に向き合ったとは言えど、敢えて今回GoogleSearchConsoleやAnalyticsのことなどは記載してこなかった。
付け焼き刃の知識では太刀打ちできないと言えよう。
と同時に、味方につけたら怖いものないな、と感じた。
調べているといいサイトが下位表示されて、全面広告がバンバンなサイトが上位表示されていて世の非情を感じて悲しくなる。
それと同時に、「嫌だな」と感じるサイトにはきちんと評価が悪くなる仕組み作りがある(広告枠案件以外)、ということに興味深さを感じた。
これからは全面広告出て記事出なかったり、ほぼコピペ内容サイトは秒で閉じようと思った。
そして、10数秒毎に何度も自動的に出てくるモーダルウィンドウ広告にイラッとし、そっとページを閉じる今日この頃である。
最後に
最後に、特に関係はないのだが、近況報告と東京都の最低賃金についてふと思ったのでメモ。
・東京都の最低賃金は1113円になったらしい。
・社長になってみたい
自分にとってこれまで社長(=なんか色々実現するためにブラックになるやつ)だと思っていた。
ブラック企業は嫌いだ。
だがしかし。
社長という生態、無駄にキラッキラしてないか？ (という n=2 のサンプルデータから偏った認識を持ってしまった。)
社員はいらないので社長になってみたい(社長とは)。社長にならなくてもいいが、社長という生態(?)モチベ、実行力に近づきたい。
言うだけで行動できないダメ人間の戯言でした。。
さらば。