「メタ ディスクリプションがない」がモバイル ファースト インデックスの一般的なエラーに追加
[レベル: 初級] モバイル ファースト インデックスのベストプラクティスに掲載している一般的なエラー一覧に “Missing meta description”（メタ ディスクリプションがない）を Google は追加しました。 Missing meta description 一般的なエラーの一覧の、“Missing page title”（ページタイトルがない）の下に“Missing meta description”（メタ ディスクリプションがない）が加わっています。 提案される修正方法は title タグがないときと同じです。 問題の修正方法: タイトルとメタ ディスクリプションがモバイル版とパソコン版の両サイトで同等になるように設定します。 なお、この記事を公開した時点では、日本語ページにはまだ更新が入っていません。 「ページタイトルがない」の下は「モバイル向け URL がエラ
Googleモバイルファーストインデックスに移行していない残りの50%の移行は問題山積か？
[レベル: 初級] 検索結果に表示される半分以上のページがすでにモバイル ファースト インデックス（以下、MFI）に移行したことを、昨年暮れに Google は公表しました。 一方で、残りの半分の移行は一筋縄ではいかないだろうと、Google の John Mueller（ジョン・ミューラー）氏はコメントしたと Search Engine Roundtable が報じています。 モバイルページと PC ページの不一致 MFI に移行できない一番の理由は、モバイル向けページと PC 向けページが同等になっていないサイトが多いからのようです。 MFI に関する最新の公式ブログ記事から察するに、おそらく特に、次の情報の不一致が移行の妨げになっているのではないかと僕は疑います。 モバイル版ページの構造化データの欠落 モバイル版ページの画像代替テキストの欠落 モバイル向けページに構造化データがないと
今月導入される Google Speed Uptate は速ければ速いほど評価が上がるアルゴリズムだった
[レベル: 中級] 【UPDATE】 この記事は事実を正しく反映していないことが判明しました。 こちらの記事で説明しています。 ページの読み込み速度をモバイル検索のランキング要因として用いる “Speed Update”（スピード アップデート）を Google は今月導入する予定です。 Speed Update は、本当に遅いページだけが影響を受けるアルゴリズムだと思われていました。 しかしながら実際には、速ければ速いほど評価が上がるアルゴリズムになっているようです。 Speed Update では、読み込み速度が速いと段階的に評価が上がる Speed Update の導入を事前アナウンスした公式ブログの記事は次のように説明していました。 The “Speed Update,” as we’re calling it, will only affect pages that delive
Google、新しいSearch Consoleベータ版を全ユーザーに開放、検索パフォーマンスの期間は最大16か月に！
[レベル: 上級] 新しい Search Console のベータ版を全ユーザー対象に Google は公開しました。 これまでは Google が選んだ一部のユーザーだけが利用できていましたが、今後はすべてのユーザーに開放されます。 ベータ版の利用準備が整ったサイトには通知が届きます。 【UPDATE】 数週間かけて順次利用可能にしていくとのこと。 ベータ版にアクセスできるようになると、ナビゲーションメニューの上に「新しい Search Console を試す」というリンクが出現します。 新 SC で利用できる4つのツール 新しい Search Console に移植されているのは、現段階では次の4つのツールです。 検索パフォーマンス インデックス登録の対象範囲のステータス レポート AMP Job Postings 「検索パフォーマンス」は従来の検索アナリティクスの置き換わりです。 機
AMP Start、レスポンシブウェブデザインのAMPサイトを簡単に構築できるテンプレートを公開
[レベル: 中級] AMP プロジェクトは、AMP HTML で構成したウェブサイトを簡単に作成するためのテンプレートの提供を始めました。 AMP Start という名称のサイトで公開しています。 まずは2種類のテンプレートを配布 AMP Start で公開されているテンプレートを使えば、AMP に対応したサイトをゼロから構築する必要はありません。 テンプレートはデザイン的に洗練されており、たいていのサイトに必要な要素を備えています。 現在公開されているテンプレートは、次の2種類です。 記事用 ブログ用 記事もブログも大差ないように思いますが、ナビゲーションメニューやソーシャルボタンなどの要素に多少の違いがあります。 “COMING SOON”とあるので、もう1種類のテンプレートが近々公開されると思われます。 RWD + AMP HTML どちらのテンプレートも、レスポンシブ ウェブ デザ
Google、モバイルファーストインデックスの導入予定を正式発表。スマホ向けページを検索の評価対象に。SEOへの影響は？
[レベル: 中級] Googleは、Mobile First Index（モバイル ファースト インデックス）の導入を正式にアナウンスしました。 Mobile-first Indexing モバイル ファースト インデックスに向けて モバイル ファースト インデックスでは、PC向けページではなく、モバイル向けページの評価に主に基づいてランキングが決定されます。 Gary Illyes（ゲイリー・イリェーシュ）氏が米ラスベガスで10月に開催されたPubCon Las Vegas 2016で発表していたGoogle検索の仕様変更です。 正式な実施時期はまだ決まっていません。 今後数か月にわたり小規模な実験を行ったうえでの判断になるとのことです。 評価対象がPC向けページからモバイル向けページへ 詳細は公式アナウウンスを読んでいただくとして、概要としてはモバイル ファースト インデックス（以下、
HTMLのサイトマップはSEOのためなら今は必要なし
[レベル: 初級] SEOを目的とするなら、サイト内の1ページとして作成したHTML形式のサイトマップは現在は不要です。 効率よくクロールさせたいのであればXMLサイトマップを使います。 HTML sitemaps are fine, especially if they work for your site & users. Most sites don’t need them for SEO nowadays (we can crawl to every page normally and get support from an XML sitemap), so I wouldn’t go out of my way to create them. 特に、サイトやユーザーにとって役立つのならHTMLのサイトマップを利用するのはいいことだ。だがほとんどのサイトはSEOのためにはHTM
「スマホ対応」アルゴリズム更新の疑問にGoogle社員が答えた
[レベル: 初・中・上級] サイトがモバイルフレンドリーかどうか（モバイル対応しているかどうか）をランキング要素として使用することを先週Googleは発表しました。 4月21日から開始の予定です。 この記事では、このアルゴリズム変更に関連した疑問についての回答を紹介します。 Googleジョン・ミューラーがオフィスアワーで回答 発表の当日に、GoogleのJohn Mueller（ジョン・ミューラー）氏が英語版のオフィスアワーをGoogle+で開催しました。 当然のごとく、モバイルフレンドリーアルゴリズムの質問が終始たくさん出てきます。 僕たちが知りたいことも多く含まれています。 参加者から出てきた質問とそれに対するミューラー氏による回答をピックアップしてまとめました。 あなたのモバイル対応の参考にしてください。 モバイルフレンドリー アルゴリズム Q&A Q: サイトがモバイル対応してい
Google、「スマホ対応」をランキング要因に利用することを決定。4/21から導入。
[レベル: 初・中・上級] Googleは、スマホ対応しているかどうかをモバイル検索のランキング要因として使用することを発表しました。 4月21日からの導入を予定しています。 またApp Indexingに対応したアプリコンテンツもランキング要因として利用するようにしました。 こちらは今日（現地時間の2月26日）から導入されています。 モバイルフレンドリーが単なるラベル表示からランキング要因に 昨年11月に、そのページがスマートフォンに対応しているときに、「Mobile-friendly」（モバイル フレンドリー）というラベルをGoogleはモバイル検索結果に表示するようにしました。 日本には、翌月の12月に導入されました。 「スマホ対応」というラベルが付きます。 導入時点では、「スマホ対応」ラベルは単純に表示だけの仕様でした。 スマホ対応しているかどうかはランキング要因にはなっていません
入力フォームの「必須」「任意」のラベルは両方付けないとコンバージョン率が下がる
[レベル: 初〜中級] 入力フォームのフィールドには、入力が「必須」なのかまたは「任意」なのかのラベルを両方付けることが推奨されます。 どちらか片方だけだと入力途中の離脱の原因になります。 ECサイトのユーザービリティ調査と最適化を専門に扱っているBaymard Instituteが詳しく解説しています。 15の大手ECサイトのユーザビリティ調査と18の主要なモバイルサイトのユーザビリティ調査、そして自社による最新の大規模なアイトラッキングテストによって実証することができました。 この記事では、その解説の要点をまとめて紹介します。 片方だけの「必須」「任意」ラベルの問題点 入力が「必須」か「任意」かをどちらか片方のラベルだけで示すことにはさまざまな問題点があります。 必須か任意かを示さないのはいちばんよくない そのフィールドの入力が必須か任意かを示さないのはいちばんよくないスタイルです。
ブログの完全HTTPS化を完了、HTTPからHTTPSへの移行プロセスを共有
[対象: 上級] 気付いている人もいるかと思いますが、このブログ全体をHTTPSにしました。 この記事では、備忘録を兼ねて、完全HTTPSへの移行を検討しているサイトの参考になるように僕が実行してきたプロセスをまとめます。 実行した主な作業は次のとおりです。 サーバー証明書の取得 HTTPSへのリダイレクト 内部リンクの修正 各種ツール・パーツのHTTPS動作確認 すべてのコンテンツがHTTPSでダウンロードされているかを確認 WordPressの設定変更 rel=”canonical”の更新 ウェブマスターツールへの登録 サイトマップの更新 ソーシャルシェアの引き継ぎ HSTSの設定 外部リンクの更新 高速化 順に説明します。 1. サーバー証明書の取得 サーバー証明書をまず取得します。 手順は利用しているサーバー会社によって変わってきます。 詳しくはお使いのサーバー会社のヘルプを参照し
Googleウェブスパムチーム隊長、マット・カッツが否定する5つのSEO都市伝説
＃今日のエントリはツリっぽいタイトルでｗ 著名な人が発言した、壁に頭を打ち付けたくなるような間違ったSEO情報の例を5つ教えてほしい Googleのウェブスパム対策チームのリーダー、Matt Cutts(マット・カッツ)氏がウェブマスター向けQ&Aビデオで上の質問に回答しました。 「壁に頭を打ち付けたくなるような」という気の利いた一言が笑えますが、真面目に答えています。 1. 悪評リンクはランキングを上げる ⇒ × 顧客をひどく扱ってサイトに対する不平や不満など悪評を集めると、そのリンクは自動的に（評価対象として）カウントされる。 これは危険な考えだ。 顧客をぞんざいに扱えば扱うほどリンクを獲得しGoogleでランキングが上がることになってしまう。 確実に誤った理解と言える。 著名なレビューサイトであったとしても、リンクにnofollowが付いていたらリンクグラフから除外し、リンク先ページ
index.html「あり・なし」のURL正規化 – 301リダイレクト応用編
“www.example.com/“と”www.example.com/index.html“、人間のユーザーにとっては同じページでも、サーチエンジンにとっては、まったく別のページです。 （余談ですが、example.com,example.net,example.orgは、例を出すときに使用するために予約されたドメインです。例えのドメインを示すときには、これらを使いましょう） 異なるページ（＝異なるURL）ということは、被リンクもそれぞれ別のページへ向けられたものとして処理され、合算されるわけではありません。 たとえ、実際にはまったく同一のページへ張られていてもです。 SEO塾の石崎さんによれば、Yahoo!ではindex.htmlがある場合と、ない場合（スラッシュで終わる場合）では、インデックスに問題が生じるケースがあるとのことです。 Yahoo!検索でindex.html表示、スラッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
