Search Console will group performance rows by seven dimensions, and searchAppearance is the one that says which result feature an impression came from. It also changes how the totals are aggregated, which is the part that surprises people.
searchAppearance is the Search Console dimension that says which result feature an impression came from — a discussion forum result, an AMP article, a plain blue link — rather than which page or which query produced it. It is the difference between knowing that a page ranks and knowing how it looked when it ranked. Grouping by it has one consequence worth knowing before you read the numbers: Google aggregates the table by page rather than by property, so the totals will not match a report grouped by query.
Grouping by page tells you which URL earned the impression, and grouping by query tells you what was typed. Neither says what the result looked like on the page of results. searchAppearance answers that: it groups the same clicks and impressions by the result feature Google displayed, so a page that earns impressions as a discussion forum result and as an ordinary text result appears twice, once under each feature. That is how a site finds out that its traffic comes from a feature it never asked for, or that a rich result it built structured data for is producing no impressions at all.
Three behaviours come with the search appearance grouping, and all three are Google's, not a client's. Grouping by search appearance aggregates the table data by page rather than by property, which changes the totals. The filter list offers only the appearance types for which the site has recorded impressions, so an empty list means no impressions of that kind rather than a broken filter. And the way to discover which values exist for a site is to run a query grouped by searchAppearance and read the keys that come back, because the set is not fixed and features are added and retired over time.
The aggregation detail is the one that causes arguments. A property-level total and a sum of per-page rows are already two different numbers in Search Console, and asking for search appearance quietly puts you on the per-page side of that split. Comparing an appearance-grouped total against a query-grouped total is comparing two aggregations, not finding a bug.
Search Console's regex filters are RE2 expressions, which is a deliberately smaller syntax than the one most regex tutorials teach. What RE2 leaves out, what to write in place of each missing construct, and the two things a filter does not change.
Search Console has no language dimension. On a site in more than one language you separate the data by page or by country, which means the URL structure you chose for translations decides what you can measure.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
| Feature in the interface | API value | Note |
|---|---|---|
| Discussion forums | FORUMS | Results that link to discussions and forums |
| AMP articles | AMP_TOP_STORIES | Also counted as rich results |
| AMP non-rich results | AMP_BLUE_LINK | A plain text and link result for an AMP page |
| Education Q&As | EDU_Q_AND_A | A Q&A page related to STEM education |
| FAQ rich results | TPF_FAQ | Deprecated: in the bulk data export, recent dates are null |
| How-to rich results | TPF_HOWTO | Deprecated: in the bulk data export, recent dates are null |
| Good page experience | PAGE_EXPERIENCE | Deprecated: in the bulk data export, recent dates are null |
The deprecated rows are worth reading carefully, because they are the reason a historical report can show a feature that has since gone quiet. Google lists these fields as still present in the bulk export schema with null values for recent dates, which in a time series looks exactly like a collapse in that feature's traffic. It is a retired field, not a lost rich result.
Discover and Google News do not accept the searchAppearance dimension, and they do not accept query either. Neither surface involves somebody typing a search, so there is no ranked result page and no result feature to report. A request that asks for those dimensions on a feed surface comes back as an error rather than as empty rows, which is the honest outcome: this product turns it into one sentence, that the type cannot be grouped by that dimension and which dimensions it does support, instead of relaying an opaque 400.
All three of those questions are read-only, and each of them costs nothing beyond a Search Console API call against a property you already own.
searchAppearance is a performance-report dimension that groups clicks and impressions by the search result feature they came from, such as a discussion forum result, an AMP article or a plain text result. It answers what the result looked like, rather than which page or query it belonged to. It is available for search surfaces and not for Discover or Google News, and grouping by it aggregates the table by page rather than by property.
Run a Search Analytics query grouped by searchAppearance and read the keys that come back. Google's API reference gives this as the way to see the available values, because the list is per-site: the interface shows filter options only for the appearance types for which your property has recorded impressions. A value missing from your list means no impressions of that kind, not a missing feature in the API.
The Search Analytics API places no limit on how many dimensions you group by, other than that the same dimension cannot be used twice, so searchAppearance can be sent alongside page, date or country in one request. What changes is the aggregation: grouping by search appearance aggregates the table by page rather than by property, so the row totals of that report are not comparable with a property-level total.
Some appearance fields have been retired. Google lists several of them, including FAQ rich results, how-to rich results and good page experience, as still present in the bulk data export schema with null values for recent dates. In a chart that reads as a sudden fall to zero on a particular day. Before treating it as a regression, check whether the field itself is one of the deprecated ones.
A report that arrives every Monday whether or not anything happened teaches its reader to ignore it. Three constraints fix that: alert only above a severity floor, only on kinds worth interrupting somebody for, and only when the finding is new.