[レベル: 中級] 動画だけを掲載するページの作成を推奨するガイドを、検索セントラル サイトの動画検索のベストプラクティスに Google は追加しました。 各動画の専用ページを作る この記事を公開している時点では、日本語ページはまだ更新されていません。 オリジナルの英語ページには次の段落が加わっています。 【UPDATE (2021/11/18)】 日本語ページにも更新が入りました。 To give your videos maximum exposure, create a dedicated page for each video, where the video is the most prominent subject on the page. Some features require that type of video page, including Key Moments

[レベル: 中級] WordPress 5.5 が、サイトマップ生成を標準機能として実装します。 プラグインを必要としません。 WordPress 本体の機能としてサイトマップを送信できます。 WP 製サイトマップの仕様 WordPress が標準機能として生成するサイトマップの仕様の概要は次のとおりです。 ファイル名: wp-sitemap.xml。WordPress をインストールしたディレクトリの直下に作られます。 登録可能 URL 件数: wp-sitemap.xml はサイトマップ インデックス ファイルです。最大で、50,000 件のサイトマップを含めることができます。サイトマップには、最大 2,000 件の URL を含めることができます。つまり最大で、1 億件の URL をサイトマップで送信できます。 robots.txt への追加: WordPress が自動生成する r

[レベル: 中級] Apple 製ブラウザの Safari がバージョン 14 で WebP を正式にサポートする予定です。 ついに Safari が WebP をサポート この記事を公開する時点の Safari の最新バージョンは 13 です。 次バージョンの 14 で WebP を標準機能としてサポートすると Apple は発表しました（正確にはベータ版でのサポートなので、正式版でサポートを見送る可能性がゼロではありませんが）。 WebP はスピードアップに最適な画像フォーマット WebP は Google が開発した画像フォーマットです。 JPEG や PNG に比べると、25 〜 35 % サイズが小さくなります。 画像は、JavaScript と並んでウェブページの表示速度を大きく左右する要素です。 最軽量の画像フォーマットである WebP を使えば、ページ表示の高速化に役立ちま

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

[レベル: 中級] 昨日とおとといに続いて、今日も 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（パフォーマンス バジェット）

[レベル: 中級] 【UPDATE】 この記事は事実を正しく反映していないことが判明しました。 こちらの記事で説明しています。 ページの読み込み速度をモバイル検索のランキング要因として用いる “Speed Update”（スピード アップデート）を Google は今月導入する予定です。 Speed Update は、本当に遅いページだけが影響を受けるアルゴリズムだと思われていました。 しかしながら実際には、速ければ速いほど評価が上がるアルゴリズムになっているようです。 Speed Update では、読み込み速度が速いと段階的に評価が上がる Speed Update の導入を事前アナウンスした公式ブログの記事は次のように説明していました。 The “Speed Update,” as we’re calling it, will only affect pages that delive

[レベル: 初〜中級] HTTPS ではなく HTTP で配信されているすべてのページに対して、通信が安全ではないことを通知するラベルを Chrome ブラウザで常に表示することを Google はアナウンスしました。 2018年7月にリリースされる Chrome 68 から実装する予定です。 全 HTTP ページに「保護されていない通信」ラベルを常時表示 HTTPS で配信していないページ、言い換えれば、HTTP のままで配信しているページには「保護されていない通信」のラベルが URL アドレス欄の先頭に表示されます。 たとえば、今でも HTTP で頑張っている東京都の公式ホームページは、この記事を書いている時点での最新版の Chrome（安定版）のバージョン 64 では、次のように表示されます。 と言っても、気になるところは何もありませんが。 これが、2018年7月にリリースされる C

[レベル: 上級] URL の末尾に付ける「/」（スラッシュ）の あり・なし の違いについて、Google の John Mueller（ジョン・ミューラー）氏が Google+ で説明しました。 結論を言うと、厳密に言えば技術的には異なるケースがありますが、正しく設定していれば通常は気にかける必要はありません。 この記事では、ミューラー氏の説明に僕からの補足を加えて解説します。 ドメイン名の最後に付けるスラッシュの有無は関係なし URL の最後につける「/」（スラッシュ）を、ミューラー氏にならって「トレイリング スラッシュ (Trailing Slash)」と呼ぶことにします。 おそらく「トレイリング スラッシュ」は明確に定義された技術用語ではなく、単純に「ディレクトリを示す場合の最後のスラッシュ」という意味の一般的な言葉ですが、SEO 俗語としてこの言葉を使います。 URL がドメイン

[レベル: 中級] レスポンシブ ウェブ デザインが選択すべき構成だ (Responsive Web Design is the way to go.) Google の Gary Illyes（ゲイリー・イリェーシュ）氏は、8月22日に開催された ISM Spin-off #2 で、このようにレスポンシブ ウェブ デザインをかつてないほどに推奨しました。 これまでは、「動的な配信」と「別々の URL」を含めた3つのモバイル構成のどれを選択しても構わないと言っていました。 しかし方針を変えて、レスポンシブ ウェブ デザイン1本に絞ったのです。 動的な配信と別々のURLが抱える問題 レスポンシブ ウェブ デザイン（以下、RWD）をゲイリーが強く推奨する最大の理由は、モバイル向けサイトと PC 向けサイトに差異がないことです。 見た目は違っていたとしても、同じ HTML を配信しているので、コ

[レベル: 初〜中級] 導入時期が依然として不透明なモバイル ファースト インデックスですが、導入に備えて確実に必要になる対処がいくつかあります。 そのうちの1つが alt 属性です。 モバイル向けページで alt 属性 をもし省略しているなら、今すぐにでも設定する必要があります。 ひとたびモバイル ファースト インデックスへの切り替えが実行されれば、検索結果、特に画像検索結果に悪い影響が出るかもしれません。 alt 属性を設定していなモバイルサイトが多い モバイルサイトでの alt 属性の状況について、Google の John Mueller（ジョン・ミューラー）氏は英語版のオフィスアワーで 次のように注意を促しました。 alt 属性に関してモバイルファーストインデックス チームから特によく聞くのは、alt 属性を画像に設定していないサイトがたくさんあるということだ。 alt 属性がな

In-house SEO Meetupが主催したGoogle MFI Nightで、Google社員にさまざまな疑問を質問するAMA with Google セッションを先週金曜日の記事でレポートしました。 日本語検索独自の品質評価アップデートがテーマでしたが、このイベントのメインテーマはモバイル ファースト インデックス (MFI) です。 当然AMAもMFI関連の質問が大部分を占めていました。 そこでこの記事では、Googleの金谷さんと長山さんを相手にしたMFIについてのQ&Aをレポートします。 MFIに関して2人のGoogle社員に何でも質問してみた [質問に答える長山さん] Q. 内部リンクの必要性 モバイル向けページではUXを考慮して、内部リンクをPC向けページよりも減らしている。 しかし、内部リンクが評価（ランキング）にも影響するなら、PC向けページと同じリンクをモバイル向け

[レベル: 初・中・上級] Googleは、ウェブマスター向けガイドラインを大幅に改定しました。 この記事では、主だった変更点を抽出して解説します。 認識しておきたい変更点が数多くあります。 新しいウェブマスター向けガイドラインの主だった変更点 セクション分け 以前は、次の3つのセクションに大きく分かれていました。 デザインとコンテンツに関するガイドライン 技術に関するガイドライン 品質に関するガイドライン 現在は、2つに分かれています。 一般的なガイドライン 品質に関するガイドライン 内容が減ったわけではなく、「デザインとコンテンツに関するガイドライン」と「技術に関するガイドライン」の2つが、「一般的なガイドライン」にまとめられた感じになっています。 「一般的なガイドライン」はさらに次の3つのサブセクションに分かれています。 Google がページを検出できるよう手助けする Google

Googleのスパム対策強化やブランドリンク重視そしてその他もろもろを先日参加したPubCon Las Vegas 2010のレポートとして、お伝えしてきました。 今日はレポートをもう1つ追加します。 ECサイトを運営するサイト管理者、特に「ECサイトではオリジナルのコンテンツを作るのは無理」と“あきらめモード”に逃げているネットショップの運営者（そう、あなたのことです！）の参考になるはずです。 （たった数秒といえど）言い訳を探すのに費やすムダな時間と思考回路をこれからリストアップするコンテンツ増強のアイディアを探すことに向けてください。ｗ モデルとなるのは、“狩猟犬アイテム”をオンラインで販売するGUN DOG SUPPLYというECサイトです。 このサイトが、当初の売上見込額の3倍の1,000万ドル（日本円で8億数千万円）を6年間で増やすことに成功した施策の1つがサイトのコンテンツを増

iFrame(Inline Frame)を使うと、ウェブページの中に別のウェブページを表示できます。 下では、数分前に公開したページ（記事）をこの記事に埋め込んでいます。 こちらでは、別のサイトのページをこの記事に埋め込んでいます。 – iFrameで表示させたページのコンテンツは、iFrameを設置したページのコンテンツの一部としてみなされるののか？ – 例で挙げた2つのページのコンテンツは、この記事の一部として検索エンジンに認識されるのか？ このような質問がWebmasterWorldに投稿されました。 「iFrame内のページは独立したページとして扱われる」という回答が返されています。 つまり、コンテンツの一部にはなりません。 考えてみれば納得がいきます。 iFrameでコンテンツを自分のものにできるとしたら、他のサイトを表示させれば自分でコンテンツを作る必要がなくなってしまいます。

今日は、もし自分の身に起こったとしたら、それはもう恐ろしいことになるであろう大事件をお話します。 僕が毎日チェックしている、”Search Engine Journal“というSEOブログがあります。 このブログのエディタのLoren Baker氏は、所有するGmailアカウントが無効化されてログインできなくなってしまったのです。 まったく身に覚えのないロックです。 途方にくれたLoren Baker氏は、困窮している状態を２度にわたってブログ記事にしました。 Google Has Disabled My GMail Account Open Letter to Google : Why Have You Taken Away my Google & GMail Accounts? Sphinnにも取り上げられました。 誰かに助けを求める、運がよければGoogleの社員に見てもらえるかもし

おなじみのGoogleのMatt Cutts（マット・カッツ）氏によるウェブマスター向けQ&Aビデオです。 Does Googlebot use inference when crawling? 今回の質問は、「Googleはクローリングするときに推測を使うのか」です。 たとえば、「site.com/article/page1.htm」と、「site.com/article/page2.htm」というページをインデックスしていた場合、連番のページもあるかもしれないと推理して「site.com/article/page3.htm」のクロールを試みるのかということです。 Matt Cutts氏によれば、Googleは確かにクロールに推測を用いるとのことです。 例として、パラメータ付きのURLを挙げています。 URLに複数のパラメータが付いたとき、そのパラメータを取り除いたURLにアクセスしてみ

というのです。 動的URL（Dynamic URL:ダイナミックURL）とは、ユーザーの要求に応じてその都度、生成されるURLです。 多くの場合「?」「&」「=」で区切られたパラメータ（引数）を伴います。 例１：http://code.google.com/p/google-checkout-php-sample-code/issues/detail?id=31 例２：http://www.google.com/support/webmasters/bin/answer.py?answer=40349&cbid=1beyxilfwhlqn&src=cb&lev=answer eコマースサイトやヘルプのように、データベースを利用したシステムで使われています。 一方、静的URL（Static URL：スタティックURL）は、誰がいつアクセスしても同じ、固定のURLです。 拡張子が、.htmや.