What is mobile usability actually about?

Whether a page is easy to use on a mobile device — legible text, tappable targets, content that fits the viewport, and no intrusive interstitials

Which version of your page Google indexes

How fast the page loads, measured as LCP, INP, and CLS

Whether your site appears in Bing's index

What happened to Google's Search Console Mobile Usability report and Mobile-Friendly Test tool?

They were retired on December 1, 2023, because better tooling like Lighthouse had matured

They were merged into the Core Web Vitals report

They still work but were renamed

They were retired because mobile usability stopped affecting rankings

Which mobile-friendliness test tool is still live as of this article?

Bing's Mobile Friendliness Test Tool

The Search Console Mobile Usability report

How much does mobile usability affect rankings?

It's one page-experience signal among several — Google will still surface the most relevant content even with a sub-par experience

It's Google's single most heavily-weighted ranking factor

It has no effect on rankings at all

It only matters for Bing, not Google

モバイルユーザビリティ

要点 — mobile usabilityとは、zoomせず読める文字、押し間違えない大きさのbutton、横scrollなしで画面に収まるcontent、本文を覆わないpopupなど、phoneでpageを使いやすいかどうかです。Googleはこれらを検出したreportを2023年12月に廃止しましたが、確認項目の重要性は変わりません。

Mobile usabilityとは

mobile usabilityは、phoneでpageを開いた人がlayoutと格闘せず、読んでtapし、目的の場所へ進めるかを示します。load速度やGoogleのindexingとは別の、small touchscreenでの実際の使いやすさです。

成否を分ける要素は4つあります。

読める文字。 paragraphを読むためにzoomが必要なら小さすぎます。
tapしやすいbuttonとlink。 指はmouseほど正確ではなく、小さいtargetや密集したtargetは押し間違えます。
画面幅に収まるcontent。 phone幅に収め、横scrollを発生させません。
contentを覆うpopupがない。 到着直後のfull-screen広告やnewsletter overlayはusabilityを損ない、検索にも影響し得ます。

重要な理由

多くの人がphoneで検索するため、mobileで使いにくいpageは大半の訪問者にとって使いにくいpageです。Googleもranking判断にmobile版を使います。これはモバイルファーストインデックスという別の概念ですが、mobile experienceが中心課題である点は同じです。

“Wait, where did the Mobile Usability report go?” (翻訳) 「Mobile Usability reportはどこへ？」

GoogleはSearch ConsoleのMobile Usability reportと単独のMobile-Friendly Test toolを2023年12月1日に廃止しました。mobile usabilityが不要になったのではなく、Chrome内蔵のLighthouseなど、より優れたtoolが役割を担うようになったためです。“open the Mobile Usability report,” (翻訳) 「Mobile Usability reportを開く」と案内するtutorialは古い情報です。

現在の確認方法

最も簡単なのは、Chromeでpageを開き、右click → InspectからLighthouseを実行する方法です。pagespeed.web.devのPageSpeed Insightsでも、小さいfont、密集したtap target、viewport問題を検出できます。browser幅を縮めるかdevice previewで実際に見れば、明らかな問題も発見できます。

混同しやすい2つの概念

モバイルファーストインデックス — Googleがどの版を読むかの話で、mobile版が対象です。
Core Web Vitals — 速度と安定性を測る別の指標群です。

tap targetの正確なthreshold、report廃止の経緯、現在利用できる確認方法はAdvancedタブで詳しく説明します。

要点 — mobile usabilityはtouch deviceでの使いやすさです。主な要素は、読める文字（Lighthouseはtextの60%以上が12px以上なら合格。本文は実務上16pxが基準）、tap target（48×48 CSS px未満、または中心から48px以内でtargetの25%以上が隣と重なると不合格。spacingは約8pxが出発点。WCAG 2,2の24×24 CSS pxは別のaccessibility最低基準）、viewportに収まるcontent（適切なviewport meta tagだけでresponsive layoutは保証されず、横scrollをなくす）、邪魔なinterstitialがないことです。 GoogleはSearch Console Mobile Usability report、Mobile-Friendly Test tool、APIを2023年12月1日に廃止しました。signalが不要になったのではなく、Lighthouseの成熟とmobile-first indexingの実質完了が理由です。現在はLighthouse、PageSpeed Insights、DevTools device emulation、Bingのtest、crawlerを組み合わせます。mobile-first indexingやCore Web Vitalsとは別のpage-experience signalで、単独の強いranking factorではありません。

正確な定義

mobile usabilityはmobile／touch deviceでpageを使いやすいかを示し、Googleの広いpage experience modelに含まれます。中心となる4つのsignalを、実際のthresholdと出典付きで確認します。

Signal 1：読めるtext

本文を読むためにpinch zoomが必要ならfontが小さすぎます。混同しやすい2つの数値を区別してください。

audit合格基準は12px。 Lighthouseは “Aim to have a font size of at least 12 px on at least 60% of the text on your page.” (翻訳) 「page内textの60%以上でfont sizeを12px以上にする」と案内します。
実務上の基準は約16px。 12pxは自動checkの最低基準で、phoneで快適とは限りません。本文は16px以上、headingはさらに大きくします。

つまり12px／60%は合格線で、本文で実際に目指す基準は16pxです。

Signal 2：tap target

指はmouseほど精密ではありません。Lighthouseは “the target is smaller than 48 px by 48 px,” (翻訳) 「targetが48×48px未満」、または “at least 25% the target area within 48 px of the center of the target overlaps with another target.” (翻訳) 「target中心から48px以内の領域の25%以上が別targetと重なる」場合に不合格とします。

48×48 CSS pxのtargetは安定して合格します。
見た目ではなくtap可能領域が対象なので、小さいiconでも padding で48pxにできます。
target間は約8pxが出発点ですが、小さいtargetでは不十分な場合があります。

古いGoogle guidanceの約7mm、spacing約5mmという説明も概ね48pxと整合します。現在は48px／8pxを使い、mm値は歴史的情報として扱います。

別基準として**WCAG 2,2 SC 2.5.8（Target Size Minimum、Level AA）**は24×24 CSS pxを定めます。これはW3Cのaccessibility基準でGoogle Searchのranking thresholdではありません。Lighthouseの48pxと目的が異なるため、固定的な「Google要件」として混同しないでください。

Signal 3：viewportに収まるcontent

contentはphone幅に収め、横scrollや縮小されたdesktop幅表示を避けます。その仕組みがviewport meta tagです。未設定や誤設定ではmobile browserがdesktop幅を想定して縮小します。修正は <head> 内の1行です。

<meta name="viewport" content="width=device-width, initial-scale=1">

Googleは “make sure your page content fits the width of the viewport, keeping in mind that not all mobile devices are the same width.” (翻訳) 「mobile deviceの幅は同じではないため、page contentをviewport幅に収める」と案内します。特定phoneだけに合う固定pixel幅は避けます。

tagは必要ですが、それだけでは不十分です。layout viewportをdevice幅へ合わせるだけで、固定幅contentをresponsiveにはしません。wide table、改行不能な長い文字列、固定pixel containerがviewportより広ければ失敗します。tagがcanvasを設定し、実際に収めるのはCSSです。

Signal 4：邪魔なinterstitialがない

検索から来た直後にcontentを覆うfull-screen popupは、usabilityと検索の両方の問題です。Googleは “intrusive interstitials and dialogs are page elements that obstruct users’ view of the content, usually for promotional purposes,” (翻訳) 「邪魔なinterstitialやdialogは通常、宣伝目的でcontentの表示を妨げる要素」と定義し、“make it hard for Google and other search engines to understand your content, which may lead to poor search performance.” (翻訳) 「検索engineがcontentを理解しにくくなり、検索performance低下につながり得る」と警告します。“don’t obscure the entire page with interstitials” (翻訳) 「interstitialでpage全体を覆わない」で、画面の一部だけを使うbannerが代替です。

Mobile Usability reportに何が起きたか

最近公開されたguideにも誤りがあるため、timelineを正確に確認します。

2023年4月 — 発表。 Googleは “Also starting December 1, 2023, we’ll be retiring Search Console’s ‘Mobile Usability’ report, the Mobile-Friendly Test tool and Mobile-Friendly Test API. This doesn’t mean that mobile usability isn’t important for success with Google Search.” (翻訳) 「2023年12月1日からreport、tool、APIを廃止するが、mobile usabilityがGoogle Searchで重要でないという意味ではない」と説明しました。理由は “in the nearly ten years since we initially launched this report, many other robust resources for evaluating mobile usability have emerged, including Lighthouse from Chrome.” (翻訳) 「約10年でLighthouseなど堅牢な評価resourceが登場した」ためです。
2023年12月1日 — 廃止。 report、tool、APIが終了し、旧URL search.google.com/test/mobile-friendly はLighthouse文書へ、Search Console reportはoverviewへredirectされました。
2023年12月4日 — 確認。 Search Console accountが廃止を公表し、“for working with us on this journey.” (翻訳) 「この歩みに協力してくれたこと」へ謝意を示しました。

なぜこの時期か。 mobile-first indexingが実質完了し、Googleは2023年10月31日に “the trek to Mobile First Indexing is now complete” (翻訳) 「Mobile First Indexingへの歩みは完了」と発表しました。またLighthouseが旧toolより実用的になりました。signalではなく専用reportが役割を終えたのです。

実務上の修正は、「Mobile Usability reportを確認」「Mobile-Friendly Testを実行」と案内しないことです。どちらも終了しています。私のAhrefs記事Mobile-First Indexing Goes Mobile-Onlyにも2024年6月更新時点で古い案内が1か所残っており、この記事が正す対象です。

現在mobile usabilityを確認する方法

専用reportがない現在は、複数toolを組み合わせます。

Chrome Lighthouse（DevTools → Lighthouse）— font、tap target、viewport auditと失敗要素を示します。
PageSpeed Insights（pagespeed.web.dev）— cloudでmobile profileのLighthouseを実行し、共有可能な結果を得ます。
Chrome DevTools device toolbar — phoneをemulateし、横scroll、小さいtext、窮屈なcontrolを確認します。
Bing Mobile Friendliness Test Tool — Bingには現在もtestがあります。Bingは “making pages mobile-friendly increases user engagement on mobile devices. It can also help you rank better in Bing search results on mobile devices.” (翻訳) 「mobile-friendly化はengagementを高め、Bingのmobile検索rankingにも役立つ」と説明します。
Third-party crawler — mobile user-agentでsite全体を監査します。
実device — 実際のphoneで確認します。

単独toolでend-to-end usabilityは証明できません。Lighthouse／PageSpeed Insightsの自動audit、DevToolsのemulation、少なくとも1台の実deviceを組み合わせます。

Mobile usability、mobile-first indexing、Core Web Vitalsの違い

次の3概念は関連しますが、別物です。

概念	内容	例となる質問
Mobile usability	phoneでpageを使いやすいか	tap targetは十分に大きいか
Mobile-first indexing	Googleがpageのどの版をindexするか	mobile HTMLに全contentが含まれているか
Core Web Vitals	load、interaction、visual stability	LCPは2,5秒未満か

mobile-first indexing済みでも、小さいtextや密集buttonでmobile usabilityが悪いsiteはあります。逆も同様です。本記事はindexingやCore Web Vitalsではなくusability layerだけを扱います。

Mobile usabilityはrankingへ影響するか

影響はありますが過大評価しないでください。mobile usabilityは広いranking system内のpage experience signalです。Googleは “should not focus on only one or two aspects of page experience,” (翻訳) 「page experienceの1、2項目だけへ集中すべきでない」、また “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (翻訳) 「page experienceが不十分でも最も関連性の高いcontentを表示する」と説明します。魔法のranking boostではなく、userのために修正します。

Mobile SEO cluster内での位置づけ

これは広いmobile SEOの一部です。mobile-first indexingはGoogleが読む版とcontent parity、mobile SEO checklistは監査手順を扱います。本記事はusability signalに範囲を限定します。

AI向け要約

Advanced版の要約です。

Mobile usabilityはtouch deviceでの使いやすさ。 読めるtext、tap target、viewportへ収まるcontent、邪魔なinterstitialが4要素です。
Text: Lighthouse合格は12pxかつtextの60%以上、本文の実務基準は16pxです。
Tap target: 48×48 CSS px未満、または中心から48px以内で25%以上重なると不合格。tap可能領域が対象でspacingは約8pxから。WCAG 2,2 SC 2.5.8の24×24 CSS pxは別のaccessibility最低基準です。
Viewport: <meta name="viewport" content="width=device-width, initial-scale=1"> を設定し、横scrollをなくします。tagだけでは固定幅contentをresponsiveにしません。
Interstitial: entry時のfull-page overlayを避け、小さいbannerを使います。
旧reportは廃止。 2023年12月1日にreport、tool、APIが終了しました。
現在の確認: Lighthouse、PageSpeed Insights、DevTools、Bing test、crawler、実deviceを使います。
別概念: mobile-first indexing、Core Web Vitalsとは異なります。
Ranking: 広いsystem内のsignalの1つです。

公式文書

検索engineの一次資料です。

Google

page experienceとhelpful content（2023年4月） — report、tool、API廃止の発表。
Google page experience — signalの位置づけと注意。
邪魔なinterstitialとdialogを避ける — 定義とbanner代替。
Mobile-first indexing完了（2023年10月） — 完了milestone。

Chrome／Lighthouse

読めるfont size — 12px／textの60%というthreshold。
適切なtap target size — 48×48 CSS pxとoverlap／spacing rule。

Bing／Microsoft

Bing Mobile Friendliness Test Tool — Bing Webmaster Toolsで現在も利用できるtest。

W3C

Target Size (Minimum) — WCAG 2,2 SC 2.5.8 — Lighthouseの48pxとは別の24×24 CSS px accessibility最低基準。

出典の引用

Google、Chrome／Lighthouse、Bingの発言です。各linkは対応箇所を示します。

Google — reportとtoolの廃止（2023年4月発表）

“Also starting December 1, 2023, we’ll be retiring Search Console’s ‘Mobile Usability’ report, the Mobile-Friendly Test tool and Mobile-Friendly Test API. This doesn’t mean that mobile usability isn’t important for success with Google Search.” (翻訳) 「2023年12月1日からreport、tool、APIを廃止しますが、mobile usabilityがGoogle Searchで重要ではないという意味ではありません」 — Google Search Central Blog。記事を読む
“In the nearly ten years since we initially launched this report, many other robust resources for evaluating mobile usability have emerged, including Lighthouse from Chrome.” (翻訳) 「公開から約10年で、ChromeのLighthouseを含む堅牢な評価resourceが登場しました」記事を読む

Google — page experienceの位置づけ

“Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (翻訳) 「page experienceが不十分でも、Google Searchは最も関連性の高いcontentを表示しようとします」 — Google Search Central docs。引用へ

Google — 邪魔なinterstitial

“Intrusive interstitials and dialogs are page elements that obstruct users’ view of the content, usually for promotional purposes.” (翻訳) 「邪魔なinterstitialやdialogは通常、宣伝目的でuserのcontent表示を妨げるpage要素です」 — Google Search Central docs。引用へ

Google — mobile-first indexing完了（背景）

“We’re delighted to announce that the trek to Mobile First Indexing is now complete.” (翻訳) 「Mobile First Indexingへの歩みが完了したことを発表します」 — Google Search Central Blog、2023年10月31日。引用へ

Chrome／Lighthouse — threshold

“Aim to have a font size of at least 12 px on at least 60% of the text on your page.” (翻訳) 「page内textの60%以上でfont sizeを12px以上にします」 — Chrome開発者向け文書／Lighthouse文書。引用へ
tap targetは “48 px by 48 px” (翻訳) 「48×48px」を満たさない場合や、中心から48px以内で領域が重なる場合に不合格です。引用へ

Bing — 現在も使えるtool

“Making pages mobile-friendly increases user engagement on mobile devices. It can also help you rank better in Bing search results on mobile devices.” (翻訳) 「pageのmobile-friendly化はengagementを高め、Bingのmobile検索結果でranking向上にも役立ちます」 — Bing Webmaster Tools。 toolを開く

注：2023年4月のGoogle Search Central記事はclient-side renderingのため、このpassでは全文の自動検証ができませんでした。引用した2文は同記事を参照する複数のsecondary sourceにも原文どおり掲載されています。公開前にlive pageで再確認してください。その他の引用はdirect fetchで確認済みです。

report廃止後にmobile usabilityをどう確認するか

古い “just open the Mobile Usability report” (翻訳) 「Mobile Usability reportを開くだけ」という方法は使えません。目的に応じた現行toolを選んでください。

Choosing a mobile-usability checker now that the GSC report is gone

Mobile usability checklist

次の4 signalをmobile rendering（DevTools device modeまたは実phone）で確認します。

zoomなしで本文を読める — 約16pxを基準とし、最低でもLighthouseの12px／textの60%以上を満たす。
tap targetが48×48 CSS px — 小さいiconならpaddingでtap領域を広げる。
targetが密集していない — 中心から48px以内で重ねず、約8px以上離す。
viewport meta tagがある — <meta name="viewport" content="width=device-width, initial-scale=1">。
横scrollがない — viewportより広い固定pixel要素がない。
検索entry時に邪魔なinterstitialがない — full-page overlayを避け、小bannerや法的gateだけにする。
robots.txtでCSS／JSをblockしない — Googlebotのrenderingに必要。
Lighthouse／PageSpeed Insightsで監査済み — 廃止toolへ依存しない。
実deviceでspot check済み。

判断に使えるmental model

1. 4 signal、1つの問い。 読めるtext、tap target、viewport適合、邪魔なinterstitialのどれが失敗しているかを特定してから修正します。

2. audit最低基準を目標にしない。 Lighthouseの12pxと48pxはfloorです。本文16pxと十分なspacingを目指します。

3. 見た目ではなくtap可能領域。 小さいiconでも padding でhit areaを48pxにできます。見えるpixelだけでなく操作領域を設計します。

4. 同じではない3概念。

mobile usability ≠ mobile-first indexing（indexする版）。
mobile usability ≠ Core Web Vitals（load／interaction／stability）。
mobile usability ≠ 単独の強いranking factor。

5. tool変更を習慣へ反映する。 GSC reportとMobile-Friendly Testは2023年12月に終了しました。Lighthouse、PageSpeed Insights、DevTools、Bing test、crawlerを使います。process文書に “check the Mobile Usability report,” (翻訳) 「Mobile Usability reportを確認」とあれば、その文書を更新します。

Mobile usability cheat sheet

4 signalとthreshold

Signal	基準	出典
読めるtext	textの60%以上が12px（audit合格）、推奨は約16px	Lighthouse
Tap target	48×48 CSS px、中心から48px以内で重ならない	Lighthouse
Tap spacing	約8pxから開始（小さいtargetはより広くする）	Lighthouse
Tap target（accessibility）	24×24 CSS px以上（Level AA）、spacingの例外あり	WCAG 2,2 SC 2.5.8
Viewport	`width=device-width, initial-scale=1`、横scrollなし	Google
Interstitial	entry時にfull-page overlayを表示せず、小さいbannerは可	Google

viewportの1行設定

<meta name="viewport" content="width=device-width, initial-scale=1">

重要date

2023年4月 — 廃止を発表。
2023年10月31日 — mobile-first indexing完了宣言。
2023年12月1日 — report、tool、APIを廃止。
2023年12月4日 — 公開確認。

旧toolのredirect先

Mobile-Friendly Test URL → Lighthouse docs。
GSC Mobile Usability report → GSC overview。

現在の確認tool: Lighthouse · PageSpeed Insights · DevTools device mode · Bing Mobile Friendliness Test · third-party crawler · 実device。

混同しない: mobile-first indexing（indexする版）· Core Web Vitals（LCP／INP／CLS）。

SOP：report廃止後のmobile usability監査

one-click reportがない現在の反復可能な手順です。1page約10分です。

ChromeでLighthouseを実行。 DevTools（⌘⌥I／Ctrl+Shift+I）→ Lighthouse → SEOとPerformance → MobileでAnalyze page load。fontやtap targetの失敗要素を記録します。
viewport tagを確認。 <head> の name="viewport" が width=device-width, initial-scale=1 か確認します。tagがない、または width=980 のような固定値なら修正します。
phoneをemulate。 device toolbar（⌘⇧M／Ctrl+Shift+M）でsmall deviceを選び、横scrollやはみ出しを確認します。
tap targetを手動test。 隣接linkを押し間違えるなら48px hit areaと約8px以上のspacingへ修正します。
entry interstitialを確認。 incognitoで検索流入のように開き、本文前のfull-page overlayを検出します。
Bing test／PageSpeed Insightsでcross-check。
重要pageは実deviceで検証。
signal別にticket化。 font、tap size／spacing、viewport、interstitialへ分類します。

Mobile usabilityのanti-pattern

現在も流通する古い助言を含む、繰り返される失敗です。

“Check the GSC Mobile Usability report.” (翻訳) 「GSC Mobile Usability reportを確認」 — 2023年12月1日に廃止され、overviewへredirectされます。
“Run Google’s Mobile-Friendly Test.” (翻訳) 「Google Mobile-Friendly Testを実行」 — 同日廃止され、旧URLはLighthouse docsへredirectされます。
12pxのaudit floorへ合わせる — 本文は約16pxを使います。
tap可能領域ではなくiconだけ測る — paddingを含む48px hit areaを確認します。
viewport meta tagの欠落／誤設定 — desktop幅renderingと縮小を引き起こします。
検索entry時のfull-screen interstitial — contentを妨げます。small bannerを使います。
robots.txtでCSS／JSをblock — Googlebotがmobile pageを正しくrenderできません。
単独の大きなranking leverと扱う — userのために修正します。
mobile-first indexingやCore Web Vitalsと混同 — 問題、修正、toolが異なります。

自分で実行できるquick check

廃止済みtoolがなくても、一般的な問題は次のsnippetで検出できます。

command lineでviewport meta tagを確認

# Does the page ship a proper viewport meta tag?
curl -s https://example.com/ | grep -i 'name="viewport"'
# Expected: <meta name="viewport" content="width=device-width, initial-scale=1">
# No output = no viewport tag (a mobile-usability failure).

横scrollを起こす要素を探す（DevTools console）

phone emulation中にChrome DevTools consoleへ貼り付けると、横scroll原因になりやすいviewportより広い要素を一覧表示します。

// Flag elements wider than the viewport
const vw = document.documentElement.clientWidth;
[...document.querySelectorAll('*')]
  .filter(el => el.getBoundingClientRect().right > vw + 1)
  .forEach(el => console.log(Math.round(el.getBoundingClientRect().right), el));

16px未満のtextを探す（DevTools console）

// List text-bearing elements rendered below the 16px baseline
[...document.querySelectorAll('body *')]
  .filter(el => el.childNodes.length && [...el.childNodes].some(n => n.nodeType === 3 && n.textContent.trim()))
  .map(el => ({ px: parseFloat(getComputedStyle(el).fontSize), el }))
  .filter(x => x.px < 16)
  .forEach(x => console.log(x.px + 'px', x.el));

Bookmarklet：小さいtap targetを強調

bookmarkとして保存しmobile emulation中に実行すると、rendered boxが48×48 CSS px未満のinteractive要素をoutline表示します。

javascript:(()=>{document.querySelectorAll('a,button,input,select,textarea,[role=button]').forEach(el=>{const r=el.getBoundingClientRect();if(r.width<48||r.height<48){el.style.outline='2px solid red';}});})();

注意点は、audit対象がpaddingを含むtap可能領域であることです。ここでflagされてもpaddingで48pxへ広がっていれば問題ない場合があります。

Mobile usability確認tool

Chrome Lighthouse — 廃止toolの直接的代替で、font、tap target、viewportの失敗要素を示します。
PageSpeed Insights — cloud上のmobile Lighthouseと共有可能な結果。
Chrome DevTools device toolbar — 実寸phone emulation。
Bing Mobile Friendliness Test Tool — 現在も利用できるsecond opinion。
Search Console URL Inspection — Googlebot smartphoneのrendered HTMLとscreenshot。
Ahrefs Site Audit — mobile user-agentでsite全体をcrawl。
実phone — emulationを補うground truth。

emulationでは正常だが実phoneで失敗する

症状: device toolbarでは正常でも、実userはcontent切れ、control重なり、dialogの操作不能を報告する。原因候補: browser chrome、safe-area inset、text scaling、OS keyboardをemulationできていない。修正: iOSとAndroidの実deviceでorientation、文字拡大、keyboard表示までtestします。

pageが横scrollする

症状: contentが右端から少しはみ出す。原因候補: 固定幅要素、改行不能文字列、table、image、100vw container。修正: 最も広い要素をDevToolsで調べ、mediaをresponsiveにし、長文をwrapし、padding付きcontainer内では width: 100% を使います。原因修正前に overflow-x: hidden で隠しません。

iconを大きくしてもtap targetが失敗する

症状: iconを大きくしてもLighthouseがcontrolをflagする。原因候補: interactive boxが小さいか隣接linkと重なる。修正: clickable要素自体へpaddingを追加し、targetを離し、DevToolsでhit boxを確認します。tiny anchor内のSVGだけ大きくしてもanchorは広がりません。

load後にtextが読みにくくなる

症状: initial HTMLは使えるがclient-side code後に小さいtextやdesktop layoutへ変わる。原因候補: responsive style／componentの遅延、breakpoint failure、server／client差。修正: JavaScript有効のrendered stateをtestし、breakpointを調べ、可能ならmobile layoutをinitial critical CSSへ含めます。

Mobile-usability修正が機能したことを証明する

実行するtest	期待結果	失敗の解釈	監視期間	rollback条件
320、375、412 CSS-pixel幅で代表templateをload	横scrollがなくprimary contentが見える	固定幅またはoverflow要素がnarrow breakpointを壊す	毎releaseとshared CSS変更後	navigation、checkout、primary CTAへ到達不能なら戻す
変更URLでLighthouse mobileを実行	viewport、font-size、tap-target auditが合格	見た目だけ変わりrendered geometryが未修正	deploy直前と直後	新しいaccessibility／navigation failureなら戻す
実iOS／Androidでcritical flowを操作	zoomなしで読め、tap、focus、dismissできる	emulationがbrowser、keyboard、OS挙動を再現できない	deploy当日とdevice regression test	primary taskを完了できなければ戻す
browser／OS text sizeを上げflowを再実行	clipping、overlap、control消失なしでreflow	固定text height依存またはuser scaling無効	release前とtypography変更後	必須text／actionが消えれば戻す
server HTMLとrendered DOMのresponsive contentを比較	重要contentとlinkがrender後も同等	client-side codeがmobile contentを削除／置換	deploy直後、1週間spot check	rendered mobile版がindex可能なprimary contentを失えば戻す

理解度test：Mobile usability

mobile usabilityに関する5問です。各問を選び答えを確認してください。

時間を使う価値のあるresource

私の記事

Mobile-First Indexing Goes Mobile-Only — mobile-first indexingとmobile design。2024年6月版には廃止済みtoolへの古い案内が残っています。
The Beginner’s Guide to Technical SEO — technical SEO全体での位置づけ。
Core Web Vitalsとは何か、改善方法 — usabilityと混同されやすいperformance側。

登壇資料

How Search Works — crawl、render、index、rankingとGooglebot smartphoneの解説。（注意書き：“This is my understanding of systems… not going to be 100% complete or accurate.” (翻訳) 「systemについての私の理解であり、完全または正確とは限りません」）

業界資料

page experienceとhelpful content（Google）— 廃止発表とLighthouse案内。
GoogleがMobile Usability report、tool、APIを正式廃止（Search Engine Land）— 平易な廃止解説。
Search Console Mobile Usability reportとtest終了（Search Engine Roundtable）— 2023年12月4日の確認とredirect先。
読めるfont size（Chrome／Lighthouse）— 12px／60%。
適切なtap target — 48×48 CSS px。
邪魔なinterstitialを避ける（Google）。
Bing Mobile Friendliness Test Tool — 現在も利用可能。

引用に使える数値

font audit合格：textの60%以上で12px — 推奨本文16pxではなく最低基準です。出典
tap target audit：48×48 CSS px未満、または中心48px以内で25%以上重なると不合格 — 見た目ではなくtap可能領域を測ります。出典
WCAG 2,2 SC 2.5.8：24×24 CSS px — W3Cの別のaccessibility最低基準です。出典
廃止日：2023年12月1日 — report、tool、APIを廃止し12月4日に確認。出典
mobile-first indexing完了：2023年10月31日。出典

変更履歴

2026年8月13日に更新。

編集概要と記録された変更の詳細。

変更の詳細

変更の詳細な注記は現在英語でのみ提供されています。
変更の詳細な注記は現在英語でのみ提供されています。

完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。

2026年8月13日に更新。

編集概要と記録された変更の詳細。

変更の詳細

変更の詳細な注記は現在英語でのみ提供されています。
変更の詳細な注記は現在英語でのみ提供されています。
変更の詳細な注記は現在英語でのみ提供されています。

完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。

2026年7月18日に更新。

編集概要と記録された変更の詳細。

変更の詳細

変更の詳細な注記は現在英語でのみ提供されています。
変更の詳細な注記は現在英語でのみ提供されています。
変更の詳細な注記は現在英語でのみ提供されています。

完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。