A Host-Level Search Console Baseline That Accounts for App Subdomains
Decide deliberately whether your baseline is the domain property or a URL-prefix property for the specific host you work on, and write the choice down with its reason. A domain property aggregates every subdomain that verifies under it — marketing site, docs, app, and any preview or static host that leaked into the index — so a change in one can move a number you attribute to another. For most teams the right baseline is a URL-prefix property for the marketing host, with the domain property kept alongside to catch subdomains you did not know were indexed. Check that second one first: teams are routinely surprised by what is in it.
Domain properties are the default recommendation and they are right for coverage. They are wrong as a baseline for work scoped to one host, because they answer a question about the whole domain while you are trying to measure a site.
What a domain property is actually counting
| Host type | Usually indexed? | Effect on a domain-property baseline |
|---|---|---|
| Marketing site | Yes, intentionally | The thing you meant to measure |
| Docs subdomain | Often, intentionally | Large volume, different intent |
| App subdomain | Sometimes, unintentionally | Branded queries inflating the total |
| Preview or staging host | Should be noindex | Duplicate content if it leaks |
| Static or asset host | Often overlooked | Image and file impressions |
Build the baseline in three steps
First, list every host under the domain that returns a 200 to a crawler — not the list you believe exists, the list the domain property shows you under the page report. Second, decide for each whether it should be indexed at all, and fix the ones that should not be. Third, create a URL-prefix property for the host you work on and use that as the measurement baseline from then on.
The surprise everyone gets
Something is indexed that should not be. Usually a preview or static host that never had a noindex rule, occasionally an app subdomain serving a marketing-shaped landing page. It contributes impressions on branded queries, which makes a domain-property baseline look healthier than the marketing site actually is, and it competes with your real pages for the same terms.
What to record in the baseline
Per host: impressions, clicks, and the date the measurement started. Per host, not summed — the sum is the number that hides the problem. Record the date explicitly because a baseline whose start date nobody remembers cannot be compared against anything later, and that is how a year of work becomes unmeasurable.
Keeping both properties
The domain property is not wasted once you have a prefix property. It is your early warning for hosts appearing in the index that you did not intend — which happens on its own, through a new deployment target or a forgotten branch preview, without anyone doing anything wrong.
FAQ
Should I delete the domain property? — No. Keep it for discovery and use a URL-prefix property for measurement. They answer different questions and the discovery one keeps being useful.
How do I find subdomains I do not know about? — The domain property's page report lists them, and a site: query against the domain surfaces more. Both undercount, so treat what you find as a floor rather than a complete list.
Does an app subdomain hurt the marketing site? — Directly, rarely. Indirectly, it distorts your baseline and can compete for branded queries, which is enough reason to decide deliberately whether it should be indexed.
Put this to work on your own website.
Fenn finds what your customers ask, drafts the articles and site fixes, and measures what ChatGPT, Claude, Gemini, Perplexity and Grok say about you — with every change waiting for your approval.