Domain property vs URL prefix: what each one counts, and how a group of sites should choose

Google's help page, read on 6 November 2026, lets one Search Console account hold 1,000 properties, and not one of them can span two domain endings.

That line costs a single site nothing, and a group has to plan around it.

Google autocomplete finished "google search console domain property vs url prefix" when I typed it the same day, so plenty of people are standing at that same dropdown.

For one site with one owner, the answer is usually Domain, and you can stop reading here.

But a group is not one site, and here is the complication. The cheap choice on a quiet address is also the fragile one, and a cleanup is how you find out.

One limit before the entries. This page will not say which VALORAE address uses which type or which verification method. That list is a map, and a how-to has no reason to print it.

Entry 1: what each type counts

Google's help page on adding a property draws the line in a table.

A URL-prefix property holds only the addresses that start with the exact string you typed, protocol included. So https://example.com/ misses http://example.com/ and misses www.example.com.

A Domain property holds every subdomain and every protocol under that domain. The catch is verification: for an ordinary site, DNS is the only route.

That is the entire technical difference. The rest of this page is what it does to a group.

Entry 2: no property spans a group

Here is the line a group should read twice.

Google treats the ending as part of the property name, and its page says "different suffixes are different properties."

So no single property can hold us. The nine group domains are valoraehq.com, valorae.in, valorae.net, valorae.pro, valorae.space, valorae.live, valorae.blog, valorae.store and valorae.si, and each one needs its own.

Add the three running ventures, Arc, Media and Cast, then NovaTechRay, an alias agency of the group, and tgsidd.com, and you reach 14 addresses. Google allows 1,000 properties in one account, so the limit is attention rather than quota.

The one upcoming line, Shop, sits outside that count. Nothing has dropped there and there is no date.

Entry 3: a site with posts should get Domain

A site with real pages has variants you will not think about until they cost you.

Ours do not even agree on a host. When I requested the blog sites on 6 November 2026, some answered on www and sent the bare domain there with a 308, and others did the reverse.

Register the wrong version as a prefix on a site like that and you get a quiet report that looks like a site nobody searches for.

Google's page names the wrong URL as one reason a property stays empty after verification.

A Domain property cannot make that mistake, because it counts www and bare together.

DNS is the price. You need access to the domain's records, and someone has to keep them tidy.

Entry 4: when a prefix is enough

Some addresses have one job.

If an address serves its page on one host and one protocol, and its www and http versions only redirect, a Domain property mostly adds variants that do nothing.

A prefix also suits one section you want to read separately, such as a /blog/ folder or one subdomain. Google's page suggests extra URL-prefix properties for exactly that, sitting alongside the Domain property.

And the prefix type has cheaper ways in. Google's verification page allows HTML file upload for URL-prefix properties and refuses it for Domain ones.

One upload against one DNS edit. That is the whole saving, and it is small.

Entry 5: the file is the weak point

Cheap verification is debt.

The same Google page says deleting that file loses you verification, and that each file belongs to one specific user.

So a property verified by a file hangs off one person's token, in a folder that ships with every deploy. One tidy-up commit can remove it.

It would not be instant. Search Console rechecks tokens periodically, warns you when one fails, and ends your permissions after a grace period if nothing changes.

But that warning only helps someone who is reading it, and Google does not say how long the grace period runs.

Google's own fix is a second verification method on the same property, so one failure does not end your access. A DNS record works for this, and so does a tag in the page.

Check your own list privately. For each property, ask what proves ownership and what happens if that one thing disappears.

Entry 6: a quiet address can be a healthy one

An empty report looks like a broken property. On an address that points elsewhere it can be the goal.

Google's page on impressions, position and clicks credits that data to the canonical URL, with a caveat that some can land on the actual URL instead.

The group's doors show the group page at their own address and name valoraehq.com as canonical, a setup written up on the group address page.

So a door should report little, and one that fills up with traffic suggests Google picked the door over the group address.

That is the signal I would chase.

So why keep a property on a quiet address at all? For the reports that have nothing to do with traffic.

On 9 October 2026 the Manual actions and Security issues reports both showed no issues on all eight doors. That is the job: somewhere for Google to say a door has a problem.

Entry 7: what neither type sees

Here is the trap in running a group from this screen.

In the 28-day report I read on 6 November 2026, Search Console credited valoraehq.com with 22 impressions for the word valorae. That is a small number, and I am printing it anyway.

VALORAE Arc's record is 500+ videos delivered, and those 10M+ views happen where no website property can look.

Domain or prefix, these reports cover how a domain does in Google results. A clip watched inside an app never touches them.

So if I judged the ventures by these reports alone, I would badly misread Arc.

A property tells you how Google Search treats an address, and it says nothing about whether the business behind that address works.

Entry 8: every token is an owner

Verification also decides who holds the keys.

Google's users and permissions page separates two kinds of owner. A verified owner holds a token on the site or in DNS. A delegated owner was added by another owner and holds none.

The difference shows up when someone leaves.

Take a verified owner off the user list and they may get back in through any token still in place, so the token has to go as well.

And if every verified owner goes, everyone else loses access, while Google's add-a-property page says data collection carries on as long as a user still has the property in their account.

That is why I would give a contractor delegated access and keep tokens with the people who own the business.

Google lets several people verify one property, so two tokens can be fine. DNS does not say whose they are, though, so keep a private list with a name next to each one.

The short version

• Choose Domain for any site with real pages, because it counts www and bare together.
• Use a URL prefix for one section, or for an address whose variants only redirect.
• Give every domain ending its own property, since none can span two.
• Back up file verification with a second method before a cleanup deletes it.
• Read a quiet door as healthy and a busy one as a canonical problem.
• Remove the token when an owner leaves, because the user list alone will not do it.
• Never read a website property as the size of a business.

The full list of official VALORAE addresses starts at valoraehq.com.