「モバイル ユーザビリティ」の問題が新たに 検出されました クエリパラメータでモバイル用ページが指定されない

SearchConsoleから以下のようなメッセージが届きました。

Search Console により、貴サイトに影響するモバイル ユーザビリティの新たな問題が 3 件検出されました。
主な問題（最大 5 件）

• 貴サイトでは、以下の問題が検出されました。
• テキストが小さすぎて読めません
• ビューポートが「端末の幅」に収まるよう設定されていません

クリック可能な要素同士が近すぎます

これらの問題について詳しく調べ、できる限り解決されることをおすすめいたします。これにより、サイトのエクスペリエンスと Google 検索結果での表示を最適化できます。

特にいままで通知がなかったので、新しい機能なんでしょうか？

１．エラーの詳細の確認

通知に表示されているボタンをクリックすると、詳細が確認できます。

１つのページでエラーが出ているみたいですね

エラーの内容も、同じものが表示されています。

エラー情報をクリックしていくと、問題のページのスクリーンショットや、ソースも確認できます。

スクリーンショットを見ると、確かに画面がはみ出ているようです。

でも、この記事にだけ特別なことはしていないと思うのですが・・・

２．原因の調査

ということで、今回エラーが発生したページは、以下のURLとなっています。

http://t-pirori.blogspot.com/2018/02/scratch_17.html?m=0

下の図は、エラーが発生していないサイトの一覧です。

エラーが出たページのURLを改めて見比べると「クエリパラメータ」がついています。

クエリパラメータというのはURLの後ろにつくオプションみたいなものです。

今回は「m=0」という部分がクエリパラメータです。

この「m=0」ってのは、どうやら「モバイルページじゃないよ」ってオプションのようです。

このオプションが「m=1」か、未指定の場合、おそらく「モバイルページだよ」という設定となり、表示方法が切り替わるみたいですね。

なので、エラーとなっているURLがモバイル対応していないのは普通ですね。

となると問題は「なぜ、モバイルページじゃない設定が、SearchConsoleでモバイル用としてチェックされているのか」ということになるようです。

３．URL検査

次にSeachConsoleで
http://t-pirori.blogspot.com/2018/02/scratch_17.html
http://t-pirori.blogspot.com/2018/02/scratch_17.html?m=0
の、それぞれのURLを検査してみます。

URL検査はSearchConsoleの上の検索バーにアドレスを入れるだけです。

http://t-pirori.blogspot.com/2018/02/scratch_17.html

http://t-pirori.blogspot.com/2018/02/scratch_17.html?m=0

どうやら、クエリパラメータのついたURLがインデックス登録されているようです。
ここを修正できれば、エラーが消えるかな？？

登録したいURL側で「公開URLをテスト」を選択してみます。

こちらのURLはモバイル対応されているようです♪

４．インデックスの登録

とりあえずURL検査のページから「インデックス登録をリクエスト」をクリックしてみました。
http://t-pirori.blogspot.com/2018/02/scratch_17.html

これで、しばらく様子をみてみようと思います。


翌日インデックス登録をリクエストしてページを再度、URL検査しました

http://t-pirori.blogspot.com/2018/02/scratch_17.html

無事、クエリパラメータなしのURLがインデックス登録されたようです。

５．結果確認

後日、SearchConsoleのモバイルユーザビリティを確認しました。
画像のように、3件あったエラーが0件になっています。

また、グラフ内の③という数値をクリックすると下のように、問題が解決された旨がメッセージで表示されました。

とりあえず、何か問題が出たときは、
１．指摘されたページのアドレスが変なものになっていないか？
を確認し、
２．おかしなURLは再度、URL検査とインデックス登録
することで対応できそうです。


（2019/7/25 追記）
英語圏の人にも届くように・・・
SearchConsoleでの英語版メッセージは「Fix mobile usability issues」ってのがキーワードみたい

新機能である「ドメイン プロパティ」がアカウントに追加されました

SearchConsoleに

新機能である「ドメイン プロパティ」がアカウントに追加されました
というメッセージが届いていました。

Search Console ユーザーの皆様
Search Console チームでは、ユーザーの皆様からのフィードバックに基づき、常にサービスの改善に努めています。これまでユーザーの皆様からは、http や https、www、m など、サイトのバリエーションごとにプロパティを作成するのが面倒だとのご意見をたびたび頂戴していました。そこで Search Console チームはこのたび、一般的なサイト バリエーションを 1 つのプロパティに集約できる便利な新機能、「ドメイン プロパティ」を導入いたしました。
ドメイン プロパティには、すべてのサブドメイン、パス、プロトコル の URL が含まれます。たとえば、ドメイン プロパティを「example.com」と定義した場合、プロパティには、example.com、m.example.com、www.example.com に加え、example.com のその他すべてのサブドメインの URL（http と https の両方）が含まれます。
このプロパティを追加しても、既存のプロパティには影響せず、プロパティが削除されることはありません。このプロパティは、必要に応じて削除できます。ドメイン プロパティは、新しい Search Console でのみご利用いただけます。
なお、お客様の既存のプロパティに基づいて、以下のドメイン プロパティがすでに作成されています（最大 8 個を記載しています）。
t-pirori.blogspot.com
お客様のアカウントでは、現時点ではこのプロパティをお使いいただけます。

どうやら、少し前に廃止されることになった「プロパティセット」の代替品のようです。

SearchConsoleのプロパティ一覧に「ドメインプロパティ」という項目が増えています。

以前の記事にも書きましたが、Bloggerでは記事に対して、複数のURLからアクセス可能です。
なので、httpやらhttpsやらからのアクセスを集約する必要がありました。
そのために使用していた「プロパティセット」の機能を「ドメインプロパティ」が自動で設定してくれているようです。
今後はこの「ドメインプロパティ」の確認をしていけば大丈夫そうです。

オムライスのブラッセリエ

記事のタイトルは「オムライスのブラッセリエ」と書きましたが、実際にはいろんなメニューがあるので、ほかのメニューも力を入れているようです。
入り口の看板にも「オムライスとラーメンのおいしいお店」と書いてあったような・・・

富山市婦中町にある、洋食屋ブラッセリエに行ってきました。
かなり昔からあるお店ですが、10年ぶりくらいの来訪です。
特に行かなかった理由もないんですが、、、立地ですかね（汗

一番ベーシックなトマトソースオムライス（850円）を注文しました。

日ごろ、島田食堂のオムライスも好きでよく食べるのですが、ブラッセリエのオムライスは、ふわふわ玉子の「洋食」オムライスという感じで、味や雰囲気は別物ですがとても美味しいです♪

ちなみに店内の注文は店員を呼ばなくても、タブレットから注文が可能でした。
店員さんから目が届きにくい席もありそうな店内なので、タブレットからの注文は良い発想だと思います♪

大盛りやトッピングなど、いろんな選択肢もあって良い出来のメニューでした（笑

今回はオムライスを注文しましたが、オムラーメンなどのメニューもあるようなので、今度はそちらを食べてみようかな


ブラッセリエ
〒939-2723　富山県富山市婦中町萩島４３３－１
電話番号：076-466-5666
営業時間：11:00～22:00

tempdbがSHRINKFILEで圧縮できない

SQL Server2014 StandardEditionにて確認

SHRINKFILEでファイルを圧縮する際に、tempdbが圧縮できなかったケースがあったので覚書

temdbを圧縮するコマンドはこんな感じ。

DBCC SHRINKFILE（tempdb, 0）

ただ、今回は以下のようなエラーが出ました。

DBCC SHRINKFILE ページ N:Nは、作業テーブル　ページなので移動できませんでした。

このエラーメッセージで検索してもあまり情報がありません。
で、英文では以下のようなメッセージのようです。

Page N:N could not be moved because it is a work table page.

こちらのメッセージで調べると、クエリプランを再作成が必要だそうです。

DBCC FREEPROCCACHE

を行うことで、一時テーブルのキャッシュがクリアされて圧縮可能となりました。
ただ、FREEPROCCACHEはそれなりにコストがかかる作業かなと思うので、

DBCC FREESYSTEMCACHE (‘Temporary Tables & Table Variables’)




などの方が良いかもしれません。（未調査です）


ちなみに、今回のようにtempdbの圧縮が失敗すると、tempdbの初期サイズが書き換わってしまうそうです。
tempdbが肥大化していた場合、次回のSQLServerの起動に悪影響を与えることもあるそうなので、注意したほうが良さそうです。

【参考URL】
TempDB を圧縮する場合の注意点について

SQLServerのmdfファイルのサイズを取得する

SQL Server2014 StandardEditionにて確認

SqlServerで使用しているDBのファイルサイズを調べる場合

Select name, size From sys.database_files;

 
でmdfファイル、ldfファイルのサイズが取得できます。

tempdbについてもmdfファイルのサイズを取得したい場合は

Select name, size From sys.master_files;

 
を使いたくなりますが、なんだか結果が実際の値と合わない。。
Microsoftによるとsys.master_filesのサイズは、

データベース スナップショットの場合、size は、スナップショットがファイルに対して使用する中で最大の領域を表します。

とのこと。
でも、
USE tempdb
でDB変更すると
Select name, size From sys.database_files;
で実際のファイルサイズが取得できました。
でも、sys.database_filesの説明にも同じことしか書いてないのですが・・・