自分研究会

一日の振り返りと課題を探す

MFIについて説明する

http://www.sem-r.com/google-2010/20161109203539.html


■MFIについて説明する

1.エンティティ(実体)の理解

エンティティとは実体を意味する言葉。例えば企業のプレリリースがHTML版とPDF版の2種類あったとする。それぞれファイルは2つだが、フォーマットの違いだけなので情報としては、1つ。
内容を把握するために、2つのファイルに目を通す必要もない。


2.モバイル版とPC版も形式の違いである

この考え方を検索の世界に持ち込んだのが、Googleバイル検索。
PCとモバイルを異なるURLで提供されている場合に、この2つのページはバージョン違いで用意された同じ情報を持つページだ。と関係性を理解しながらデータベースに登録する方法をとった。
※バージョンの違いの関係性をGoogleに伝えるには、特定のアノテーションを対象に記述する必要がある


3.バージョン違いの関係で処理しておくと、検索も便利になる

2つのページの関係性を理解するとなぜいいのか?両者が同じコンテンツを有するなら、基本的に同じ検索クエリで検索結果にヒットする。
その時、検索ユーザーがPCなのが、モバイルなのかによってGoogleがとちらか適切な方を表示することができるようになる。

例えば、PC検索ユーザーにはPC版のURLのリンクを、モバイル検索ユーザーであればモバイル版のURLへリンクを自然に検索結果で表示することができる。


4.どちらのコンテンツをメインで表示させるのか?

今までは、PCが主流だったので多くのユーザーは最初にPC版のコンテンツを見てきた。
GoogleもPC版のコンテンツを「Primary」(メインコンテンツ)としてきた。
※モバイル版は「Secondary」(サブコンテンツ)


5.MFI(モバイルファーストインデックス)によりモバイル版がメインコンテンツに

2010年以降、急速にモバイルが普及してきて、いまやGoogle検索の過半数はモバイルから検索する時代に。この背景から多くのユーザーは最初にモバイル版を目にすることになる。
そこで、Googleも時代に合わせて、モバイルコンテンツを「Primary」とし評価していきます。
と発表した。


○具体的にどんな対策が必要なのか?


■レスポンシブWEBデザインの場合

レスポンシブデザインの場合は、モバイルファーストインデックス実施に当たって特にすることはない。自分のサイトがレスポンシブデザインに対応しているかどうかは、「モバイルフレンドリーテスト」にて確認することができる。


■PCとスマホに別々のURLを見せている場合

スマホ用のコンテンツを、PC用コンテンツとは別のURLで用意しているサイトは少しやるべきことがある。以下の二つだ

・PC版とスマホ版のページを、しっかりと「canonical」(正規化)する
・PC版とスマホ版で、どちらも同じコンテンツを用意する


canonical対応について
canonical対応ができていないと、例えばPC版ページについた被リンクがスマホページの順位評価に加味されなくなる。
一方で、正規化さえできていればPC版ページの被リンク評価や、その他SEO評価は問題なくスマホ版ページに引き継がれる。


▼同じコンテンツを用意する
「同じコンテンツを用意する」というのができていないと、今時点ではPC版ページでGoogleに評価されていても、数か月後にモバイルファーストインデックス化が行われたとき、PC版とは違うスマホ版ページのコンテンツで順位評価がされることになり、今よりも順位が下がってしまう可能性もある。

逆にこの2つの対応が完了していれば、別々のURLでモバイル対応しているサイトでもおおよそ問題は解決できる。


▼モバイル対応していない場合

もし、レスポンシブデザインにも未対応で、モバイル向けに別URLでのページ配信も行っておらず、モバイルユーザーのための他の手立て(動的配信/Dynamic Serving⇒ユーザーエージェントによって見せ方(HTML)を変える)も用いていない場合は、モバイルファーストインデックス化が行われるまでの数か月のうちに、何らかの方法でサイトのモバイル対応を進めることをオススメする。

 

■レスポンシブデザイン以外の方法でもOK

急にレスポンシブデザインにしろ、と言われても難しい人もいるはず。
ワードプレスなどのCMSを使っているのであれば割かし簡単にできる
自前で作ったホームページや自社制作の会社サイトの場合、多少なり付加がかかる。

その場合、サイトトップや主力商品ページなどの順位を上げたいページだけを、モバイル対応させるだけでも、やらないよりはまし。

 

■不完全なモバイルページが一番NG

いくらモバイルページを早く用意したからと言って、不完全なコンテンツを載せたモバイル版ページをとりあえず作ったり、マークアップの不完全なモバイルサイトを上げるのはだめ。
Googleの公式サイトにも、不完全なモバイル対応を行うよりも、内容のまともなPC版ページだけが存在する方がユーザーもしくは検索エンジンにとっても好ましい場合がある。と記載がある。

とりあえずで作るのではなく、しっかりと作りこむことが大切。

【スマホSEO】スマホ順位を上げるために抑えておくべき3つのこと

 

http://seolaboratory.jp/other/201505292300.php

①モバイル端末からブラウジングする際

1.インタースティシャル広告が表示される
インタースティシャル広告とは、メインコンテンツを閲覧する前に広告ページやアプリダウンロードを促すポップアップ広告のこと
2.再生できない動画やコンテンツがある
3.表示速度が遅い
4.トップページにリダイレクトされる


②今後、スマホ順位が下落するサイト

バイルフレンドリー対応していないサイト


③モバイルフレンドリーテストで、合格しても「スマホ対応」が表示されないケース

スマホ対応ラベル表示されない3つの原因

①リンク同士の間隔が狭すぎる
┗つまりボタン同士が近すぎる可能性があるということ
②文字サイズが小さすぎる
┗文字を大きくしましょう
③PCサイトからスマホサイトへのリダイレクト対応が不適切
┗PC向けサイトを訪れたスマホユーザーをスマホサイトへリダイレクトするのではなく、同じURLへリダイレクトさせていませんか?

http://www.aiship.jp/knowhow/archives/9757

Page Speed Insights(ページスピードインサイト)について

■Page Speed Insights(ページスピードインサイト)とは?

https://developers.google.com/speed/pagespeed/insights/?hl=ja&url=http%3A%2F%2Fmocom.tv%2F


■Page Speed Insightsとは?

Page Speed Insightsとは、webページの表示速度を計測するGoogle公式提供の無料SEOツール。
Page Speed Insightsは、「Googleスピードチェック」などともいわれている。


http://seolaboratory.jp/other/2016110149630.php#p03a


■Page Speed Insightsの改善方法

・ブラウザのキャッシュを活用する
・スクロールせずに見えるコンテンツのレンダリングをブロックしているjavascript/cssを排除する
・圧縮を有効にする
・画像を最適化する
css,HTML,javascriptを圧縮する
・サーバーの対応時間を短縮する

 

マイアミ・ケータさん

■期限を決めない目標は戯言

自分は何歳で結婚して、何歳までにその会社でどういう部署にいって、というのをリアルに描くことが大切。
なんとなく、「おれ、こんなことしたいんだよな」と思っていてもできるわけがない。
明確にやりたいことを決める。

そして大切なことは、「やるか・やらないか」この二つだけ。
どんな環境であれ、やるやつはやる。

自分の人生、1年後、2年後どうしていたいだろう。5年後はどうなっていたいだろうという目標と。
10年後、20年後、30年後、40年後、50年後というのは、描く必要がある。

 


■人のイメージは出会って10秒で決まる

■お金は人を喜ばせた対価

■やってて気持ちいことを振り返る

■人に何かを与えるという感覚を持つ

■次の日にやることは前日に決める

■できますよ!と言って帳尻を合わせる

 

■チャラさ

■ファミリー感

■信頼

■みんなで作る

■楽しい

 

http://logmi.jp/165830

レイヤ3 ARP

レイヤ3 ARP


■4つのアドレス・おさらいのおさらい


送信元のアドレスを取得する方法について。

送信元、自分のMACアドレスNICをとりつけた段階で分かる。
送信元IPアドレスは、管理者に教えてもらうアドレスを直接入力する静的と
DHCPにより自動で割り振られる動的。の二つの方法がある。

残る問題は、データの転送を行いたい相手のアドレスをどのように知るかという一点にかかっている。

 

宛先のMACアドレスを知る方法はARPというプロトコルを使用する。

 

■アドレス解決プロトコル

アープと読む。

アドレス解決プロトコルと日本語では訳される。
「宛先のMACアドレスが分からない」という状態を解決してくれるプロトコルという意味。


ARPは宛先のIPアドレスが決定した時点で実行される。
例えば、このサイト「Roads to Node」を見たいと思ったとする。
そうすると、ブラウザに「Roads to Node」のURLを入力する。

そうすると、DNSという機能が働いて、サイトが置いてあるサーバのIPアドレスを教えてもらえる。

そこで、「このIPアドレスのホスト、あなたのMACアドレスを教えて」と聞く。
これがARPだ。


ARPテーブル

まず、データ転送を希望するホストは、宛先のIPアドレスを取得する。
DNS


宛先IPアドレスが決定した時点で、宛先MACアドレスを知るためにARPテーブルを参照する。

ARPテーブルとは、IPアドレスMACアドレスの対応表のこと。

 

f:id:sakamotosakamo:20161113171514p:plain

「192.168.0.1のMACアドレスは00-40-26-f4-1a-02」です。という表がある。


ARPエントリタイプは?>

static(静的)とdynamic(動的)の二つがある。
dynamicはARPによって取得したIPアドレスMACアドレスの対応という意味。
staticは手動で対応を入力したという意味になる。


ARPテーブルに宛先IPと宛先MACの対応があれば、その時点でMACアドレスがわかる。
ARPテーブルがあれば、いちいちMACアドレスを聞く必要がない。

問題は、ARPテーブルに宛先IPと宛先MACの対応がない場合だ。
そのため、「このIPアドレスのホスト、あなたのMACアドレスを教えて」と聞きその結果をARPテーブルに載せることをする。
この「教えて」というのがARP要求だ。

 


ARP要求&ARP応答

このARPはIPと同じくレイヤ3のプロトコルだ。
このARPにのっとって送信されるARP要求だが、IPを使わない。

つまり、IPの代わりにARPでデータ転送を行う。
なので、IPパケットの代わりにARPパケットというちょっと特殊なパケットを使う。


特徴はARPパケット自体がデータという点。
上のレイヤのプロトコルを使わない。

つまり以下のような形で送るということ。



f:id:sakamotosakamo:20161113171554p:plain

ARPパケットの中身は以下のようになっている。

f:id:sakamotosakamo:20161113171613p:plain

 

下の4つを見てわかる通り、4つのアドレスすべてが入っている。

????

でも宛先のMACアドレスは分からないのでは?
まず、文章でで説明するとこのようになる。


▼宛先にデータを転送しようとして、宛先IPアドレスが分かったあと。

 
1.ARPテーブルを参照し、宛先IPアドレスに対応するMACアドレスがあるかどうかを調べる。
2.なければ、ARP要求をブロードキャスト送信する。
3.ARP要求を受け取っとホストは、ARPパケットの中の宛先IPアドレスと自分のIPアドレスを比較する。
 └一致しなければ無視
 └一致した場合、ARP対応を送信

4.ARP対応を受け取った(ARP要求を送った)ホストは、ARPテーブルにそのMACアドレスを追加する。
4つのアドレスがそろい、宛先へのデータ送信が可能になる。

 

 

f:id:sakamotosakamo:20161113171652p:plain

 

 

f:id:sakamotosakamo:20161113171700p:plain

 

 

f:id:sakamotosakamo:20161113171710p:plain

 

f:id:sakamotosakamo:20161113171948p:plain

 

 

f:id:sakamotosakamo:20161113172018p:plain

 

 

 

 

 

DHCPと同じように、ブロードキャストを使う。
誰に送ったらいいか分からないときは、ブロードキャストをよく使う。


ARP要求を受け取ったら、その送信元を自分のARPテーブルに追加しておく。
そうすることによって、ARPを出す回数をなるべく減らすようにしている。
ARPが多発するのは望ましくない。

 

ARPテーブルのエントリの問題

ARPが多発するのはなぜよくないのか?

それはARPがブロードキャストだから。
ブロードキャストはなにしろ、全員宛なので、ネットワークの帯域幅を多く消費する。


<でも、イーサネットは結局全員に届くのでは?別にブロードキャストでなくて、一人宛だとしても全員と同じになってしまわないか?>


確かにイーサネットだと全員に届く。
しかし、スイッチやブリッジなどのデバイスを使えば事情はことなる。
※スイッチやブリッジはフィルタリングして宛先のみに届く。

だが、ブロードキャストはスイッチやブリッジではフィルタリングできない。
なのでブロードキャストの多発はトラフィックに影響を及ぼしやすい。


ブロードキャストが多発しすぎると、ネットワーク全体が通信不能になってしまうことがある。
このような状態をブロードキャスト・ストームという。

 

では、そのARPの回数を減らす方法は?


答えは、ARPテーブルを事前に作っておくこと。

ARPテーブルを静的にエントリを作っておくのがARPの回数を減らす早道だ。
静的なエントリはずっと保持される。
そうすればARPは行われなくなる。


だが、実際ほとんどのデバイスでは、ARPテーブルを静的に作成することはできない。
なぜなら、ARPテーブルが間違っている時点で、送信は絶対に不可能になるからだ。


ARPテーブルが間違って記憶されると、IPアドレスMACアドレスが一致しないことになる。
イーサネットの仕組みを思い出してもらいたい。
自分のMACアドレスと一致しないフレームは破棄される。


なので、MACアドレスが違った時点でフレームを受け取ってもらえないことになる。
だからARPテーブルの動的なエントリは一定時間ごとにクリアされるように作られている。
IPアドレスMACアドレスの対応が間違うことのないように。


。。。。。でもそうなると、結局ARPは減らないよね?

結論、そうなってしまう。

 

 

<今日のポイント>


・宛先MACアドレスを知るにはARPを使用する
・ホストはIPアドレスMACアドレスの対応表であるARPテーブルをもつ
ARPテーブルは一定時間でクリアされる
ARPテーブルに宛先のエントリがない場合、ARPが実行される
ARP要求をブロードキャストする
ARP要求の宛先IPアドレス以外のホストはARP要求を破棄する
ARP要求の宛先IPアドレスのホストは、ARP対応を返す
ARP対応を受け取ったARP要求の送信ホストはARPテーブルにエントリを追加する

 

 

 

 

AMP(Accelerated Mobile Pages)化によるモバイルSEOまとめ

■AMPとは

AMPとは、Accelereted Mobile Pege の略で、モバイル端末のウェブページの表示を高速化するためのプロジェクトのこと。
今後は、AMP対応したモバイルページの作成が重要になる。
AMP対応すると、例えば、ツイートの中にAMP対応したページのリンクが含まれていた場合、そのウェブページが即座に表示される仕組みのこと。

 

従来のモバイルページよりもAMPページ倍速になり、データ量が8分の1に減ったという情報もある。

 

■AMP対応するための3つの方法

①AMP HTMLでページをマークアップ
AMP HTMLで使用が許されていないタグや属性を使用することができず、推奨されているものを使いマークアップすることが必要。

②構造化データを実装する
現状でサポートされているschema.org/NewsArticle と schema.org/BlogPosting でマークアップし、構造化データを実装する。

③正しくAMP化されてるかチェックする
chromeデベロッパツールでチェック
・構造化データテストツールでチェック
・search Console でチェック

ワードプレスの場合は、AMP用のプラグインを使う

 

http://seolaboratory.jp/other/2016021025666.php


http://masup.net/2015/10/fits-amp-html.shtml
AMPのマークアップについて

Googleペナルティのチェック確認・解除方法と原因まとめ

Googleペナルティとは

Google公式ウェブマスター向けガイドラインに違反してサイト構築を行った場合、に課せられるペナルティのこと。
Googleペナルティは、ホームページの検索順位に悪影響(順位下落、インデックス)をもたらし、お問い合わせ数、申し込み数などの売り上げにも影響を及ぼす。
Googleペナルティは、もっとも重いペナルティ「手動ペナルティ」、「自動ペナルティ」の大きく2種類に分けられる。


Googleペナルティのチェック方法

サーチコンソールで確認する(手動ペナルティ)

http://seolaboratory.jp/penalty

 

Googleペナルティの解除方法と流れ

悪質なリンクが原因だった場合。

①サーチコンソールに手動ペナルティの警告メッセージ「外部から不自然なリンク」が届いた

②サイトの検索順位が下落し、インデックス削除された

③外部からの不自然なリンクを精査し、ツールを使ってそのリンクを否認した

④再審査リクエストする
⇒手動ペナルティの原因を改善した後、Googleへ再審査リクエストする必要がある

⑤○○日後に再審査リクエストが承認され、(手動ペナルティ解除)、サーチコンソールにメッセージが届く。

⑥検索順位回復

 


Googleペナルティの種類

自動ペナルティの種類

・キーワードを詰め込む過剰なSEO
・同じようなコンテンツの過度な使いまわし(重複コンテンツのコピー)
・薄っぺらいコンテンツ


手動ペナルティの種類

・不自然な被リンク
・不自然な発リンク
・相互リンク
・低品質で価値のないコンテンツ