Domain vs URL-prefix properties, verification and user permissions

Every Search Console account starts with the same question: which property should I add? The choice affects what data you see, how verification works, and how easily you can share access with colleagues, agencies and tools. Getting it wrong is common and mostly harmless, but it leads to confusing numbers ("why do we have half the clicks we expected?") and, occasionally, to lockouts when a verification tag disappears.

The two property types

	Domain property	URL-prefix property
Example	example.com	https://www.example.com/ or https://www.example.com/blog/
Covers	All subdomains (www, shop, blog…), both http and https, every path	Only URLs that start with that exact prefix, including protocol and host
Verification	DNS record only	Several methods: HTML file, meta tag, analytics or tag manager, DNS
Best for	The complete picture of a site	Separate views of sections, subdomains or language folders

For most sites the answer is: create a Domain property as the main view, and add URL-prefix properties where a narrower view is useful. They can coexist; data is not split between them, each simply shows the URLs within its scope.

Why the Domain property should be the default

• Nothing is missed. Traffic to example.com, www.example.com, shop.example.com and old http:// URLs all appear together. Prefix properties silently exclude anything outside their exact prefix, which is the most common reason numbers look too low.
• Migrations are easier to follow. When you move from http to https or from www to non-www, a Domain property shows the whole transition in one place.
• Verification is robust. A DNS record is rarely removed by accident, unlike a meta tag that disappears in a redesign.

The only practical obstacle is DNS access. If you cannot add a TXT record (some hosted platforms make this hard), start with a URL-prefix property for your main host and add the Domain property when you can.

When URL-prefix properties help

• Sections: a property for https://example.com/blog/ gives the content team a view of blog performance without filters, and its own Page indexing report.
• Language or country folders: /de/, /fr/ as separate properties make international reporting simpler; see international site structure.
• Subdomains run by different teams: help centres, shops, regional sites.
• Tools and partners that only need access to part of the site.
• Large sites: each property has its own row limits in the interface and API, so several prefix properties can expose more detail than one Domain property; see data limits.

Verification methods

Method	Works for	Notes
DNS TXT record	Domain and URL-prefix	Most robust. Added at your DNS provider; survives site rebuilds
HTML file upload	URL-prefix	A file at the root; can be deleted in deployments
HTML meta tag	URL-prefix	Easy with CMS plugins; disappears if the theme or plugin changes
Google Analytics / Tag Manager	URL-prefix	Uses existing tracking code; breaks if tracking is changed

Verification is checked periodically. If the token disappears, the verified owner loses ownership after a grace period. Two habits prevent surprises: verify with DNS where possible, and keep at least two verified owners (for example, the business owner's account and a company-controlled admin account), each with their own token.

Users and permissions

Search Console has owners and users:

• Verified owners proved ownership with their own token. They can do everything, including adding and removing other owners and users.
• Delegated owners were added by a verified owner. They have owner rights without their own token, and lose them if the verified owner who added them is removed.
• Full users can view nearly all data and perform some actions, such as submitting sitemaps and requesting indexing.
• Restricted users can view most data but cannot take actions or change settings.

Practical rules:

1. Least privilege. Reporting tools and most agency staff need Restricted access. Developers who submit sitemaps or request indexing need Full. Very few people need to be owners.
2. The business keeps ownership. Agencies and freelancers should be users, not the only owners. When a relationship ends, the business must not depend on the agency to keep access.
3. Review users twice a year. Remove former staff, old agencies and tools no longer used.
4. Service accounts for tools. Tools that pull data automatically often use a service account email; add it as a Restricted user on the property they need.

DeskSEO, for example, connects to Search Console through a service account that you add as a Restricted user, after you verify in DeskSEO that you manage the site. It looks for a Domain property first, then the https URL-prefix properties. The step-by-step version is on the Search Console connection page.

Adding a property later does not lose history

A common worry is that adding a Domain property late means starting from zero. In practice, Search Console generally shows performance data for a newly added property going back through its normal history window, because Google collects search data about the site whether or not anyone has verified it. Some reports, such as indexing details, may take a little time to fill in. So there is no reason to delay: if you only have a URL-prefix property today, add the Domain property now and compare the two.

Agencies managing many properties

For agencies and freelancers, property management becomes an operational task. A few practices keep it under control:

• Ask clients to add a dedicated agency account (not a personal address) as a Full or Restricted user, depending on the work. Staff changes then do not affect client access.
• Keep a register of client properties, their type, who the verified owners are on the client side, and when access was last reviewed.
• Never become the only owner of a client property. If a client has no verified owner, help them set one up via DNS before the engagement starts.
• Remove your access at the end of an engagement, or ask the client to, and note the date. It is good practice and avoids awkward questions later.

The client onboarding guide covers the rest of the first-day access list.

Do the same in Bing

Bing Webmaster Tools offers similar data for Bing, and its search index also feeds other products. It can import sites and verification directly from Search Console, which takes a minute once your Google properties are set up. The same principles apply: verify robustly, keep the business as owner, and give others the access they need.

Common problems and fixes

Problem	Likely cause	Fix
Numbers far lower than analytics suggests	Using a URL-prefix property that excludes a host or protocol	Add a Domain property
"You don't have access to this property"	Verification token removed, or delegated owner removed	Re-verify with DNS; ask another owner to re-add you
No "Users and permissions" option	You are a user, not an owner	Ask an owner to add the new user
Two properties disagree on totals	Different scopes	Compare like for like; use the Domain property for totals
Agency left and took access	The business was never a verified owner	Verify the business account via DNS, then remove old owners

Setting up a new site properly

1. Add a Domain property and verify it with a DNS TXT record, using a company-controlled Google account.
2. Add a second verified owner (another person or a shared admin account).
3. Add URL-prefix properties for important sections, subdomains or language folders.
4. Submit the XML sitemap in the Domain property; see XML sitemaps.
5. Add agencies, staff and tools with the least access they need, and record who has what.
6. Set a reminder to review users every six months, and note in your records which verification method each owner uses.

Then the reports are ready to use: the Performance report for traffic, the Page indexing report for coverage.