遂に来た！通信が安全ではないことを示す警告をすべての非HTTPSページにGoogle Chromeが常に表示。2018年7月リリースのバージョン68から
[レベル: 初〜中級] HTTPS ではなく HTTP で配信されているすべてのページに対して、通信が安全ではないことを通知するラベルを Chrome ブラウザで常に表示することを Google はアナウンスしました。 2018年7月にリリースされる Chrome 68 から実装する予定です。 全 HTTP ページに「保護されていない通信」ラベルを常時表示 HTTPS で配信していないページ、言い換えれば、HTTP のままで配信しているページには「保護されていない通信」のラベルが URL アドレス欄の先頭に表示されます。 たとえば、今でも HTTP で頑張っている東京都の公式ホームページは、この記事を書いている時点での最新版の Chrome（安定版）のバージョン 64 では、次のように表示されます。 と言っても、気になるところは何もありませんが。 これが、2018年7月にリリースされる C
Google アナリティクス、AMPキャッシュ計測の問題を解決。AMP Client ID APIのオプトインで正確なアクセス解析が可能に
[レベル: 上級] AMP キャッシュへのアクセスとオリジナルのページ（AMP含む）へのアクセスを同一認識できない問題を解決する手段を Google アナリティクスが提供しました。 AMP アクセス解析が抱えていた問題 Cookie を引き継ぐことができないため、同じユーザーであっても AMP ページに訪問したユーザーと通常のページ（非 AMPページ）に訪問したユーザーを異なるユーザーとして認識してしまう問題を、Google アナリティクスを含む AMP 対応しているすべてのアクセス解析ツールは抱えていました。 Google アナリティクスは、AMP ページ本体へのアクセスと通常ページ向けページのアクセスを同一視できるように5月に改善を加えました。 しかしながら、AMP キャッシュのアクセスは依然として異なるユーザーとして認識されたままでした。 ですが、AMP キャッシュへのアクセスであっ
amp-bindが一般公開、ECサイトでのAMP対応がいよいよ現実的に
[レベル: 上級] AMP プロジェクトは amp-bind を一般公開しました。 amp-bind は、“オリジントライアル”に参加したサイトで試験的に公開されていました。 しかし、すべてのサイトでもはや完全に機能します。 amp-bind でダイナミックな機能を実現 一般的に言って、AMP は、ニュース記事やブログ記事、レシピなど静的なコンテンツに向いています。 だれがいつ読んでも、閲覧中にどんな動作をしても、コンテンツは変化しません。 いつも同じです。 しかし、ユーザーのアクションに応じてコンテンツが変化する動的なページが現代のウェブではそこかしこに存在します。 EC サイトであれば、たとえば次のような動的な機能は当たり前です。 サイズや個数に応じた合計金額の変化 タップしたサムネイル画像に応じた拡大画像の切り替え 商品の絞り込みや並び替え サイト内検索 ところが、従来の AMP の
AMPのバリデーションや構造化データ、キャッシュなどを一括でチェックできるツール――AMPBench
[レベル: 上級] AMP化したモバイル検索の導入が日本でも迫っています。 AMP対応を進めているサイト管理者も多いのではないでしょうか。 AMP対応する際に役立つツールとして、AMPページの有効性を検証するための「AMP テスト ツール」をGoogleは先週公開しました。 この記事では、公式ツールではない、AMPページのさまざまな情報をチェックできるサードパーティ製のツール、「AMPBench（アンプベンチ）」を紹介します。 さらに多くの情報をチェックするAMPBench AMPBenchは、公式のAMPテストツールよりもさらにずっと多くの情報をチェックしてくれます。 AMP HTMLの有効性 amphtmlリンクタグおよびcanonicalの有無 Googlebotがクロール可能か AMP CDNにキャッシュされているか 構造化データが設定されいてるか etc. リストに挙げたのは一部
入力フォームの「必須」「任意」のラベルは両方付けないとコンバージョン率が下がる
[レベル: 初〜中級] 入力フォームのフィールドには、入力が「必須」なのかまたは「任意」なのかのラベルを両方付けることが推奨されます。 どちらか片方だけだと入力途中の離脱の原因になります。 ECサイトのユーザービリティ調査と最適化を専門に扱っているBaymard Instituteが詳しく解説しています。 15の大手ECサイトのユーザビリティ調査と18の主要なモバイルサイトのユーザビリティ調査、そして自社による最新の大規模なアイトラッキングテストによって実証することができました。 この記事では、その解説の要点をまとめて紹介します。 片方だけの「必須」「任意」ラベルの問題点 入力が「必須」か「任意」かをどちらか片方のラベルだけで示すことにはさまざまな問題点があります。 必須か任意かを示さないのはいちばんよくない そのフィールドの入力が必須か任意かを示さないのはいちばんよくないスタイルです。
schema.orgを使ったパンくずリストのマークアップ設定方法
[対象: 上級] schema.orgの仕様に従ったパンくずリストの設定方法をこの記事では解説します。 パンくずリストを示すための構造化マークアップを適切に記述していなかったばかりに間違ったパンくずリストがGoogleの検索結果に表示されてしまったというトラブル事例を先日紹介しました。 パンくずリストであることを検索エンジンに伝える構造化データにはいくつか種類がありますが、ここではschema.orgを使います。 公式サイトでのガイダンスはこちらになります。 では行ってみましょう。 下のようなパンくずリストだったとします。 TOP > イタリア料理 > パスタ > カルボナーラ HTMLのソースコードはもっともプレーンな状態だと下のようになります。 <a href="/">TOP</a> > <a href="/italian/">イタリア料理</a> > <a href="/italia
スマートフォン向けサイトにはレスポンシブ・ウェブデザインを推奨、Googleが公開したスマホサイトの最適化 at #SMX Advanced Seattle 2012
[対象: 中〜上級] SMX Advanced Seattle 2012 セッションレポート第2弾は、英GoogleのPierre Far（ピエール・ファー）氏による「スマートフォン向けサイトの最適化」です。 Far氏のプレゼンテーションは、直前にGoogle Webmaster Central Blogで公式アナウンスがあったスマートフォンサイト構築の推奨に関する記事とその詳細を説明しているドキュメントとほぼ同じ内容です。 Far氏のプレゼンと公開されたばかりのドキュメントを合わせて、Googleが推奨するスマートフォンサイトを構築する際の最適化についてレポートします。 スマートフォン向けサイトの最適化 3タイプの構成のスマートフォン向けサイトをGoogleはサポート レスポンシブ・ウェブデザイン (Responsive web design) — デスクトップとモバイルで同じURL・同
Googleからのお願い、「CSS・JavascriptをGooglebotがクロールするのをブロックしないで」
[対象: 初級] CSSファイルやJavascriptファイルへのGooglebotのクロールをrobots.txtでブロックしないようにしてほしいと、GoogleのMatt Cutts(マット・カッツ)氏が“公共メッセージ”を流しました。 もし、JavascriptやCSSにGooglebotがクロールするのをブロックしているとしたら、少しだけ時間を取ってその記述をrobots.txtから削除してほしい。 JavascriptやCSSをクロールさせてもらえればそのページでどんなことが起こっているかをより適切に理解できる。 帯域幅のようなリソースを浪費しないようにとブロックする人がたくさんいるけれど、Googlebotはかなり高性能なのでそういったものを速すぎるくらいにクロールしたりはしない。 ほかにもFlashがJavascriptを含んでいるのを知らなくてJavascriptをブロック
HTTPS(SSL)ページをインデックスさせない方法
住所や生年月日、クレジットカードなどの個人情報をインターネット経由で伝えることが当たり前のようになり、セキュアな通信はますます重要になってきています。 SSLというのは、”Secure Sockets Layer”の略でインターネット（TCP/IPネットワーク）でやりとりする情報を暗号化して送受信するプロトコル（通信規約）です。 ウェブサーバーとブラウザの通信をSSLの仕組みを使って暗号化するのが、HTTPSです。 SSLは、公開鍵やら秘密鍵やらデジタル証明書やらデジタル署名やらいろいろな技術を使い、理解するのに難易度が高い仕組みです。 といっても、今日の記事はSSLの解説ではありませんので、中身は知らなくてもぜんぜんOKです。ｗ ブログ読者から質問をいただきました。 「HTTPSページをインデックスさせないようにするには、どうすればいいのか？」という質問です。 この方は、eコマースサイト
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リダイレク
H1タグはH2タグの下に来てもOK！、ホントに？
おなじみ、GoogleのMatt Cutts（マット・カッツ）氏のウェブマスター向けのショートビデオです。 今回のテーマは、「H1タグがH2タグよりも下に記述されていたらクローリングに問題が起こるか」という質問です。 「大丈夫」だそうです。 ページが全部H1やH2タグだったら、さすがにマズイですが、H1タグがH2より下にあっても、きちんと解釈してくれます。 Webページの40%は、何らかの構文間違いを犯しているという統計もあります。 Googleは、有益な情報を集めるためにHTMLのミスを上手に処理できるように努力しているということです。 だからといって、H1タグをH2タグの下にもってきてもよいというわけではありません。 HTMLは正しく記述するに越したことはありません。 しかし、技術の進歩で、多少のHTMLの打ち間違いは、検索エンジンやブラウザがカバーしてくれるようになっています。 「H
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
