What 369 Real Searches After iOS 27 Actually Asked For

Between 20 September and 6 October 2026 — the first weeks of iOS 27 — this site's Google Search Console account recorded 1,630 query records covering 369 distinct search terms. We classified every one of them by the symptom it describes, counted the result, and published the SQL that produces every figure below. This page is what came out, including the parts we cannot explain.

The short version: the searches that reached us were about heat, storage accounting and wireless connections, in that order. The problems people usually assume dominate a bad update — crashing apps and missing notifications — were a rounding error.

What this data is, and what it is not

The source is our own Search Console export, held in this project's database and re-runnable from the docs/growth/data/query-mix-study/ files published with it. It is a real measurement of real searches, and it has six hard limits that you should read before quoting any number on this page:

1. It is one site. WhyMyPhone is a small troubleshooting site that launched in September 2026. Its search visibility is a slice of one market, not a sample of iPhone users.
2. It is the head of the distribution. The export returns roughly the top 200 queries per day, so the long tail is missing entirely. Everything here describes the biggest queries, not all queries.
3. It is 10 daily exports, not 17. We captured 12 days between 20 September and 6 October. Two of them (25 September and 2 October) were byte-identical to the previous day's export, which we read as a failed fetch that rewrote the previous result; we dropped the repeats. Five calendar days have no query-level data at all. The window is frozen at 6 October. Search Console keeps delivering new days — one landed while this page was being written — so the analysis pins the end date rather than reporting "the latest available". Without that pin the same query returns a different total every week, and nothing here would be checkable. The days excluded for that reason are listed in report-14.
4. The rows do not reconcile with our daily totals. Taken day by day, query-level impressions range from under 3% of that day's total (our first, partial export) up to 164.5% of it. We never found a clean explanation, so this study only ever reports shares inside the query set and never converts them into a share of site traffic.
5. Our own library shapes what we can appear for. We rank for questions we have written about. A problem we never covered cannot show up in this data no matter how common it is.
6. Classification is ours. We assigned each search term to a symptom cluster with a documented regular-expression rule, not by reading each one by hand. The rule is in the published SQL, so you can disagree with it and re-run it.

The mix: heat, System Data and Bluetooth took nearly two-thirds

Every term was assigned to exactly one cluster. Impressions are how many times a page of ours appeared in results for that term; position is where it appeared; CTR is the share of those appearances that were clicked.

Four of those clusters — heat, storage, lag and battery — describe symptoms our own content attributes to the same process: the background work iOS runs after an install, which is documented by Apple as taking hours to days depending on how much data you have. Together they are 67.2% of all impressions. That grouping is our editorial reading of the mechanism, not something the search data proves on its own; the mechanism itself is set out in How long does iOS indexing take?.

A second observation is easy to miss in the table: the clusters where we rank best are not the clusters with the most demand. We sat at average position 7.0–8.0 for notifications, app crashes and connectivity, and at 10.5–12.5 for lag and heat — yet heat drew nine times the impressions of crashes (1,779 against 195). Ranking well for a question fewer people ask does not produce traffic.

Crashes were 2.5%, and that is not a coverage artefact

The obvious objection to "crashes were 2.5%" is that we simply did not write about crashes. We did: two pages on iOS 27 crashing apps and two on missing or delayed notifications, and both clusters ranked better than heat — average position 7.5 and 7.0 against 12.5. They got few impressions while ranking well.

That is the useful signal. Impressions at a mediocre-but-consistent position are a rough proxy for how many people are searching the term at all: we appear, and almost nobody clicks through because the question is rare. On that reading, the iOS 27 problem wave as seen from search was a thermal and storage-accounting wave, not a stability wave. See iOS 27 apps crashing and iOS 27 System Data for what those two clusters actually contain.

Two different mechanisms wear the same "after the update" label

The third-largest cluster — within a rounding error of the second — is the one that does *not* fit the post-update settling story. Bluetooth drops, AirPods disconnections, CarPlay trouble and SIM detection are 20.4% of impressions, and they hold the single largest term of the whole set:

The mechanism our content describes for these is not background indexing — it is connection state: stale pairing records written under the previous system version, accessory firmware updating on its own schedule, and a changed 2.4GHz interference picture. Those are covered in iOS 27 Bluetooth issues. Lumping them into "the update broke my phone" would be wrong, and the search data is precisely what makes the distinction visible: people type the same three words for two unrelated causes.

Nobody searched for the new features

Zero of the 369 terms matched any feature-related language — no new-interface names, no assistant names, no "review", no "how to use". Every single term was about something misbehaving or a switch people did not understand.

Read that carefully, because it has an obvious alternative explanation: we published no feature pages, so we could not have appeared for them even if people searched them. This is the clearest illustration of limit 5 above. What the zero does support is narrower and still useful — in the queries we were eligible for, nobody was looking for what the release added.

The version-agnostic layer is 13% of demand and our weakest ground

155 of the 369 terms name no operating system and no phone model. Unlike the version-tagged queries, this layer behaves completely differently:

Average position 34 means page four: we are effectively invisible, and the 1.8% CTR follows from that rather than from any failure of the page. This is where the evergreen questions live, and several of them carry real, steady volume:

These are the "what does this switch actually do" questions — the ones that do not expire when the next release lands. The version-specific pages that answer them are already written (Background App Refresh, Battery health by model); the problem recorded here is position, not content.

Where the demand arrived from

Our default language is English, yet 58.5% of the impressions and 67.7% of the clicks came from queries written in another script. Japanese terms produced 45.7% of clicks from 38.3% of impressions.

One caution before this gets quoted: query language and page language are entangled. A Japanese query reaches our Japanese page, an English query our English page, and the two versions are not identical in length, structure or internal linking. Nothing here supports the claim that Japanese-speaking users have more iPhone problems. The defensible statement is about the reachable market, not about people.

The number we cannot explain

The System Data family is the cleanest illustration of how careful you have to be with CTR. Five different wordings of what looks like one intent, all ranked between position 5.9 and 7.8, produced this:

We can see the pattern and we cannot attribute it. Snippet matching, intent specificity, how the query earned its impressions across days — none of it is separable in a 10-day window with these sample sizes. We are publishing it rather than smoothing it over, because a study that hides its noise is less useful to whoever cites it than one that marks where the noise is.

How to reproduce every number

The full analysis lives in docs/growth/data/query-mix-study/ in this project's repository:

• base.cte.sql — the deduplication, the frozen analysis window and the classification rules, including the regular expressions
• report-00 to report-14 — one file per table on this page
• run.sh — re-runs all of them and writes OUTPUT.txt
• coverage-map.csv — how many of our own articles sit in each cluster
• OUTPUT.txt — the saved output, so you can compare against a re-run

```bash

export DB9_API_KEY=<key>

bash docs/growth/data/query-mix-study/run.sh

```

Two robustness checks are built in. Re-classifying with a deliberately coarser rule (fewer keywords per cluster) changes no named cluster by more than 1.9 points of impression share and leaves the top three — heat, System Data, connectivity — in the same order. The catch-all bucket absorbs the terms the coarser rule stops recognising, growing from 3.5% to 16.2%, so treat that bucket as a classifier artefact rather than a finding. And counting our own articles per cluster — 11 thermal, 7 connectivity, 6 storage, 5 battery, 2 lag, 2 crashes — shows the impression mix broadly tracking the coverage mix, which is why limit 5 above matters more than any other. 76.3% of the impressions came from terms seen on seven or more of the ten exports, so this was a sustained wave rather than a single day's news spike.

Related

• How long does iOS indexing take?
• iOS 27 System Data: how much is normal
• iOS 27 Bluetooth issues
• iOS 27 lag and stuttering
• What is Background App Refresh?