Googleモバイルファーストインデックスの有効通知が一斉に管理サイトへ

予定されていたGoogleのモバイルファーストインデックスですが、準備が整い移行可能となったサイト管理者宛に有効通知がいっせいに送られたようです。

モバイルファーストインデックス移行に向けてGoogle が正式に発表をしたのは2016年11月5日。

2016年11月5日 Google ウェブマスター向け公式ブログ: モバイル ファースト インデックスに向けて

そこから移行開始の正式な発表は2018年3月27日。

Google ウェブマスター向け公式ブログ: モバイル ファースト インデックスを開始します

Googleがモバイルファーストインデックスへの移行準備が整っていると思われるサイトから移行が始まるとのことでしたが、今回、その対象が一気に広まった感じでしょうか。

Mobile-first indexing モバイルファーストインデックス有効通知

Mobile-first indexing enabled for http://kazunoriiguchi.com/

http://kazunoriiguchi.com/ の所有者様

モバイル ファースト インデックスが有効になっているため、スマートフォン用 Googlebot のログでサイトのトラフィックが増加している可能性があります。また、モバイル版のコンテンツから Google 検索結果のスニペットが生成されるようになることもあります。

背景: モバイル ファースト インデックスは、インデックス登録とランキングの決定についてモバイル版のコンテンツを使用することで、ユーザー(主にモバイル ユーザー)が探している情報を見つけやすくするための仕様です。弊社のクロール、インデックス登録、ランキングのシステムは、これまでは PC 版のサイトのコンテンツを使用していたため、PC 版とモバイル版でコンテンツが異なる場合、モバイル検索に不都合が生じることがあります。弊社の分析によると、お客様のサイトのモバイル版と PC 版は類似しています。

詳細:

  • インデックス カバレッジについては、インデックス ステータス レポートをご利用ください。
  • インプレッション数、クリック数、サイトのデザインについては、検索パフォーマンス レポートをご利用ください。
  • ご不明な点がありましたら、ウェブマスター フォーラムにご投稿ください。その際は、メッセージ タイプ [WNC-20058194] である旨をお知らせください。または Google の一般公開イベント
    にお立ち寄りください。

すでに対応されているサイト管理者様はとくにすることは無いでしょうが、モバイル ファースト インデックス有効の通知があった時期は記録されていたほうが良いかも。
少数かとは思いますが対象のサービスがモバイルで閲覧されることに関係がないという方以外は、早急に対応をすることをおすすめします。

また、今後早急な対応をおすすめするのはなんといっても「https化」。
みなさん、httpsへの移行はおすみですか?

もしご心配のようでしたら、お気軽に弊社までご相談ください。

株式会社アリー allie – meet new scenery

G suiteで使用しているドメインでhetemlの特定のメールアドレスのみ、他社サーバーでメールを送受信する方法

ご存知のとおり、G suiteでは各アカウントごとにメールアドレスを割り振りアカウント管理されています。

企業内であれば企業のドメイン(@allie.site)が共通となり、各々のメインアドレスとそれ以外にエイリアスを作成しグループや個々のサブメールアドレスを使用します。

今回、社内外関わらず関係者で共通で利用する弊社ドメインのメールアドレスを作る必要になり、そのためだけに有償のアカウントを増やすものなんだなと思い、一般的な独自ドメインと同じくメールアドレスのみ作成し、それをみんなで使うことに。

独自ドメインであれば新しいメールアドレスを作るなんてわけないこと。
しかし、G suiteで使っている企業ドメインとなると、メールサーバーはすでに弊社で使用しているものではなくGoogle管轄。

どうしたものかと問い合わせてみたところ、こちらの意図をサクッと理解して丁寧な解説とともに回答をいただいたのだが、そこからが長かった…。

ちなみに今回の環境は以下。

ドメイン管理:
ムームードメイン

サーバー:
heteml

話は少しそれますが、いつもながらG suiteのカスタマー担当の方々の対応には本当に感謝。
丁寧かつ迅速に対応していただき、ほんとうに助かります。

弱小企業こそ、セキュリティ面含めG suite おすすめ。

話を戻しますが、カスタマーへ確認したところ、以下の回答。

適宜抜粋
※〜は個人的注釈

弊社サービスでご利用いただいているドメインで特定のメールアドレスに対してのメールのみ、他社サーバーでメールを受信なさりたい場合、一旦、弊社サーバーにてメールを受信し、弊社サーバーに存在しないメールアドレス宛のメールを他社メールサーバーに転送する運用が有効と存じます。

他社サーバーでメールを送受信したいメールにつきましては、G Suite内で作成頂く必要はございません。
※→ メールエイリアスのこと

以下にG Suiteでの手順をご案内いたします。手順は大きく分けて2つの内容になります。

  • 転送先のホスト(他社サーバー)を設定
  • デフォルトの転送設定

Sponsored Links

<転送先のホスト(サーバー)を設定>

下記のヘルプ記事にある「ドメインのメールルートを追加する」の設定を実施いただけますよう、お願いいたします。

Gmail の高度な配信設定(メールルートの追加) – G Suite 管理者 ヘルプ
https://support.google.com/a/answer/2614757?hl=ja

※登録ホストのIPアドレスやホスト名、ポート番号につきましては、当該サーバーのご提供元にご確認をいただけますよう、お願いいたします。

※Gmail の高度な配信設定(メールルートの追加)ページ内解説

ドメインのメールルートを追加する

Google 管理コンソール - Gmail

Google 管理コンソール にログインします。

管理コンソールのホームページから、[アプリ] 次へ [G Suite] 次へ [Gmail] 次へ [詳細設定] にアクセスします。
ヒント: [詳細設定] を表示するには、Gmail ページを最下部までスクロールします。

Google 管理コンソール -メールのルートを編集
  1. [ホスト] をクリックします。
  2. [ルートを追加] をクリックします。
  3. ルートの名前を入力します。わかりやすい名前を使用することをおすすめします。
  4. ルートのメールサーバーを指定します。

[単一のホスト] を選択した場合は、ルートのホスト名または IP アドレスを入力します(ホスト名の使用をおすすめします)。次に、ポート番号を入力します (25、587、または 1024~65535 の範囲の値)。

[複数のホスト] を選択した場合は、負荷分散とフェイルオーバーを目的として、複数のプライマリ ホストとセカンダリ ホストを指定することができます。[追加] をクリックしてホストを追加し、各ホストのホスト名、ポート番号、負荷の割合を入力します。負荷の割合は、各カテゴリ(プライマリとセカンダリ)で合計 100% になるよう指定します。たとえば、プライマリ ホストを 2 つ指定する場合は、ホスト名ごとに「50」と入力します。

hetemlのホスト名

hetemlへ念のため確かめたところ、動作確認外。ご自身で… という回答。まあ社外ですしね。

ヘテムルのレコードの設定については下記ページで確認できるのですが、G suiteのメール転送(ホスト名)としての情報はあまり見受けられなかったので、Google Cloud Support の方からいただいた内容と対処方法を

ヘテムル – レコードの設定(編集)をしたい

https://heteml.jp/support/faq/1602.html

もともと弊社で使っているヘテムルのサーバーですが、SSLへの対応から現在はサーバー番号が「usersXXX」となっていますが、途中で変更となったもので以前は「ftpXXX」でした。

※heteml はサーバーの契約時期によってサーバー番号が変わるため、その時期によってMXレコードが違います。

そのことからか、mx.hetemail.jpではなく今回のホスト名がftpXXX向けのMXレコードで説明のある「mail31, mail38, mail39, mail51とmail501以降 : mx-proxy501.heteml.jpとmx-proxy502.heteml.jp」になっているのかも。

上記ページの

プライマリネームサーバー dns0.heteml.jp ( 210.188.214.228 )

セカンダリネームサーバー dns1.heteml.jp ( 210.188.214.229 )

を一番最初に試していたのですが、送信メールはエラーで帰ってこなかったのですがどっかリレーでぐるぐるしてるみたいで(?)届きませんでした。
(ただ、この設定でもMXレコードの設定箇所に「mx-proxy501.heteml.jp」とか出てきていたような)

ホスト名 – hetemlの場合

ヘテムルで送受信できたホスト名と設定はコレ
mx-proxy501.heteml.jp : ポート番号 25
2. オプションはすべてチェックなし

設定 1
mx-proxy501.heteml.jp : ポート番号 25
設定 2
mx-proxy501.heteml.jp : ポート番号 587
設定 3
mx.hetemail.jp : ポート番号 25
設定 4
mx.hetemail.jp : ポート番号 587

「設定 1 の方から順に成功する可能性が高いと見受けられます。」とのことで、たしかにそれぞれポート番号25・587と2.オプションの各チェックの組み合わせを試してみたところ、通ってメールが受信できたのは設定 1の組み合わせのみでした。

ちなみに「反映時間もございますため、切り分けのため、設定後 1 時間ほどお待ちいただきますようお願いいたします。
※ 管理コンソール反映は最大で 24 時間かかりますが、一旦、1 時間をお待ちいただきますうようお願いいたします。」

このときのG suiteの管理コンソールのGmail詳細設定 > 全般設定のMX レコードはこんな感じ。

優先順位 参照先
1 ASPMX.L.GOOGLE.COM.
5 ALT1.ASPMX.L.GOOGLE.COM.
5 ALT2.ASPMX.L.GOOGLE.COM.
10 ALT3.ASPMX.L.GOOGLE.COM.
10 ALT4.ASPMX.L.GOOGLE.COM.
10 MX-PROXY501.HETEML.JP.
20 MX-PROXY502.HETEML.JP.

ポート番号25でTLSのチェックもしなくてちょっと心配もあるけど、heteml→ googleの転送時のみでメールクライアントなどで受信する場合は別なので、それはそれで大丈夫?なのかも。

Sponsored Links

<転送設定>

Google 管理コンソール -デフォルトの転送
Google 管理コンソール -デフォルトの転送

以下の手順を実施いただけますよう、お願いいたします。

  • 1.管理コンソール > アプリ > G Suite > Gmail > 詳細設定と遷移
  • 2.画面上部「デフォルトの転送」をクリック
  • 3.「設定を追加」
  • 4.以下の設定を実施

1.一致するエンベロープ受信者の指定
「全ての受信者」を選択

2.エンベロープ受信者が上記と一致している場合
-「メッセージを変更」を選択
-「ルートを変更」にチェック
-「通常のルーティング」をクリックいただくと先の手順でホスト登録いただいたルートが表示されますので、該当のホストをクリック

3.オプション
「この操作は認識されないアドレスに対してのみ実行しますにチェック」

上記で「保存」をクリック。

G suiteで使っているドメインのメールアドレスをGmail以外のメールクライアントアプリで送受信

これで無事にG suiteで使っているドメインのメールアドレスも、G suiteアカウントで使用しているもとメールエイリアスで使用している以外のメールアドレスをGmail以外のメールクライアントアプリで送受信できるようになりました。

いやはや、今回はこのホスト名にハマりました…汗
heteml関連だと、あまりG suite関連って出てこないもので。。

Google Cloud Support の皆さま、ありがとうございました。

G Suite – GoogleドライブファイルストリームでローカルPCの保存容量の増加とカレンダーの外部共有設定など

社内のデータのバックアップや保存場所として、社外スタッフとの共有なども考慮して外付けHDDやNAS、WebDavなどを利用していますが、今回改めて法人向けG Suite(Google Apps)を利用してみることにしました。

キメ手としはG Suite Businessプラン以上でオンラインストレージが無制限、なおかつローカルPC(Mac)のストレージ容量をほとんど使用しなかったりファイルの同期(意外とウザい)でPC側のリソースがほとんど使われないといった点。

正直ストレージだけなら導入も簡単なDropboxも良かったのですが、カレンダーや他のGoogle Appsを常時使用していることもキメ手でした。

今回、初期導入でちょっとつまづいた点をいくつかご紹介。

ちなみに、ヘルプチャットにお世話になりましたが、丁寧に対応していただきサービスに対してさらに好印象となりました。

GoogleドライブファイルストリームでローカルPCの保存容量を使用している?

Google ドライブ ファイル ストリーム ローカルフォルダ

ローカルPCのストレージを圧迫しないというのが良くて使ってみたGoogleドライブファイルストリームですが、当初、ローカルPC内に保存してあったフォルダをいくつかFinderでGoogleドライブファイルストリームのマイドライブ(/Volumes/GoogleDrive)へ移動させて確認してみたところ、PC(Mac)のストレージの空きが移動したフォルダ分と思われる分が減少…。

もしや、インストールしたGoogleドライブファイルストリーム(ローカル側)からFinderでフォルダを保存するとローカル側のストレージを使用してしまうのだろうか…と思い、オンライン上のG SuiteのGoogleドライブからマイドライブへフォルダをアップロードしてローカル側のストレージ容量を確認してみたところ、前述の状態とは異なり容量は減っておらず。

それもでも確かに便利といえば便利ですが、やはりちょっとすっきりとせずヘルプチャットへ問い合わせてみました。

ドライブファイルストリーム上からファイルをアップロードする際は、アップロードするファイルと同等かそれ以上の容量のキャッシュデータが一時的に ローカルドライブ上に必要です。

Finder(ローカルPC)から保存した場合、一時的にキャッシュデータが必要になり、その分が増加分として認識できるようです。

そのキャッシュデータのクリアにはローカルPC側でGoogleドライブファイルストリームから一旦ログアウトする必要がある(ちょっとめんどくさい)そうで、PCの再起動ではクリアされないそうです。

ファイルストリームのキャッシュのデータは、PC 上のファイルストリームからログアウトすることで、クリアされます。(容量が戻ります)そのため、再起動せずともクリアされることとなります。

~ ファイルストリームからログアウトしない場合は、クリアされないものとなります。

大容量の母艦であれば気になりませんが、限られたストレージのマシンの場合は非常に気になる点ですよね。
別途クリアされるタイミングももしかしたらありそうですが、キャッシュのデータのクリアについてはもう少し簡単だと助かります。

ドメイン外のユーザーとカレンダーの共有で閲覧権限以上の予定の変更権限のプルダウンが選択できない

知ってしまえば特になんてないところですが、ここはちょっとハマりました…汗

G Suiteでデフォルトで作成されいるカレンダー(メインカレンダー)を外部の人と共有する場合、管理コンソールより、

メインカレンダーの外部共有オプション > すべての情報を共有する(外部ユーザーにカレンダーの変更を許可する)

で共有・権限を変更することがかのうですが、ここはあくまでもメインカレンダーの設定のみ。

スタッフなど各ユーザーが作成する新しいカレンダーの共有・権限設定は管理コンソールのアプリ カレンダーの「全般設定の予備カレンダーの外部共有オプション」から設定する必要があります。

G Suite カレンダー共有設定画面

設定を変更して数分待つと、無事に新しく追加したカレンダーで共有した人の権限も変更できました。

G Suiteのメインアイコン(プロフィール画像)が変更できない

管理コンソールから会社プロフィール > カスタマイズ(ヘッダーロゴ)ではなくて画面右上に表示されるアイコン画像の変更ができず、

「もしかして試用期間だから?」と思っていたら、

「管理コンソール > G Suite > ディレクトリ」プロフィールの編集の写真にチェックを入れ、数時間後(ちょっと待ちました)に変更可能になりました。

G Suite プロフィールアイコン画像設定画面

今後人数が増えていったりするとさらに疑問点も増えそうですが、親切なヘルプチャットもあり心強いですね。

iOSでGoogle AMPの元ページURLなどを表示

ページ表示の高速化が可能なGoogle AMP

SERPからAMP対応のページへアクセスした際に、画面上部へアプリインストールと同じような表示形式でAMPキャッシュページではない元ページのURLを表示するようになっていました。
※タイトルで「iOSで〜」としていますが、現時点でAndroidで検証はしていないためです。

iOSでGoogle AMPの元ページURLなどを表示

上部に表示されたリンクアイコン(クリップ)をタップすると、AMPでキャッシュされた元のページURLが表示され、それをさらにタップすると元ページへ訪れることができます。

iOSでGoogle AMPの元ページURLなどを表示

リンクアイコンの右側の三点アイコンをクリックすると「詳細」と表示され、Google AMP Viewer の説明ページへのリンクが表示されます。

iOSでGoogle AMPの元ページURLなどを表示

読込速度の向上につながるAMPですが、検索結果から訪れたサイトが初めてのサイトの場合、それがオリジナルのページなのかAMPでキャッシュされたページが表示されているのか一見すると判断が付きません。
今回のようにページ上部に表示されれば、一瞬にしてそれを判断することができます。

内容を閲覧するだけであればとりあえずはどちらかであるかはあまり大きな問題ではないように思いますが、画一的に表示されるAMPキャッシュのページでは印象への残り方も違いますし、TwitterなどSNSへ投稿する際にもAMPページでは現状、og:titleなどが反映されませんが今回の改善ではその判別が簡単になりますね。

【簡易版】WordPressのAMP公式プラグインでGoogleアナリティクスとAdSenseを表示させる方法


Fatal error: Call to private method CodeColorer::performHighlightCodeBlock() from context '' in /virtual/kots/public_html/kazunoriiguchi.com/blog/wp-content/plugins/codecolorer/codecolorer-core.php on line 70