リンク無効化ツールのQ&A
先日、サイトへの不自然なリンクを否認する新しいツールの提供を開始した、とGoogleの公式アナウンスがありました。⇒Googleリンク無効化ツール
このGoogleリンクの否認ツールによくありそうな13個の疑問についてマッツカッツ氏が回答している記事はこちら です。
非常に便利なツールですが、誤った使い方だけはしないようにとアナウンスしています。要は、リンクの削除などやるべきことはきちんとやって、ツールの仕組みを100%理解して、そのうえでの最終手段として使いましょうということです。
応援クリックにご協力ください!
↓↓↓↓↓
8月と9月に行った検索品質改善をGoogleが公表!!
8月と9月に行った検索品質改善をGoogleが公表しました。公表された検索品質改善は65個(8月:43個、9月:25個)です。
以下がGoogleが公表した改善内容です。
8月分↓
#82862
[プロジェクト・コードネーム: Page Quality]
より質の高いコンテンツを信頼度の高いソースから見つけられるようになった。
#84010
[プロジェクト・コードネーム: Page Quality]
パンダ・アップデートのデータを更新した。
(鈴木補足: これ
です。)
#83689
[プロジェクト・コードネーム: Page Quality]
より質の高いコンテンツを信頼度の高いソースから見つけられるようになった。
(鈴木補足: 2つ上の#82862と同じ説明です。)
LTS
[プロジェクト・コードネーム: Other Ranking Components]
場所を含むクエリに対してどのページが関連性があるかを決定するためのランキングシステムを改良した。
#82279
[プロジェクト・コードネーム: Other Ranking Components]
もっとも関連性の高い結果を可能な限り素早く返すためにクエリによっては、検索結果の表示件数を減らした。
(鈴木補足: このこと
でしょう。)
#84586
[プロジェクト・コードネーム: Other Ranking Components]
場所を示すキーワードを含むクエリに対して順位を決定する方法を改善した。
#83709
[プロジェクト・コードネーム: Other Ranking Components]
ランキング付けにおいて使われているリンクの評価に関係する小さなバグを修正した。
#83135
[プロジェクト・コードネーム: Query Understanding]
キーワードの近接度のスコアリングを改善した。
Imadex
[プロジェクト・コードネーム: Freshness]
古くなったコンテンツの処理方法を更新し、ドキュメントの公開日(or 更新日)に基いて微調整する機能を採用した。
#83105
[プロジェクト・コードネーム: Snippets]
サイトリンクを生成するデータを更新した。
#83442
[プロジェクト・コードネーム: Snippets]
検索結果のページタイトルを置き換えるとしたら、そのタイトルがそのページに実際にどのくらい関連性があるかを決定するために使用しているシグナルを改善した。
(鈴木補足、titleタグ書き換え
関連と思われます。)
#83670
[プロジェクト・コードネーム: Snippets]
comments(コメント)やlogo(ロゴ)のような一般的な言葉が検索結果のタイトルに出てこないようにした。
#82407
[プロジェクト・コードネーム: Other Search Features]
robots.txtでブロックされているページはクロールできないからスニペットを作ることがでいない。代わりにその理由を説明するようにした。
(鈴木補足: このこと
です。)
#83197
[プロジェクト・コードネーム: Autocomplete]
オートコンプリートでの予測の生成方法を変更した。
essence
[プロジェクト・コードネーム: Autocomplete]
オートコンプリートでエンティティ
の予測を導入した。文字列だけではなく、そのものごとの実態に対しても予測するようになった。検索の曖昧さをなくす手助けをするために、明確にさせるテキストがドロップダウン内に現れる。
#84259
[プロジェクト・コードネーム: Autocomplete]
オートコンプリートでの繰り返しを減らすために現実世界のエンティティの表示を調整した。この変更により、クエリにすべて含まれているときにはエンティティの名前(ダッシュの右に表示される)を表示しなくなった。
(鈴木補足: 何のことを言っているのか分かりません。)
TSSPC
[プロジェクト・コードネーム: Spelling]
ロングテールのオートコンプリート予測の関連性を高めるためのスペリングアルゴリズムにこの変更は利用される。
#83777
[プロジェクト・コードネーム: Synonyms]
もともとの検索キーワードが適切な検索結果を返すときは確証の低い同義語に頼らないようにした。
#83484
[プロジェクト・コードネーム: Refinements]
特に、同じ名前の人物がたくさんいるときに、正しい人物の情報を探すためにユーザーが検索をやり直すことを手助けする。
#83818
[プロジェクト・コードネーム: Answers]
映画の上映時間の表示を改良した。
#83819
[プロジェクト・コードネーム: Answers]
MLB(メジャーリーグ ベースボール)検索の表示を改良した。
#83820
[プロジェクト・コードネーム: Answers]
ファイナンス検索の表示を改良した。
#83659
[プロジェクト・コードネーム: Answers]
ローカルタイムを検索する機能の表示を改良した。
#83821
[プロジェクト・コードネーム: Answers]
単位換算機能を表示するための自然言語の検出を改善した。
#84083
[プロジェクト・コードネーム: Answers]
映画の上映時間の表示を改良した。
gresshoppe
[プロジェクト・コードネーム: Answers]
目的地がなくてもフライト検索の結果を表示するようにした。
#84068
[プロジェクト・コードネーム: Answers]
通貨換算機能の表示を改良した。
#83459
[プロジェクト・コードネーム: Alternative Search Methods]
音声検索における、新しい証券取引に関する回答方式のサポートを追加した。
#83384
[プロジェクト・コードネーム: Universal Search]
トルコ語での車のルート案内を改善した。
#83613
[プロジェクト・コードネーム: Universal Search]
ユーザーが明らかにビデオを探している意図が分かるときは、モバイル検索ではより適切な大きさのビデオのサムネイルを表示するようになった。
Maru
[プロジェクト・コードネーム: SafeSearch]
アダルトコンテンツを探していないクエリに対して、ビデオ検索でのアダルトビデオの取り扱いを改善した。
Palace
[プロジェクト・コードネーム: SafeSearch]
セーフサーチが強に設定されているときに表示されるアダルトコンテンツの数を減らした。
#82872
[プロジェクト・コードネーム: SafeSearch]
「強」のセーフサーチではあまり関係のない結果を表示しない。この機能はこれまで英語だけだったがインターナショナルで導入した。
Sea
[プロジェクト・コードネーム: SafeSearch]
セーフサーチが強に設置されているときにアダルトコンテンツが表示されるのを防ぐのに役立つ。
#83443
[プロジェクト・コードネーム: Knowledge Graph]
Knowledge Graphにリストとコレクションのパーツを追加した。
#83012
[プロジェクト・コードネーム: Knowledge Graph]
米国以外の英語を使用する国にもKnowledge Graphを展開した。
Knowledge Graph Carousel
[プロジェクト・コードネーム: Knowledge Graph]
Knowledge Graphのカルーセル機能を英語ではグローバルに展開した。
(鈴木補足: この検索結果の上に出ている一覧表示
のことです)
#84063
[プロジェクト・コードネーム: User Context]
通貨と計算に焦点を絞って、計算機機能のための自然言語の理解を改善した。
nearby
[プロジェクト・コードネーム: User Context]
より関連性があるローカル結果を見つけるために使うシステムの正確性とカバー範囲を改善した。これによりユーザーがいる場所に関連する結果をより正しく識別し適切にランキング付けできるようになった。
#83377
[プロジェクト・コードネーム: User Context]
より関連性の高いローカル結果を返すようになった。
#82546
[プロジェクト・コードネーム: Indexing]
システムの効率性を改善するためにバックエンドでのビデオのインデックスを改良した。
以下の2つはすでに公式アナウンスが別途出ています。
DMCA アップデート
DMCAによる著作権侵害サイトが検索結果の上位に出ないようにした。
(詳しくはこちらを
ご覧ください。)
音声検索の利用国拡大
音声検索を利用できる言語に13ヶ国語が新たに追加された。
(詳しくは公式アナウンス(英語)
をご覧ください。)
9月分↓
Dot
[プロジェクト・コードネーム: Autocomplete]
中国語と日本語、韓国語でカーソルの位置を認識しての予測を向上させた。たとえば「restaurants」(レストラン)を検索した後に「Italian resutaurants:」(イタリアン レストラン)を検索しようと思って検索ボックスの先頭に「I」を入力すると、カーソル認識によって「Irestaurants」ではなく「Italian」を候補として提示してくれる。
(鈴木補足: 英語での例なので実際にはこのとおりではありませんが、「レストラン」の先頭にカーソルを当てて「い」を入力すると「いレストラン」の候補ではなく「池袋レストラン」や「伊勢丹 新宿 レストラン」のように確かにあり得る検索候補を提示します。)
#84288
[プロジェクト・コードネーム: Autocomplete]
韓国語において、より最新のオートコンプリート候補を表示するようにした。
espd
[プロジェクト・コードネーム: Autocomplete]
この変更により、ユーザーがいる国により関連性の高いエンティティをオートコンプリートで提供できるようになった。
#82876
[プロジェクト・コードネーム: Autocomplete]
オートコンプリートの候補の最後の単語が同じときの予測を更新した。
#80435
[プロジェクト・コードネーム: Autocomplete]
Googleアカウントにログインしているユーザーのウェブ履歴に基くオートコンプリートの提案をこの変更により改善した。
trafficmaps
[プロジェクト・コードネーム: Universal Search]
“traffic from A to B”(AからBへの交通)や”traffic between A and B.”(AとBの間の交通)のようなクエリで交通マップを表示するようにした。
#83406
[プロジェクト・コードネーム: Query Understanding]
明らかに画像を探している、場所を探している、ビデオを探しているなど意図がはっきりしているクエリの理解力を向上させることでユニバーサル検索結果を改善した。
#84394
[プロジェクト・コードネーム: Page Quality]
より質の高いコンテンツを信頼度の高いソースから見つけられるようになった。
#83761
[プロジェクト・コードネーム: Freshness]
クエリに対して関連性のあるページが同じドメインに2つ以上あった場合、もっとも新しいコンテンツを返すようにした。
#83901
[プロジェクト・コードネーム: Synonyms]
ユーザーの検索意図に関連性がある結果をもっと頻繁に返せるように検索キーワードの同義語の使用を改善した。
#84652
[プロジェクト・コードネーム: Snippets]
HTMLに変換したときにPDF(とその他のHTML以外のドキュメント)のタイトルを生成する。これらの自動生成タイトルはたいていは良いものだが他のシグナルも見ることによってより適切なタイトルをこの変更で付けられるようになった。
#84211
[プロジェクト・コードネーム: Snippets]
より適切なスニペットのタイトルを表示できるようになった。
#84460
[プロジェクト・コードネーム: Snippets]
ページのなかで重要なフレーズをより適切に識別するのに役立つ変更。
#83391
[プロジェクト・コードネーム: Answers]
症状検索
を国際対応し改善した。
#83304
[プロジェクト・コードネーム: Knowledge Graph]
右パネルにトピックのサマリーをいつ表示すべきかを決めるシグナルを更新した。
#81360
[プロジェクト・コードネーム: Translation and Internationalization]
適用可能なところでは、一般的なホームページではなくユーザーの地域に即したURLを表示するようにした。たとえばスイスのユーザーにはblogspot.comの代わりにblogspot.chを見せる。
#81999
[プロジェクト・コードネーム: Translation and Internationalization]
(ウェブマスターが書いていなくても)特定の地域や言語に関連が高いドキュメントを自動的に理解するためのコードを改造した。
Cobra
[プロジェクト・コードネーム: SafeSearch]
アダルトコンテンツをより適切に検出するためのアルゴリズムを改良した。
#937372
[プロジェクト・コードネーム: Other Search Features]
検索結果ページのサイドバーにある「Translated foreign pages」(翻訳して検索)のリンクから翻訳検索ツールが利用可能になった。加えて、英語でない検索に対して英語のドキュメントからの方がより適切な結果を返せるときは検索結果ページの下に翻訳ツールを使うように提案するメッセージを表示するようにした。この変更により提案を表示するときの関連性が向上した。
以下の3つは公式アナウンスが別途すでに出ています。
Structured Data Testing Tool
「リッチスニペット テストツール」が「Structured Data Testing Tool」(構造化データ テストツール)としてリニューアル。
詳しくはこちらの解説記事
で。
Google Insights For SearchがGoogle トレンドに統合
Google Insights For SearchがGoogleトレンドと統合した。
詳しくはこちらの解説記事
で。
タブレットからのフライト検索
タブレット端末からのフライト検索が可能になった。
詳しくはこちらの解説記事(英語
)で。
以上が8・9月でGoiogleにて更新された検索品質改善項目になります。
詳細については下記記事元を御覧ください。
Google、8月と9月に行った検索品質改善を公表。目立った更新や変更はなし。
パンダ・ペンギンの影響を受けたかどうかチェックするツール
自分の運営しているサイトがパンダアップデートやペンギンアップデートに引っかかってしまったのか、そうでないのか、気になるところですよね。
今回はパンダアップデートやペンギンアップデートに引っかかったかどうかを調べるツールがあるのでご紹介します。
それは、“Panguin ”(パンギン?)という名前のツールです。Googleアナリティクスのデータと連携させるもののようです。
Web担当者にとって有益なツールとなるかもしれないですね。
詳細はこちらの記事にあるのでご覧ください。
パンダ&ペンギン・アップデートにやられたかどうかを調査するツール | 海外SEO情報ブログ
応援クリックにご協力ください!
↓↓↓↓↓
301リダイレクトで、不自然リンクのペナルティも一緒に連れて行くのか
不自然なリンクに対するGoogleからの警告を受け取った場合は、順位を下げる手動措置が取られているときはもちろんのことリンク無効化だけに留まっているとき でもできる限りすべてを外すことが望まれます。
しかし問題となっているリンクをどうしても取り除けないときがあります。
そんなときに、301リダイレクト を使うのはどうだろうかと思い付く人がいるはずです。
別のドメインに301リダイレクトしてしまえば、不自然リンク警告の対象から逃れることができるかもしれません。
ここで問題になるのが不自然リンクのペナルティも301リダイレクトが一緒に受け渡すかどうかです。
301リダイレクトは、不自然リンクのペナルティも一緒に連れて行くのでしょうか?
結論を言うと、連れて行きます。
先週参加したGoogle+でのハングアウトでGoogleのJohn Mueller(ジョン・ミューラー)氏に答えてもらいました。
その時の回答がこちら↓↓
不自然リンクの警告を受け取ったドメインを新しいドメインに301リダイレクトたら当然その要因も転送する。301リダイレクトで警告から逃れることはできないだろうし状態は保たれたままだろう。
警告を受け取ったら可能な限り取り除くことを勧める。どうしても撤去できないなら別のページを使うために新しいドメインに変えたほうがいい場合もある。でもそのときでも転送設定したらペナルティも転送するだろう。
もっとも、301リダイレクトで逃げることができる可能性が万が一あったとしても、Googleの人が「逃げられる」と口にするはずはありませんね。
とはいえ、「301リダイレクトはペナルティも引きずる」とGoogleの人が発言したのを直接的にも間接的にも聞いたのは僕にとってこれが初めてです。
不自然リンクに限らず受けたペナルティは根本的な要因を解決しなければならないと言えます。
301リダイレクトで逃げることはできません。
仮にできたとしてもいっときの“脱走”に留まりそうです。
参考元はこちら
↓↓↓
パンダアップデート対策
2012年7月18日パンダアップデートが日本語にもついに導入されました。パンダアップデートとは、コンテンツの質を重視し、質の低いコンテンツを検索結果から除外し、逆に質の高いコンテンツを上位表示させることを狙いとしたアルゴリズムです。
このパンダアップデートの影響を受け、涙目になった方も少なくないでしょう。今回はそんなパンダアップデートに対する対策を紹介している記事がありましたので、ご紹介します。
以下本文です。
今回は改めてパンダアップデートの対応について簡単にポイントをまとめておきます。
なお…欧米で最初にパンダアップデートが投入されたのは2011年2月。それから約18カ月もの「猶予」があったのです。私個人的には、特にオーガニック検索のトラフィックを重視している担当者の方には「もう対応済みです」と言ってほしいわけです。このアナウンスを見て慌てるようなSEO担当者は、危機管理意識が低すぎます。
eコマースサイトとパンダアップデート
通販サイト一般に言えるパンダアップデートのポイントを簡単に。課題は、取扱商品点数が多い通販サイトにおける、商品説明文の作成。
- メーカー公式説明文をそのまま使用しないこと:取引先やパートナーから提供された商品説明文をそのままウェブページに張りつけることは基本的に推奨されません。同じ商品を扱う他通販サイトも同じものを流用すれば、ネット上には取扱サイト数だけのコピーコンテンツが流通することになるからです。
- オリジナルな商品説明文を作成する:従って、自分のサイトで利用する商品説明文はできるだけ、独自作成をします。ただし、商品点数が多ければ、個々に説明文を作成することは現実的ではないでしょう。それならば、Amazon.com などのように、重点取扱商品だけでもオリジナルで役立つコンテンツを作成しましょう。
- ユニークで役立つコンテンツを:メーカー公式サイトには掲載されていない特定のスペック情報を、消費者が大変興味を持っている場合があります。その商品を購入する時に、商品だけでは説明しきれない情報が望まれることがあります。自分が扱っている商品を購入する側の立場にたって考えた時、何の情報を掲載すべきか考えてみましょう。消費者が何を期待しているかわからなければ、Q&AサイトやTwitterw、商品レビューサイトで自分の扱う商品に消費者がどんな質問や感想を述べているかを調査すると良いでしょう
- 海外の通販サイトはどう対応した?:中堅~大手の通販サイトは、商品説明についてのコンテンツを外部のライターに発注する動きを見せています。あるいは、特定商品の専門通販サイトの場合は(もともとその商品自体が大好きという運営者も多いため)時間を割いて説明文を自ら作成する、あるいはそういう商品が好きなブロガーに商品説明分文を作成するための基礎情報の収集を依頼している事例もあります。
- ユーザーレビューをコンテンツとして取り入れる:自身のウェブサイトに価値あるユニークなコンテンツを追加するアイデアとして、ユーザーレビューの掲載はビジネス的にも技術的にも優れた解決方法です。ユーザーレビューを提示することで購入検討中のユーザーの意思決定を手助けできるのはもちろん、そのレビュー(クチコミ)情報が他サイトにはない、価値あるコンテンツとしてページに追加・蓄積されていくことで、そのページ自体の有用性とオリジナリティを高めます。レビュー情報自体は今後のスマホ検索とGoogle+ Local (いわゆるSoLoMo)においても重要性を増していきますので、その観点からも対応して損はありません。
旅行・不動産・求人サイトとパンダアップデート
旅行・不動産・求人サイトなど、1つ1つの情報と同じものが他サイトにも掲載されていることが通例であるようなサイトにおいてのパンダアップデートのポイントを簡単に。如何に無駄なページを削除、クロールさせないかという点。
- 不要なページを削除・隔離する:SEOのためだけに"水増し"されたページや、ユーザーに利用されていない目次ページ、情報があまりに乏しいウェブページは削除したり別(サブ)ドメインに隔離するなどの対応を検討しましょう。SEOのために水増しされたページとは、サイト内検索が1度でも実行された検索クエリのページを自動生成したり、タタグクラウドにより無数のインデックス(タグ)ページが作成されているようなケースを指します。
- 「1ページ化」する:あるアイテムについて総合的な情報を提供しているページにおいて、その情報の役割や機能ごとにページを適度に分割していることはよくあります。たとえば、不動産情報における「物件写真」「レビュー」「地図」の分割や、商品比較サイトにおける「商品スペック」「価格情報」「レビュー」「取扱店舗」「写真」といった分割です。以前はこうしたページ分割はSEO的な事情からも推奨されることがありましたが、今日の(欧米の)トレンドは真逆、1ページにまとめる方向に動いています。
- インデックスさせるべきページの制御:ここで挙げた業種は、ユーザーが様々な条件・希望から目当てのものを探し出せるように、非常に充実した検索機能やカテゴリ分類を提供しています。しかしながら、それ故に(検索エンジンに対し)不必要に大量のページを見せてしまうこともあります。最近の海外サイトの傾向として、あえて"クロールできない"範囲を決めてサイト改修を行っている事例が出てきています。
シンジケーションビジネスとパンダアップデート
情報配信先という提携サイト(シンジケーション)の規模の拡大により価値が高まるようなサイトにおけるパンダアップデートのポイント。一般論として、これに属するサイトは本質的にはGoogleが評価したくない体裁を持っていますので、その点は認識しましょう。
- プレスリリース配信サイト:欧米の検索ランキング状況を見ると、プレスリリース配信系のサイトは芳しい結果となっていません。ビジネス的に配信先サイトの数だけ同一のプレスリリースが掲載される、つまりオリジナリティのない重複コンテンツを増やす結果をもたらすためです。また、プレスリリース配信系サイトは「重複コンテンツの寄せ集め」でもあるため、パンダ・アップデートの影響を受けやすい側面もあります。
- 比較系サイト:価格比較系サイトは、ユーザーレビューを持たない、すなわち何らかのオリジナルコンテンツを持たないサイトはパンダ・アップデートの影響を受ける可能性があります。コミュニティに活気がある = ユーザレビューが集まる、ユーザーの意見交換が行われている = ようなサイトは、それ自体がオリジナルで有益なコンテンツであるため、リスクは小さくなります。
- ディレクトリサイト:提携サイト数が多いディレクトリほど、パンダ・アップデートの影響を見るべきです。Yahoo! 以後に登場した、検索サイトとしてのディレクトリではなく、SEOのためにあるディレクトリサイトであることも、パンダ・アップデートによる悪影響のリスクを高めます。他のサイトからリンク集として数多くの紹介を受けているような、実質的な"ディレクトリ"としての価値を提供できているなら問題ありませんが、SEOのためのリンク発生源としてのディレクトリは、コンテンツをどうすべきか考えるべきです。※ 本件は、"ディレクトリ運営者サイドが認識すべき課題"を述べています。当該ディレクトリサイトへの(リンク)掲載が、パンダ・アップデートに係る何らかのリスクをもたらすものではございませんので、誤解なきようお願いします。
メディア(新聞社、ニュース系サイト)とパンダアップデート
ニュースサイト。ここは記事/(関連)リンク/広告の比率配分を見ましょう。
- 記事(主コンテンツ)/広告、関連リンクの割合:記事本文が薄っぺらい、短い、ほとんど詳細を伝えていないのに比して、バナー広告や他記事へのリンクが面積でページの大部分を占有しているようなケースは注意が必要です。そもそも、大部分がリンクや広告で占められているようなページをユーザーは望んでいません。
- 主コンテンツの割合(絶対文字量):米国内のパンダアップデートの影響を見ると、日本でいう「アメブロの(芸能人ブログなど)によくありがちなスタイルのページ」は、検索順位が下落しているケースが確認されています。アメブロ的な、というのは、写真数枚+無駄に改行が入っていて1文 1文は短い、総文章量もさほどないようなページが多数存在するようなサイトです。※ イメージしやすいようにアメブロを例に挙げていますが、決してアメブロのサイトが危ないという意味ではございません
記事元はこちら
↓↓↓
Googleパンダアップデート 傾向と対策 通販、求人、旅行、不動産 など::SEM R (#SEMR)応援クリックにご協力ください!
↓↓↓↓↓