Aggregator

rel=canonical 属性に関する 5 つのよくある間違い

12 years 7ヶ月 ago
ウェブページで rel=canonical 属性 を指定することは、検索エンジンが 重複ページ の中からどのページをインデックスに登録するかを判断する上で重要な手がかりとなります。Yahoo!Bing、Google など複数の検索エンジンがこれに対応しています。rel=canonical 属性は、重複ページから、外部からのリンクなどのインデックス登録に関連する属性を集約するとともに、検索結果に表示させたい URL を指定します。しかし、このように便利な rel=canonical 属性ですが、設定する際には少し注意が必要です。

検索エンジンは、右側のソースコードにあるように「blue velvet(ブルー ベルベット)」カップケーキのページへの rel=canonical を優先的に表示させたいページとして認識するので、左側の「red velvet(レッド ベルベット)」カップケーキのページは検索結果には表示されないことになります。このように、rel=canonical の設定の方法により検索結果に大きな影響を与えます。

この記事では、rel=canonical を使用する上での推奨事項をご紹介します。:
  • 重複ページに含まれるコンテンツの大部分を含むページを canonical ページとしましょう。
    • ここで、コンテンツが自分の知らない言語で書かれていると仮定してみましょう。重複ページと canonical ページを左右に並べて見たときに、重複ページ内の文字の大部分が canonical ページにもあるでしょうか?その言語を理解できる人でなければ 2 つのページが類似していると判断できない場合、たとえば扱っている内容は類似しているけれども文章自体はさほど似ていないという場合は、canonical 指定をしても検索エンジンで無視される可能性があります。
  • rel=canonical のリンク先ページが確かに存在すること(エラーや ソフト 404 ページではないこと)を確認しましょう。 
  • rel=canonical のリンク先ページに noindex メタ タグがないことを確認しましょう。
  • 検索結果に表示させたいページが(重複 URL の方ではなく)rel=canonical で指定する URL であることを確認しましょう。
  • rel=canonical リンクをページの <head> タグ内または HTTP ヘッダー内に入れましょう。
  • rel=canonical を 1 つのページで 2 つ以上指定することは避けましょう。2 つ以上指定されていると、すべての rel=canonical が無視されます。

間違い 1: 複数ページにまたがるコンテンツの 1 ページ目を rel=canonical のリンク先とする

次のような複数ページにまたがる記事があるとします:
  • example.com/article?story=cupcake-news&page=1
  • example.com/article?story=cupcake-news&page=2
  • 以降同様
2 ページ目(またはそれ以降のページ)に 1 ページ目への rel=canonical リンクを指定するのは rel=canonical の正しい使用法ではありません。このようなページは重複ページではないからです。このように rel=canonical を使用すると、2 ページ目以降のコンテンツがまったくインデックスに登録されなくなってしまいます。

複数ページにまたがるコンテンツの 2 ページ目以降に 1 ページ目への rel=canonical リンクを指定すると、良いコンテンツ(例: 2 ページ目と 3 ページ目のコンテンツ)が登録されなくなってしまいます。

ページ指定されたコンテンツ の場合は、記事全体を 1 ページにまとめたページへの rel=canonical リンクを各分割ページに指定する か、ページ指定マークアップ rel="prev" と rel="next" を使用する ことをおすすめします。

全体表示ページへの rel=canonical リンクを各分割ページに設定

ページ指定されたコンテンツで全体表示ページへの rel=canonical リンクを指定しない場合、マークアップ rel=”prev” と rel=”next” を使用できます。

間違い 2: 絶対 URL のつもりで相対 URL を記述してしまう




<link> タグでは、他の多くの HTML タグと同様に、相対 URL と絶対 URL のどちらも使用できます。相対 URL とは、リンク元のページを基準とした「相対的な」パスのことです。たとえば、「images/cupcake.png」は、リンク元ページと同じディレクトリの中にあるサブディレクトリ「images」の中にある「cupcake.png」を指します。絶対 URL は、「http://」といったスキームを含めたパス全体を記述したものです。

<link rel=canonical href=“example.com/cupcake.html” />(「http://」が付いていないため相対 URL です)と指定すると、canonical URL としては、実際にはそのような意図でないことがほとんど確実であっても、「http://example.com/example.com/cupcake.html」と指定していると見なされてしまいます。このような場合、Google のアルゴリズムでは rel=canonical の指定が無視されることがあります。どのような意図でこのように rel=canonical を指定したとしても、結果的に目的を達成できないことになります。

間違い 3: rel=canonical を意図しない形で指定している、または 2 つ以上指定する

時々、意図した結果ではないと思われる rel=canonical の指定が見られることがあります。単純なタイプミスもごくまれにありますが、よくあるのはページ テンプレートの rel=canonical のリンク先を変更し忘れたまま使用しているケースです。この場合、サイト運営者のページにテンプレート作成者のサイトへの rel=canonical リンクが設定された状態になってしまいます。

ソースコードから、プラグインがどのように HTML に反映されたかをチェックし、意図しないrel=canonical リンクが無いことを確認します。

間違い 4: カテゴリ ページまたはランディング ページで特集記事への rel=canonical リンクを指定する

たとえば、デザートについてのサイトを運営していると想定します。そのサイトでは「pastry」(ペストリー:ケーキなどのお菓子類)や「gelato」(ジェラート)といったカテゴリ ページがあり、それらのカテゴリ ページでは日替わりで特集記事を紹介しています。たとえば、「pastry」のランディング ページで「red velvet cupcakes」(レッド ベルベット カップケーキ)を紹介するとします。「pastry」カテゴリ ページには「red velvet cupcake」のページと同じコンテンツがほとんど全部含まれているため、カテゴリ ページにその特定の特集記事への rel=canonical リンクを追加したとします。

仮にこの rel=canonical 指定が Google で認識されるとすると、「pastry」カテゴリ ページは検索結果に表示されないことになります。rel=canonical を指定することで、重複ページの代わりに canonical URL を検索結果に表示させたいという意思を示すことになるからです。これに対して、カテゴリ ページと特集記事のどちらも検索で見つかるようにしたい場合は、カテゴリ ページにそのページ自身をリンク先とした rel=canonical を指定するか、あるいは rel=canonical をまったく指定しないかのどちらかにするのがベストです。

canonical として指定すると、表示させたい URL を指定することになる点にも注意が必要です。カテゴリ ページまたはランディング ページで特集記事への rel=canonical リンクを指定することは避けましょう。

間違い 5: <body> タグ内に rel=canonical を入れる

rel=canonical 属性タグは、HTML ドキュメントの <head> タグ内にのみ記述します。さらに、HTML の構文解析時に問題が発生しないようにするには、<head> タグ内の上部に、rel=canonical を配置し、できるだけ早い段階で読み込まれるようにしましょう。rel=canonical の指定が <body> タグ内にあると Google では無視されます。

この間違いは簡単に修正できます。rel=canonical リンクが必ずページの <head> タグ内にあることと、できるだけ早い段階で出現することを念入りに確認します。

rel=canonical 指定は <head> タグ内では認識され、<body> タグ内では認識されません。

まとめ

有益な rel=canonical 指定を行うには:
  • 重複ページの本文コンテンツのほとんどが canonical ページにもあることを確認する。
  • rel=canonical の指定は1ページで1つとし、かつページの <head> タグ内で指定する。
  • rel=canonical のリンク先が、有効なコンテンツが含まれている URL であること(404 やソフト 404 ではないこと)を確かめる。
  • 特集記事が検索結果に表示させたい URL と見なされてしまうため、ランディング ページまたはカテゴリ ページで特集記事への rel=canonical リンクを指定することは避ける。
ご質問がありましたら ウェブマスター ヘルプフォーラム にお寄せください。

グーグル、カスタマージャーニー分析ツールを公開

12 years 7ヶ月 ago
グーグルが、オンラインでマーケティングチャネルに接触してから購買に至るまでのカスタマージャーニーについて、国別や商品カテゴリー別にベンチマークを確認できるツールを公開。日本のデータも確認できる。
------------------------------
The Customer Journey to Online Purchase
http://www.google.com/think/tools/customer-journey-to-online-purchase.html
------------------------------
noreply@blogger.com (Kenji)

ニュースリリースやブログ投稿に便利! 画像編集ができるフリーソフトまとめ

12 years 7ヶ月 ago

全国1千万の頼られ系男子のみなさんこんにちは。むらかみです。
突然ですがみなさんにはこんな経験はないでしょうか。

女「もしもし? ○○?」
俺「うん。久しぶりじゃんどうしたの?」
女「パソコン起動しなくなっちゃったんだけど」
俺「・・・(またそっち系のお話ですか)」

パソコンが起動しなくなった、こんなフリーソフトを探してるんだけど、ネットに繋がらない、なんかケータイがおかしいんだけど? etc…
という時にしか女性から電話がかかってこないこと。
身に覚えがある方は、だいたい便利系頼られ系男子です。
もちろん私はあります。

閑話休題。
最近、同僚の女性がミラーレス一眼カメラを買ったんですね。とある理由で。
その流れで、ニュースリリースやらブログやらFacebookに写真をアップしたいからイイカンジでフリーの画像編集ソフトを教えなさいよ。と言われ、トッププライオリティで調べてみました。

IrfanView – パパッと簡単編集におすすめ! -

tools_image_editor_01

言わずと知れた画像ビューワー兼簡易画像編集ソフト。
Web制作に関わっている方ですと利用している方は結構多いのではないでしょうか。
切り抜き、回転、反転、リサイズはもちろんのこと、シャープやぼかしなどのフィルター機能も備えており、パパッと編集したいときなどに超便利です。
また、PhotoshopのPSDファイルも表示できるので重宝します。

縮小専用。 – 大量画像の一括リサイズ処理におすすめ! -

tools_image_editor_02

その名の通り、画像を縮小させたらこれ以上簡単なソフトはないというほど簡単&シンプルな画像縮小専用ソフト。
画像をドラッグ&ドロップするだけでサクっと画像の縮小が出来るお手軽さが人気で、複数枚の画像を一気にドロップすればその全てを同じサイズに変更出来てしまうのが便利ポイントです。

GIMP – 複雑な画像編集におすすめ! -

tools_image_editor_03

バージョンアップを重ね続けて早17年。最近のバージョンはAdobe Photoshopに匹敵する機能を備える多機能画像編集ソフト。
前述の2つのソフトに比べると操作は難しいですが、レイヤーが使えたり複雑なフィルターも多数搭載していてレタッチからなにから全部こなせるすごいやつ。
さらにWindows/Mac/Linuxとほぼ全てのOSで使えるのも魅力のひとつです。

  • GIMP
    ※リンク先は英語になります。右上のナビゲーション内 Downloads からダウンロードできます。

 

駆け足で3つご紹介しました。
IrfanViewと縮小専用。は使い方の説明が必要ないくらい簡単シンプルなので、インストールだけでもしておくといざという時に役立つかと思います。
この他にもPictBearなど便利なソフトがありますが、今日はこのあたりで。
それでは。

むらかみ

AdWords 利用規約の重要な変更について

12 years 7ヶ月 ago
日本を含むアジア太平洋地域のすべての国と地域(中国、韓国、台湾、インドを除く)において、新しい利用規約が導入されます。

AdWords のご利用にあたっては、AdWords の利用規約に同意していただいております。この利用規約は、AdWords のポリシー、キャンセル、お支払い、係争処理、法的責任といった基本的項目について、Google と広告主様の間で共通認識を持つために重要です。

広告プラットフォームの進歩と世界展開が進むにつれて、利用規約に変更を加える必要が生じました。そこで、日本を含むアジア太平洋地域の広告主様(詳細)を対象に、新しい利用規約を導入することになりました。

変更点
第一の変更点は、新しい広告サービスに対応したことです。たとえば、状況に応じて第三者配信が利用できるようになったため、広告配信にまつわる係争の解決方法に関する規定が追加されています。

その他の変更点としては、Google のポリシーへのリンクが更新されたこと、世界全体で広告掲載に関する規約の一貫性が向上したことなどが挙げられます。

必要なお手続き
お客様には AdWords の新しい利用規約を確認し、45 日以内に同意していただく必要がございます。この期間内に同意されなかった場合は、同意していただくまで広告掲載が一時停止されますのでご注意ください。

新しい利用規約を確認するには、https://adwords.google.co.jp から AdWords アカウントにログインしてください。自動的に新しい利用規約に関するお知らせが表示されますので、内容をご確認のうえ同意してください。

ログイン時に新しい利用規約が表示されない場合
アカウントへのログイン時に新しい利用規約が表示されなくても、お客様の方ですぐに行っていただく作業はありません。利用規約の更新は順次行われているため、しばらくしてから更新される可能性があります。

また、同じアカウントへのアクセス権限をもつ別のユーザー(広告代理店や、共同管理者など)が既に利用規約に同意された可能性もあります。

詳細情報
より詳しい情報については、AdWords ヘルプセンターをご覧ください。是非新しい利用規約の全文を今一度ご確認の上、同意頂きますようお願いいたします。


noreply@blogger.com (Google Blog)

欧州ソーシャルマーケ費、今後5年で倍増

12 years 7ヶ月 ago
フォレスターリサーチによると、ヨーロッパにおけるソーシャルメディア向けマーケティング支出は、2012年は14億ユーロだった。2017年には32億ユーロになるという。
------------------------------
European social media marketing spending in good shape
http://blogs.forrester.com/anthony_mullen/13-04-29-european_social_media_marketing_spending_in_good_shape_upcoming_legislation_the_major_inhibitor

------------------------------
noreply@blogger.com (Kenji)

米国ネット広告費、2012年は366億ドル

12 years 7ヶ月 ago
IABによると、2012年のアメリカのインターネット広告費は前年比15%増の365億7,000万ドル。そのうち、モバイル広告費は前年比111%増の33億7,000万ドル。
------------------------------
Internet Ad Revenues Again Hit Record-Breaking Double-Digit Annual Growth, Reaching Nearly $37 Billion, a 15% Increase Over 2011's Landmark Numbers
http://www.iab.net/press_release/pr-041613
------------------------------
noreply@blogger.com (Kenji)

Marketers, Agencies Locked in a Data Tug of War を読み解く

12 years 7ヶ月 ago

ちょっと前の記事になってしまったが、3/25付けのアドエイジ誌掲載の「Marketers, Agencies Locked in a Data Tug of War」を読み解いてみる。

http://adage.com/article/agency-news/marketers-agencies-battle-owns-data/240518/

・明らかに、エージェンシーとクライアントで、データの所有権の争い(協議)がある。
 
・データは今や、マーケティング業界での、アツい「通貨」だ。

・クライアントの為に購入したサードパーティのデータに至るまで、エージェンシーのテクノロジー(プラットフォーム)の中に蓄積されてては、クライアントは使い勝手が悪い。

・データの所有権に関する、エージェンシーとクライアントとでの争いがある。

・クライアントも独自のインハウスプラットフォームを作るブームがある。

・Omnicomは、クライアント横断型のデータは作らない、クライアント個別のデータ蓄積に徹する、と言っている(オムニコムのAnnalect:DMPのDMP)「アイデアだが、連合制モデル、とでも言うべき
 みんなが使えるデータ形式になるのではないか」

・Turnは、「所有権問題、というのは、ちと古い」 「今後は、データがある事が前提での、アクセス権、の議論になるだろう」

・HTC曰く、「契約書を作る時は、エージェンシーとの契約ではなく、その先のベンダーと広告主との契約を、必ず結ぶパターン」にしている。

・DSP、DMPの裏で動く、マネーシャッフル(データシャッフル)を理解することが鍵。


など、非常に重要な話が議論されている。


さて、従来のアドテクノロジーに関しては、アメリカが最低でも2~3年先を行っていてくれたので、どういう方向に収斂するかが分かってから日本でのダイレクションを検討できた。しかしDMPに関しては、その差は1年ないんじゃないかと思う。その意味で日本のプレイヤーにもリスクが大きい。しかし、その分先行メリットはより大きくなっている。先行した者に追いつくのは至難の技だろう。それだけ、チューニング(学習)による改善効果が高い仕組みだと思う。

GooglebotのアクセスをIPアドレスで確認するときには注意が必要、DNSリバースルックアップを使う

12 years 7ヶ月 ago

サーバーにアクセスしてきたクローラが本当にGooglebotかどうかを確認したいときにはIPアドレスだけを基にして判断するべきではない。DNSのリバース ルックアップ(逆引き参照)を用いて、そのIPアドレスがGoogleが所有するものかどうかを併せてチェックする必要がある。

- GooglebotのアクセスをIPアドレスで確認するときには注意が必要、DNSリバースルックアップを使う -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM

【海外SEO】鈴木謙一

人気記事トップ10

人気記事ランキングをもっと見る