「SEO に強い HTML の書き方」というツイートがそこそこバズっていて、その内容に対して駆け出しエンジニアの方たちが「参考になった」などと称賛の声を挙げていたのを見かけて思うところがあったのでこの記事を書きました。 元ツイの概要は次の通り。 body > main > article > sectionに h1は 1 ページに 1 つ（要キーワード） 見出しタグは毎度 section で囲む ヘッダーメニューは nav で囲む 画像に適切な alt を設定する title / description を書く 階層を意識して書く div はあまり使わない 画像は p で囲む この記事は元ツイおよび元ツイの投稿者を批判する意図で書いたものではなく、あくまで挙げられている内容に対する個人的見解をまとめたものです。 正しいか正しくないかをそれぞれの項目のはじめに書いていますが、あくまで僕個人の

[レベル: 上級] rel="nofollow" 属性の扱いを Google は変更しました。 従うべき命令としてではなく、手がかりのためのヒントとして利用するようになります。 また、nofollow の派生型として、link タグと用いる 2 種類の rel 属性を新たに導入しました。 nofollow 属性の扱いを変更 rel="nofollow" 属性が付いたリンクを Google はこれまでランキング要因としては利用していませんでした。 PageRank を渡すこともないしアンカーテキストも評価しません。 そして、nofollow 属性を命令 (Directive) として Google は扱い、必ず従ってきました（nofollow リンクが評価されている状況があるという分析もあるけれど、公式見解では nofollow リンクはランキング要因から除外されることになっている）。 今後

[レベル: 中級] ネイティブ Lazy-load を簡単に実装する WordPress 用のプラグインを Google が公開しました。 ネイティブ Lazy-load は JavaScript のライブラリを利用することなく loading 属性を追加するだけで、画像と iframe の遅延読み込みを可能にします。 1 か月前にリリースされた Chrome 76 でサポートされました。 設定不要、インストールするだけで WP で Lazy-load Native Lazyload プラグインの使い方は非常にシンプルです。 インストールして有効にするだけです。 設定項目はありません。 有効にすると、img タグと iframe タグに loading=”lazy” 属性をプラグインが自動的に追加します。 現状では、loading 属性をサポートするブラウザは Chrome 76（以上）だ

[レベル: 上級] Google Chrome 76 がネイティブ lazy-load をサポートするようになりました。 JavaScript のライブラリを利用することなく、ブラウザの標準機能として画像の遅延読み込みが可能になります。 ネイティブ lazy-load は開発版 Chrome (Canary) で試験運用されていました。 自動で遅延読み込み 次の動画は子猫の画像だけを掲載したデモ用ページをスクロールした様子です。 デベロッパーツールの Network パネルで見ると、スクロールに応じて画像が順に読み込まれているのがわかります。 この遅延読み込みは JavaScript で実装しているわけではなく、Chrome の標準機能として実装された lazy-load の機能で実現しています。 loading 属性でネイティブ lazy-load ネイティブ lazy-load を利用

[レベル: 上級] JavaScript を多用するウェブサイトの SEO のために必要な基本知識を解説するドキュメントを Google はデベロッパーサイトで公開しました。 ドキュメントに書かれている内容をざっくり紹介します。 Googlebot が JavaScript を処理するプロセス Googlebot による JavaScript の処理は次の 3 つのプロセスに大きく分かれます。 Crawling（クローリング） Rendering（レンダリング） Indexing（インデックシング） 2 番目のレンダリングが、静的な HTML ドキュメントにはないプロセスになります。 レンダリングが完了して初めて最終的なコンテンツがインデックシング プロセスに渡されます。 クローリングもレンダリングも、すぐ実行されるとは限りません。 “キュー” に保存され順番に処理されます（なので、レンダ

[レベル: 中級] 同じドメイン名のサイトから 3 件以上のページが検索結果に通常は同時に出現しないように検索の仕様を Google は変更しました。 検索結果の多様性を高めることが目的です。 同一ドメインのページは 2 件まで 同一ドメインのページが同時に複数表示されることがあります。 こちらは、僕のサイトからのページが 3 件並んだ（過去の）検索結果です。 今回の仕様変更により、基本的には 2 件までに制限がかかりました。 検索結果の多様性を高めることが狙い 同一サイトからの結果ばかりだと多様さが失われます。 違うサイトからのいろいろな情報を得たいというユーザーのフィードバックをもとに仕様を変更するに至ったとのことです。 検索結果のほとんどが同じサイトからというケースもありましたね。 例外あり どんなときでも絶対に 2 件までということでもありません。 特定のクエリにおいては、関連性が

オウンドメディアを長年運営すると、サイト内に貯まった記事ページからの内部リンク効果で、一覧ページやタグページの検索順位が上昇し、流入数が増え始める事があると思います。一定のサイト規模に達すると、記事ページと合わせて一覧ページの流入貢献度が高まります。 しかし、この「一覧ページ」は何も施さないで置くと、SEOに於いてネガティブとして捉えられる「重複コンテンツ」や「類似コンテンツ」と評価され、結果的に本来得ることが出来る流入を逃してしまう事もあります。 今回は、Googleに正しく認識される為の、ページ送り（ページネーション）に対するSEO施工をまとめてみたいと思います。 ページ送りに対するSEO施工【その１】「prev/next」とcanonicalを併用 複数に分割されているページ送りを、ページ個々でインデックス登録させる方式です。rel=next/prevを用いる事で、連続して繋がるペー

[レベル: 上級] メジャーな 2 大 JavaScript フレームワークである Angular と React、そしてこの 2 つには及ばないもののシェアを伸ばしてきている Vue.js を採用したウェブサイトは基本的に Google 検索においてうまく機能します。 SEO と相性が悪いフレームワークではありません。 ただしいくつか気をつける点もあります。 Angular/React/Vue は Google SEO に問題なし JavaScript SEO をテーマにした DeepCrawl との Q&A 動画チャットで、Google の Matin Splitt 氏が、メジャーな JavaScript フレームワークの Google 検索での利用について説明しました。 次の 3 つの JS フレームワークは Google の SEO に害を与えるようには作られていないと自身で詳しく

「SEOに効果がある」と過去にはされていたが、すでに時代遅れになってしまった「化石」の手法を5つ紹介する。古いやり方ではなく、今の時代に効果がでるやり方もあわせて紹介する。 なかなか認めにくいことだが、僕たちの多くは相変わらず時代遅れのSEO戦術を実践している。そうした戦術には、今なお大きなプラスの影響があると信じているからだ。 今回のホワイトボード・フライデーでは、ランドがそうした「化石」のような古代の手法を挙げ、現在それよりも効果的に機能する代替策を提示しながら、僕たちを優しく正しい方向に導いてくれる。あなたもコメント欄で、ぜひヒントやお気に入りの策をシェアしてほしい！ 化石戦術その1： Google広告のキーワードプランナーに頼ってキーワードを調査する最初に取り上げるのは、以前にも何度か話したことのある、Google広告（旧AdWords）のキーワードプランナーに基づくキーワード調査

ほかにも、次のようなSEOネタを今週もまとめてお届けする。あなたの仕事とスキルアップに役立ててほしい。 Search Consoleから緊急警告！ 検索結果のクリックが著しく減少しました3万ページを削除したら、検索ランキングへの影響はいかに？Fetch as Googleを使いすぎるとペナルティを受ける!?リンク否認ツールの間違った使い方： ×見覚えのないリンクを否認するサイトの長期的な成功は「ランキング要因の研究」ではなく「UX改善」が必要figcaptionタグはalt属性の代わりになる？URL検査ツールでPCサイトのスクリーンショットを取得できないグーグル、JSレンダリングの速度向上に取り組み中広告もLPもAMPにしたら、CTRが87%⬆・CVR76%⬆PWA+TWAでウェブサイトを完全アプリ化してGoogle Playに登録も狙い目のSEOは画像検索。2人のGoogle社員がアドバ

「見出しタグは6種類あるけど、どれをどこで使えばいいの？」 「hタグにはSEO対策としての効果はどの程度なの？」 サイトを制作していると見出しタグを使わないことの方が珍しいでしょう。それほど頻繁に使う「hタグ」ですが、その種類は6種類もあるため、初学者はそれぞれの使い方に迷ってしまいます。実際、それぞれのhタグの重要度をよく理解せず、デザイン上必要性だけを考え、「適当に使ってしまえ」となりがちではないでしょうか？ でも安心してください。今回は、このhタグについて説明します。特に以下の疑問に答えることを中心に説明していきます。これらはよくある疑問の最たるものです。 見出しタグは、h1-h6までそれぞれ使い方に違いがあるのか？ 見出しを設定することでSEO効果はあるのか？ hタグに使い方のルールがあるのか？ 今回の説明は、HTMLを学習し始めたばかりの初学者を想定して書いています。経験者にとっ

[レベル: 上級] WordPress サイトを AMP 対応する公式プラグインのバージョン 1.0 安定版が正式公開されました。 AMP プラグインのディレクトリからダウンロードできます。 統一されたデザインと機能を AMP で実現 v1.0 の大きな特徴の 1 つは統一されたデザインと機能を AMP ページで実現できる点です。 v1.0 以前のプラグインは、AMP ページのデザインが変わってしまい通常のモバイルページと比べるとかなり簡素に変換されてしまっていました。 しかし、v.1.0 では、AMP ページの外観および機能は通常のモバイルページとなんら変わりありません。 最新の AMP プラグインには 3 つのモードがあります。 Native Mode（ネイティブ モード）: サイトを完全に AMP 化する。すべてのページが AMP になり、通常の PC ページやモバイルページはなくな

[レベル: 上級] 検索エンジン向けの Lazyload の推奨を Google は先日公開しました。 この推奨に関して、2つの補足をこの記事では紹介します。 1. polyfill は重要 ドキュメントでは、IntersectionObserver API と polyfill の2つの技術を実装するように Google は指示しています。 「SEO」という観点では、polyfill が非常に重要です。 現在の WRS（Web Rendring Service、Google 検索のレンダリングシステム）は、Chrome 41 相当です。 IntersectionObserver API は Chrome 51 からサポートされました。 したがって、IntersectionObserver API で遅延読み込みさせる画像を Google は認識できません。 そこで、polyfill が重

[レベル: 中級] 昨日とおとといに続いて、今日も Chrome Dev Summit 2018 のセッションレポートをお届けします。 セッションのタイトルは “Speed Essentials: Key Techniques for Fast Websites” です。 昨日レポートしたセッションと同じようにモバイルウェブの高速化がテーマです。 しかし、こちらはより実践的な内容になっています。 パフォーマンス改善に非常に役立つテクニックが満載です。 パフォーマンス改善の優先対象は画像とJS、フォントの3つ モバイルウェブで 1 ページあたりデータ量が多いリソースは次の順番（HTTP Archive 調べ） 画像 (約 500 KB) JavaScript (約 380 KB) フォント (約 80 KB) この 3 つは Performance Budget（パフォーマンス バジェット）

[レベル: 上級] リッチリザルト テストツールで、コードスニペットによる検証が可能になります。 現状では、URL を入力し公開されているウェブページの検証だけに対応しています。 米サンフランシスコで先週開催された Chrome Dev Summit 2018 で、Google の Matin Splitt 氏がセッション中に紹介しました。 （※今日までブログ更新を休む予定でしたが、今日から再開します。） RRTT でコードによるリアルタイム検証 リッチリザルト テストツール（以下、RRTT）のトップページに「< >コード」のオプションが見えます。 現在の RRTT では、URL の入力ボックスだけが表示されています。 コードを貼り付けて検証できます。 コードスニペットによる検証は、構造化データ テストツールでは可能です。 しかしながら、その後継ツールとしてベータ版が公開されている RRT

[レベル: 上級] SEO と相性がいい Lazyload の実装を解説するドキュメントを Google はデベロッパー向けサイトで公開しました。 3つのアドバイス ドキュメントには3つの指針が書かれています。 1. viewport 内で見えるようにする viewport 内にあるコンテンツは、必ず Google にも見えるようにしておきます（viewport は簡単に言えば、スクリーンに表示される領域）。 つまり、重要なコンテンツが viewport に入ったときは確実に読み込ませます。 IntersectionObserver API と polyfill を実装するように Google は指示しています。 2. 無限スクロールでは paginated loading を使う 無限スクロールを採用している場合は、paginated loading を実装します。 paginated

[レベル: 上級] Lazy Load で読み込ませる画像を SEO に対応させる、言い換えれば、検索エンジンにインデックスさせるための方法として、次の2つを Google の John Mueller（ジョン・ミューラー）氏は Google I/O 2018 のセッションで推奨しました。 <noscript> タグ 構造化データ Lazy Load 画像は SEO に不向き Lazy Load で読み込ませる画像が SEO に不向きな理由は以前にも説明したことがありますが、もう一度簡単におさらいしておきます。 そんなの知ってるよという方はここは読み飛ばして構いません。 Lazy Load（レイジー ロード）とは、遅延読み込みのことです。 画像の表示によく使われます。 ページを表示した段階では画像を読み込ません。 スクロールして、ユーザーの見えるエリアに画像（が表示されるべき場所）が入った

[レベル: ALL] 2018年4月6日に開催された ISM Spin-off #4 – Google Search Night で Google の Gary Illyes（ゲイリー・イリェーシュ）氏が基調講演しました。 この記事では、その講演のなかからモバイル ファースト インデックス (以下、MFI) に関する部分をレポートします。 MFI の現状 MFI によくある誤解――インデックスは1つ。モバイル検索用とPC 検索用に別々のインデックスを作成するわけではない 準備ができたサイトから移行を始める。MFI 移行によって検索トラフィックが減らないようにする MFI 移行によって起こる目に見える変化: クロールの大部分がモバイル版 Googlebot になる モバイル版ページからコンテンツが取得される MFI に移行したかどうかを調べる方法: Search Console に届く通知

サイトのコンバージョンとリードを最適化することは、ビジネスにおける最高の投資のうちの一つだ。 滞りなく運営され、コンバージョンを生み出すウェブサイトは、いざと言うときビジネスの助けになる。 しかしこれは簡単ではない。コンバージョンは勝手に生じるわけではないのだ。 ありがたいことにGoogleは、サイトが欠いている、あるいは苦労していることに取り組む助けとなる無料のツールを用意している。 例えば、Googleのサーチコンソールがある。 これはGoogleの視点からあなたのサイトを診断するのにはもってこいのツールだ。 しかし使いかたは複雑で、サイトの改善アクションにつながるアドバイスが得られないこともある。 たくさんのデータと情報のセットがあるが、現状の分析データを改善するステップはない。 そして売上と収益を上げ続けるためには、サイトを改善し続けなければならない。 私は個人的にサイトを直すため