Chrome 81に追加された便利な機能――リンク先ページの特定の場所に移動しハイライト表示
[レベル: 上級] Chrome 81 の安定版を Google はリリースしました。 Chrome 81 に追加された新機能の 1 つに、リンク先の特定の場所に直接スクロールし指定したテキストをハイライト表示する機能があります。 #:~:text= で移動&ハイライト Chrome 80 で実装したと Google はアナウンスしていましたが、実際に利用できるようになったのは Chrome 81 です。 ページの URL に #:~:text=○○○ を追加します。 ○○○ は、リンクをクリックしたユーザーをダイレクトに連れていきたい場所のテキストです。 たとえば、次のような URL としてリンクします。 https://webmaster-ja.googleblog.com/2020/04/how-to-pause-your-business-online-in.html#:~:tex
ページのダウンロード時間が1000ミリ秒を超えると、Googlebotがクロールに制限をかける可能性あり
[レベル: 上級] Googlebot がページをクロールするときにかかるダウンロード時間が 1,000 ミリ秒を超えると、クロールに支障をきたすかもしれません。 一応の目安として、100 〜 500 ミリ秒以内を考慮しておくとよさそうです。 ページのダウンロード時間は 100 〜 500 ミリ秒が理想、1,000 ミリ秒は遅すぎ （旧）Search Console のクロールの統計情報レポートでは、ページのダウンロード時間の情報を確認することができます。 ページのダウンロード時間は、Googlebot がリソースを純粋にリクエストするのにかかった時間を示すデータです。 PageSpeed Insights のようにユーザーが使うブラウザの表示にかかる時間ではありません。 リソースは、HTML のほか画像や CSS、JavaScript、PDF なども含みます。 ダウンロード時間の目安に関
AMPストーリーv1.0が公開。すべての開発者が申請不要で利用可能に。
[レベル: 上級] AMP Stories (AMP ストーリー) の v1.0 が公開され、すべての開発者が利用できるようになりました。 これまでは、申請してホワイトリストに登録してもらう必要がありました。 通常の検索での AMP ストーリー AMP ストーリーは、本をパラパラとめくるようにして物語風に一連の情報を閲覧できる AMP の機能です。 文字ではなく、画像や動画をふんだんに使ったビジュアルさに特徴があります。 AMP ストーリーは、試験用の Google 検索でしか見ることができませんでしたが、今は通常の検索で見ることができます。 こちらは Washington Post（ワシントン・ポスト）の AMP ストーリーです（“Washington Post” でモバイル検索すると、AMP ストーリーのカルーセルが出てきます）。 AMP ストーリーのもう少し詳しい解説は、Web担当者
モバイルウェブが爆速に！ GoogleがAMP (Accelerated Mobile Pages) を立ち上げ
[レベル: 上級] Googleは、Accelerated Mobile Pages （アクセラレイティッド・モバイル・ページ）という、モバイル端末でのウェブページの表示を高速化するためのプロジェクトを公開しました。 略して、AMP（アンプ）と呼びます。 AMPで策定された仕様に従ってモバイルサイトを構成すると、モバイル検索結果からリンク先ページがまさに“一瞬”で表示されます。 AMPをデモで体験 AMPを使ったページがどのようにモバイル検索から表示されるのかを見てみましょう。 Inside Searchの公式アナウンスに動画があります。 まずこれを見て、何となくでいいので雰囲気をつかんでください。 ただ、見てもどんなだか十分にはわかりませんでしたよね。 実際に試したほうが理解できます。 AMPを体験できるサンプルのリンクもアナウンスに出ていますが、日本からでは機能しないので少し細工を加え
個人ブロガーなら今すぐ設定したい、著者情報(Authorship)が遂に日本のGoogleでも導入開始
[対象: 上級] Google日本 (google.co.jp)で著者情報の表示の導入が始まったようです。 この記事を書いている時点で公式発表がないのでテストの可能性は否定できませんが、ブラウザを変えてもCookieを削除してもGoogleアカウントのログイン・ログオフを切り替えても先週後半から続けて確認できるので高い確率での本採用の気配です。 海外SEO情報ブログのGoogleの検索結果に表示された僕の著者情報です。 「著者」ではなく「作成者」になってますね。 Google+のサークルに入れられている人数は他の国と同様に付いています。 こちらは僕が寄稿しているWeb担当者Forumの連載コーナーのページに対して表示されている著者情報です。 また仕様が少し変わって同一著者によるページが検索結果のなかに複数ある場合は最初のページにだけ写真が付くようになったようです（Google.comでも確
Googleは不自然リンクをどうやって検知しているのか？ 警告は無視してOKか？
[対象: 全員] 有料リンクや自作自演リンクのようにランキングを不正に操作する目的で作られた不自然なリンクに対する警告を国内外を問わずGoogleは送り始めています。 つい最近は英語圏で、1億本以上もの人工リンクがインデックスから削除されたとも言われています。 もっとも今までは水面下で不自然リンクを検知していたのを透明化を図ってウェブマスターに通知するようにしただけというのがGoogleの言い分です。 ところで、何を判断材料にして不正に作成されたリンクであることをGoogleは検出しているのでしょうか？ iACQUIREブログは、自分たちが集めたデータから警告を受けその後大きく順位を下げたサイトに次のような特徴が見られると説明しています。 最適化され過ぎているアンカーテキストの数。ほとんどの場合は競争の激しい単一キーワード。 ネットワーク化されたことを示すような明らかなしるしがある複数の外
ウェブマスターツール Fetch as Google の「URLをインデックスに送信」で再クロールをリクエスト
[レベル：中級] URLのクロールをリクエストする機能がGoogleウェブマスターツールに加わりました。 「Fetch as Googlebot」の実行後に「インデックスに送信」という操作が可能になります。 「インデックスに送信」することでGoogleに速やかなクローリングを要求することができます。 通常は1日以内にクロールされます。 ただしクローリングを保証するものではありません。 あくまでもクローリングのリクエストです。 インデックスの送信には2種類あります。 URL URLとすべてのリンクページ 「URL」はFetch as Googlebotで取得したURLだけのクローリングをリクエストします。 「URLとすべてのリンクページ」はFetch as Googlebotで取得したURLに加えて、そのページからリンクしているページも合わせてクローリングをリクエストします。 リクエストの数
GoogleウェブマスターツールとGoogle Analyticsを関連付けする設定
GoogleウェブマスターツールとGoogle Analyticsを関連付けて、GoogleウェブマスターツールからGoogle Analyticsに直接アクセスできるようになりました。 【公式アナウンス】 Linking Google Analytics to Webmaster Tools 以下の手順で関連付けできます。 1. Googleウェブマスターツール管理画面のホームで、関連付けしたい登録サイトの[管理]をクリックして[Google Analytics プロファイル]を選択します。 2. Google Analyticsで管理しているプロファイル一覧が出てくるので該当するプロファイルを選択します（Google Analyticsを開設していないときはここからアカウント作成も可能）。 3. そうすると[サイトへのリンク]セクションで「Google Analytics からの参照元
【公式アナウンス】Google、スパムコンテンツの検出アルゴリズムを強化
GoogleのMatt Cutts(マット・カッツ)氏は、オンページのスパム的なコンテンツを検出する仕組みを改良したことを米Googleの公式ブログでアナウンスしました。 “オンページ”のコンテンツというのは、単語や文など、ページに書かれているコンテンツのことです。 たとえば、自動ツールで生成した文章や自作自演のブログコメントなど、スパムにありがちな言葉が繰り返されている価値のないコンテンツです。 この技術の向上はページ単位での検出が可能になってます。 他のサイトをコピーしたりオリジナルコンテンツに乏しかったりするサイトに主に大きく影響を与えるアルゴリズム変更も今回の変更に含まれています。 またハッキングを受けたサイトを検出する能力も大幅に向上させました。 Matt Cutts氏によれば、Googleの検索結果に出てくる英語のスパムサイトは5年前の半分以下に減っており、英語以外の他の言語で
GoogleがPageRank以外に見ている要因は？
「メーデーアップデート」「バックリンクの集めすぎ」に続いて、今日もGoogle Matt Cutts（マット・カッツ）氏によるウェブマスター向けQ&Aビデオの紹介です。 お題は「PageRank以外にどんな指標がランキングに使われているのか」です。 Q: PageRankは200ある指標のうちの1つにしかすぎないと言われるけれど、もう一度はっきりさせてほしい。そして、ほかの200個にはどんな指標があるのか？ PageRankは200の指標の中でもより重要な要素 それでも200のなかの1つであることに変わりはない バックリンクだけに取りつかれるべきではい ほかにはたとえば次のような要素を見ている アンカーテキスト ページにあるコンテンツ ページのURL ページのタイトル 見出しがあるかないか 単語同士の近接度（離れているか隣にあるか） とてもたくさんあるけれど多くは一般的な考えから推測できる
Google Analyticsでランディングページごとのコンバージョン率を調べるとっても簡単な方法
今日はGoogle Analyticsで目標設定やeコマーストラッキングを有効にしているサイト管理者に便利なTIPSを紹介します。 ランディングページ（開始閲覧ページ）ごとのコンバージョンのデータやeコマーストラッキングのデータを調べる方法です。 「Google Analyticsの『コンバージョン』メニューで見ればいいんじゃない？」と思うかもしれませんが、「コンバージョン」ではランディングページでセグメント分けできないんです。 実は意外な場所からランディングページごとのコンバージョンデータを知ることができます。 「地図上のデータ表示」です。 ナビゲーションメニューから、「ユーザー」 ⇒ 「地図上のデータ表示」と進んで「ディメンション」で「開始閲覧ページ」を選択します。 するとあら不思議、目標セットやeコマースのタブでランディングページごとのデータが見れるではないですか。 ※注：擬似的にe
SEOに適したPDFファイルの設定方法
PDFドキュメントに含まれたリンクは被リンクとして評価されるという記事を先日エントリしました。 バックリンク元としてウェブページを検索結果に表示させるのにPDFドキュメントは役に立つという内容でしたが、今日はPDFファイルそのものを検索結果に表示させるためのSEOを紹介します。 情報元は、seoconsultants.comの”SEO for PDFs – Optimizing PDF for Search“という記事になります。 ちなみにサイト管理者のEdward Lewis（エドワード・ルイス）氏は、WebmasterWorldではpageoneresultsというハンドルネームで活躍するベテランメンバーです。 ルイス氏は、大量のPDFを公開したクライアントのSEOコンサルティングで実行した方法を自身のブログ記事で公開しました。 細かな最適化まで解説していますが、ここでは重要点に絞って
内部要因をチェックするFirefoxアドオン ～ SenSEO
僕はサイト診断するとき、HTMLのソースを見ることから始めるパターンが多いです。 titleタグにキーワードが入っているか、meta descriptionタグはキャッチーであるか、meta keywordsタグはキーワードスタッフィングになっていないか、hタグには何が書かれているか、alt属性は適切に記述されいるかなどの内部要因を調べることが目的です。 ブラウザに付属のHTMLビューツールでソースを見るのですが（FirefoxやChromeは「CTRL」＋「U」のショートカットキーで簡単に出せます）、HTMLはプレーンなテキストだけで記述されるのでどこに何があるのか決して見やすいとは言えません。 こんな不便さを解消するツールを見つけたので紹介します。 SenSEOというFirefoxのアドオンです。 実行するとウィンドウの下部にSEOで重要になってくる内部要因の項目を自動的に取得して見や
iframeで表示したページはコンテンツの一部になるのか
iFrame(Inline Frame)を使うと、ウェブページの中に別のウェブページを表示できます。 下では、数分前に公開したページ（記事）をこの記事に埋め込んでいます。 こちらでは、別のサイトのページをこの記事に埋め込んでいます。 – iFrameで表示させたページのコンテンツは、iFrameを設置したページのコンテンツの一部としてみなされるののか？ – 例で挙げた2つのページのコンテンツは、この記事の一部として検索エンジンに認識されるのか？ このような質問がWebmasterWorldに投稿されました。 「iFrame内のページは独立したページとして扱われる」という回答が返されています。 つまり、コンテンツの一部にはなりません。 考えてみれば納得がいきます。 iFrameでコンテンツを自分のものにできるとしたら、他のサイトを表示させれば自分でコンテンツを作る必要がなくなってしまいます。
Google、ドメイン間の rel=”canonical” タグのサポート開始
Googleは、かねてからアナウンスしていたように、ドメインをまたぐrel=”canonical”タグのサポートを開始したことを公式アナウンスしました。 ※ rel=”canonical”タグって何？、何のために使うの？ という読者さんは、まずこちらからお読みください。 「重複コンテンツ・重複URL」のおさらい rel=”canonical”の正規化で、重複コンテンツを撃退 Google, Matt Cuttsによるrel=”canonical”タグの解説ビデオ もともと、rel=”canonical”タグは、同一ドメインまたはサブドメインの中だけで有効でした。 ”www.example.com”と”example.com”を正規化することはできましたが、 ”www.example.com”と”www.example123.com”を正規化することは、できなかったのです。 301リダイレク
「allinanchor:」コマンドでバックリンクペナルティを調査せよ
検索エンジンには、サイト管理者向けに特殊な検索構文（検索コマンド、検索オペレータ）が準備されています。 幅広く知られているのが、「link:」コマンドや「site:」コマンドですね。 使うべきなのに知られていない「allintitle:」なんていうコマンドもありました。 今日は、もう１つほとんど知られていないであろう、でも知っておくべき特殊検索構文を解説ます。 「allinanchor:」コマンドです。 “All in anchor”の意味で、”anchor”は「アンカーテキスト」を表します。 “allinanchor:キーワード“としてallinanchor:の後にキーワードを続けて入力して検索すると、そのキーワードをアンカーテキストとしてリンクが張られたページを、順に返します。 指定したアンカーテキストで、リンクを張っているページではなく、リンクが張られているページです。 allina
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
