Search Console URL-prefix vs domain property

The two scopes

Google Search Console offers two property types that collect different URLs into one report:

• Domain property: you add example.com (no www, no scheme). It covers every host, subdomain and protocol under that domain, including http, https, www, m., and any other subdomain. It is verified with a DNS record.
• URL-prefix property: you add a complete URL prefix, for example https://www.example.com/. It includes exactly the URLs that start with that prefix, so it follows https://www.example.com/ and its subpaths, but nothing on http://, nothing bare, and nothing on m.example.com.

As of August 2026 both types remain fully supported and both are common. Neither is retired or on a public deprecation list. The nuance below is about coverage, not about which is "better" today.

The data differences that matter

Two practical consequences:

1. A domain property silently merges www and non-www, http and https into one set of numbers. If you actually want to separate https://example.com from https://www.example.com, a URL-prefix property cannot do it in one; conversely a URL-prefix property on https://example.com does not show any of the https://www traffic.
2. Verification friction flips the other way. A domain property needs DNS access (one TXT record at the registrar). A URL-prefix property verifies through an HTML file or meta tag, so it works without touching DNS, which matters when a client controls the registrar.

When each one is right

• Domain property is the default for most commercial sites wanting one authoritative number. It holds up across host moves and www/https migrations without re-verification, and it avoids the "why does my prefix show zero data" trap.
• URL-prefix property is right when you report on a single subfolder (example.com/es/), track http and https separately for a migration study, or manage a portfolio where each client registers only a prefix. If you need multiple hosts and protocols, create a separate URL-prefix property for each one, so you can both compare them and merge the sums.
• If you already set up a domain property and now see nothing, it is almost always a verification or a scope mismatch, not a data bug. Re-check that the property you added is actually example.com and that the DNS TXT record is live at the right name. A domain property includes www and apex traffic together, so do not expect (or add) a second www difference to appear: the numbers are one set by design, and splitting them requires URL-prefix properties.

The operational accuracy note

• Never import a sitemap made for the domain into a URL-prefix property that excludes its longest prefix. The Sitemaps report applies within the property's scope; a URL-prefix property on https://www will not list https://example.com/... sitemap URLs.
• URL Inspection and Performance disagrees across properties. The same URL inspected in the www property and the bare property can show different coverage if the site splits www/non-www. That is scope, not a data bug.
• Migrating properties: the current way to change the type is to create the new property, keep the old for history, and use the "Change of address" flow. The change of address article covers the domain move; this article only covers the property choice.

A short decision flow

1. Does the site use only one host/protocol publicly? Domain property.
2. Do you need to isolate a subfolder, one protocol, or a hosted subdomain in its own report? URL-prefix per that scope.
3. Do you want a combined picture today and per-host granularity tomorrow? Start domain-first, then add URL-prefixes for the segments you care about.

The other reports (index coverage, performance, enhancements) are the same whatever property type you chose; the difference is which URLs the property includes first.