Search Console Domain Property vs URL Prefix: Which Should You Use?

In other words, this is not an either-or choice. You use both types together. The domain property shows you the full picture, while a URL-prefix property lets you watch one protocol, one subdomain or one folder on its own. In this guide, Talha Aslan and team walk you through the setup step by step. If you are new to the tool, start with our guide on what Google Search Console is and how to use it.

What exactly does a domain property cover?

According to Google's help page on adding a property, a domain property covers the root domain and all of its subdomains across protocols. So a property for example.com combines http, https and ftp URLs, subdomains such as www and m, and deeper levels, all in the same report.

• http://example.com and https://example.com appear in the same property.
• Subdomains such as www.example.com, m.example.com and blog.example.com are included.
• Every folder and subpath falls inside the scope.
• A different public suffix stays outside; example.com does not include example.org.

Google also says you should not add a www prefix when you create the property. That is because it already includes both the www and the non-www version. Therefore, you enter the name as plain example.com, with no protocol and no path.

Why do you still need a URL-prefix property?

A URL-prefix property covers only the addresses that start with the exact prefix you enter, and the prefix includes the protocol. For example, the property https://example.com/ does not see http://example.com/ or https://www.example.com/. That narrow scope looks like a limit at first. In practice, it is often exactly what you need.

Specifically, a URL-prefix property helps in these situations:

• A team owns only the blog folder and should not see the rest of the site.
• You run a multilingual site and want separate reports for /en/ and /de/.
• DNS access is out of reach, and you need to verify with an HTML file or tag.
• You want to track an app on a subdomain apart from the main site.

On the other hand, Google also suggests a page filter in the Performance report to split domain property data by subdomain, protocol or path. So a URL-prefix property is not mandatory. Instead, it is a tool for structure and access control.

How do the two property types compare side by side?

The table below summarizes the official comparison from the Search Console Help page in plain language. That way, you can see at a glance which property handles which job.

The takeaway is simple. The first type wins on coverage, and the second wins on flexibility. That is why we treat them as partners, not rivals.

How do you verify a domain property with DNS, step by step?

Google's site ownership verification page states that only the domain name provider method, a DNS record, works for this property type. Depending on your setup, Search Console gives you either a TXT record or a CNAME record. The process looks like this:

1. Open the add property screen and type plain example.com into the domain option.
2. Copy the verification record shown on screen. Most of the time it is a TXT record.
3. Log in to the DNS management panel for your domain and add a new TXT record.
4. Leave the host field blank, or enter @.
5. Save the record, then return to Search Console and click verify.
6. If verification fails, try again after a day or two.

With some providers, Google can add the record for you. With others, you enter it by hand. To check whether the record is live, you can look up TXT records with our DNS lookup tool.

Why does DNS verification sometimes fail at first?

Google explains that records you add manually can take two or three days to appear. So if the first attempt fails, there is no reason to panic. Keep the record in place, wait and retry. Still, a few quick checks before you wait can save time.

• You may have added the record to the wrong domain, for example a subdomain instead of the root.
• You may have typed the full domain into the host field, and some panels append it a second time.
• A stray space may have slipped in when you copied the value.
• Your name servers may point to another service, so you edit records in the wrong panel.

The last case is the one we meet most often in the field. For instance, if you bought the domain from one company and pointed its name servers to a CDN, you need to add the record in that service's DNS screen. Google also points to the Google Admin Toolbox to see which records your provider actually serves.

What happens to a domain property if you delete the verification record?

Google clearly asks you to keep the record after successful verification. Search Console checks the token periodically. If it can no longer find it, you receive a notice; if you do not fix the issue, your permissions expire after a grace period.

So take care during DNS cleanups. Example scenario: a site owner switches email providers and bulk deletes old TXT records, and the Google record goes with them. A few days later, the property shows an access warning. The fix is simple: add the record back and verify again. However, if nobody notices, the whole team can lose access to the reports.

Moreover, Google notes that if all verified owners lose access, every user of the property loses access too. Therefore, we suggest you label the record as "do not touch" in your notes and share that note with everyone who edits DNS.

Which methods can you use to verify a URL-prefix property?

You have more options here. The official page lists an HTML file upload, an HTML tag, the Google Analytics tracking code, the Google Tag Manager container snippet and a DNS record. For sites that Google hosts, such as Google Sites or Blogger, verification happens on its own when you sign in with the same account.

1. HTML file: upload the file Google gives you to the site root and leave it there.
2. HTML tag: add a meta tag to the head section of your homepage.
3. Google Analytics: use your existing tracking code if your account has enough access.
4. Tag Manager: verify through the container snippet with the right permission.
5. DNS: add a record, just as you would for the domain-wide type.

One more detail matters. According to Google, when you verify a URL-prefix property with DNS, the matching domain property also gets verified automatically. If you choose the tag method, our meta tag generator helps you understand how the head section fits together.

Which verification method lasts the longest?

Durability depends on how much site changes affect the method. An HTML tag or file can easily disappear during a theme change or a redesign. Likewise, the Analytics and Tag Manager methods can break when someone removes the code or changes account access. A DNS record, by contrast, lives outside your site code, so a redesign does not touch it.

Google also recommends adding more than one verification method, so access survives if one breaks. That is why we usually set up three layers:

• Main layer: a DNS record, which the domain-wide type needs anyway.
• Backup layer: an HTML file or tag on the URL-prefix properties.
• Record layer: a short document that says which method sits with whom.

For example, when a site moves to a new content management system, the tag may vanish, but the DNS record stays. As a result, your reports keep running without a gap.

How should you organize several properties for one site?

Google says that with URL-prefix properties you add a separate property for each protocol and each subdomain, and you can also add properties for subsections. An account can hold up to 1,000 properties, so the limit rarely matters for a typical site. The real problem is disorder.

As an example scenario, take a corporate site in three languages. Here is the structure we suggest:

1. example.com as the domain-wide property: the master view of the whole site.
2. https://www.example.com/ as a URL-prefix property: the preferred live version.
3. https://www.example.com/en/ and https://www.example.com/de/: separate views for language teams.
4. https://shop.example.com/: a property for the store subdomain.

Google also notes that child properties you create after the parent passes verification inherit the parent's method automatically. So you do not need to verify every folder property one by one. As the list grows, watch your naming; otherwise, the risk of acting on the wrong property rises.

How should you assign owners and user permissions?

Google's page on managing owners, users and permissions defines three levels. An owner has full control, adds users and changes settings. A full user sees all data, submits sitemaps and uses URL Inspection, but cannot add users. A restricted user mostly has view access.

Only owners can add users, and Google does not support email groups. Also, remember to remove people who leave the team; our guide on removing an old owner or user covers that.

Who should own the property when you work with an agency or consultant?

Our view is clear. Verified ownership should always stay with the business's own account. For the consultant, a delegated owner or full user role is enough, depending on the scope of work. That way, your access to the data never stops when the engagement ends.

Why does this matter? Because problems start when the person tied to the token leaves. Google says that if the only verified owner leaves, someone must verify again to regain access. That requires DNS or file access, and in a busy week it can take days.

When Talha Aslan and team start work on a new site as part of our SEO consulting, the first job is to clean up the property structure and the ownership chain. Then we put in writing, together with the client, who holds which role. In short, the data is yours; we work with the access you grant.

How should you manage a domain property after a site migration?

When you change domains, you need separate properties for the old and the new domain. According to Google's Change of Address tool page, you must own both properties and use the same Google account. In addition, the tool does not move subdomains automatically; it needs a separate request for each www and non-www variant.

1. Create and verify the domain-wide property for the new domain before the move.
2. Do not delete the old domain's properties; you will need them for comparison.
3. Set up 301 redirects from old pages to their new counterparts.
4. Start the Change of Address tool from the old property.
5. Keep the redirects for at least 180 days, as Google advises, and longer if traffic continues.

Google says the tool is not meant for an HTTP to HTTPS change or a www to non-www switch. For the full checklist, see our website migration SEO checklist. You can test your redirects with the redirect checker.

Do you need a new property when you move to HTTPS?

Not if you use the domain-wide type. It already covers http and https together, so you see data from before and after the switch in the same report. That is one of its most practical benefits.

However, things change if you rely only on URL-prefix properties. The property http://example.com/ does not see https URLs, so you have to add a separate one for the https version. Otherwise, your reports can paint a misleading picture after the switch. Traffic has not dropped; it has simply moved to another property.

Example scenario: a business has watched an http URL-prefix property for years. After the HTTPS move, clicks fall close to zero and the team raises the alarm. The issue is not a loss but the wrong property. To fix it, you add the domain-wide property and compare both periods in one place. Data in a new property can stay empty for a while, which is normal; our post on the processing data message explains why.

How can you track subdomains separately inside a domain property?

Because this property type merges everything, detail can get lost. For example, a support subdomain can inflate the main site's clicks. In that case, Google suggests two routes: use a page filter in the Performance report, or create a URL-prefix property for each segment.

• Page filter: ideal for a quick look; you isolate the subdomain with a "URL contains" condition.
• Separate URL-prefix property: gives lasting tracking, its own user access and section reports.
• Mixed approach: the master view stays in the domain-wide property, team views live in URL-prefix ones.

In our experience, a separate property gives cleaner results whenever a subdomain has its own team. It also makes indexing problems easier to study by section; our guide on finding unindexed pages helps here.

How does your property choice change Performance report numbers?

Seeing different click counts for the same site in two properties is completely normal. Each property counts only the addresses inside its own scope. For instance, https://www.example.com/ leaves out clicks on the m subdomain or on the non-www version. The domain-wide property adds them all up.

This gap often causes confusion in reporting meetings. One person brings numbers from one property, another from a different one, and both are right. So we recommend you always state which property a report uses.

• For management reports, pick the domain-wide property as the single source.
• For section reports, use the matching URL-prefix property and name it in the table.
• Do not switch properties between periods; otherwise, a scope gap looks like a real change.

Also, if you see a sudden drop, check the property scope first. To tell a real loss from a scope gap, our guide on diagnosing a traffic drop walks you through it.

Which property should receive your sitemap?

Submit the sitemap to a property that covers every address in it. The domain-wide type includes all subdomains, so it is the easiest choice in most cases. On the other hand, a sitemap sent to a URL-prefix property can cause trouble if it lists URLs outside that prefix.

Example scenario: a team submits the full site map to the https://www.example.com/blog/ property. Store and company pages in the file sit outside that prefix, so the report shows unexpected warnings. To fix it, you move the sitemap to the broader property or build a separate one for the blog.

1. Check the protocol and subdomain of the URLs in the sitemap.
2. Pick the property that fully covers those URLs.
3. Submit it and watch the status column for a few days.

If you see a similar warning, our post on the sitemap URL not allowed error covers it in depth.

What property setup works for multilingual sites?

On multilingual sites, the language structure drives the property plan. If languages live in folders such as /en/ and /de/, the domain-wide property already collects every language. Then you open a URL-prefix property for each language team's folder. As a result, each team sees only the data it owns.

If languages sit on subdomains, such as en.example.com, the logic is the same, but the property names change. If you use separate country domains, you need a separate domain-wide property for each one. That is because, according to Google, the example.com property does not include example.de; the suffix is part of the name.

Our advice is to open no property until the plan is on paper. Write down which language lives in which property, who gets which role, and where each sitemap goes. That single page becomes the document that saves the most time as the team grows.

What should you check in the first week after setup?

Verification is only the start. The first week is the best time to confirm that the setup really works, because data in a new property starts to fill within days and mistakes show up then. We follow this short list on new setups:

1. Is data arriving in the Performance report, and does the date range make sense?
2. Is the sitemap in the right property with a success status?
3. Does the users and permissions screen list only the right people?
4. Is the verification record still live in DNS?
5. Does URL Inspection return the expected result for the homepage?

Next, compare old properties with the new domain-wide one for a few days. Numbers will differ because of scope. Understand the reason once and write it down; that prevents false alarms later. For example, if clicks are higher in the broader property, the m subdomain or the non-www version is the likely cause.

Finally, share the document with your property plan and verification methods with the team. That way, anyone who edits DNS knows what to leave alone. A few minutes of checks in week one prevent months of misreading.

Common mistakes we see in property setups

Most mistakes we find in the field are small, but their effects are large. The list below shows the first points we check in an audit:

1. Typing www or https into the domain-wide property name; it should be plain example.com.
2. The only verified owner is a former employee or a previous agency.
3. Deleting the verification record during a DNS cleanup.
4. Continuing to watch an old http property after the HTTPS move.
5. Submitting the sitemap to the wrong property.
6. Giving everyone owner rights when a full or restricted role is enough.

In addition, Google says you can re-add a removed property without verification only if it still has at least one verified owner. So think twice before you delete one. Put simply, order begins at setup, and cleaning up later always costs more.

How often should you audit your property structure?

A Search Console setup is not something you build once and forget. Staff change, agencies change and DNS providers change. That is why we suggest a short, regular check routine. The intervals below are a field-based starting range, not a rule.

Adapt the schedule to your business. For instance, a company with frequent staff turnover should review users monthly. Meanwhile, a small site whose DNS rarely changes can often get by with a six-month review. What matters is that one person owns the check and logs the result in a short note.

The whole audit takes about half an hour, yet skipping it can cost days during a migration or a crisis.

Should you do this setup yourself or hand it to a specialist?

If you have DNS access and a single site, you can do the setup yourself with this guide. The steps are not hard; the part that needs care is the ownership chain and the user roles. Still, if you have several subdomains, language folders or an upcoming migration, one mistake can lead to months of decisions on the wrong data.

Let us be clear: a correct property structure does not bring rankings on its own, and nobody can guarantee rankings. That said, without correct data you cannot make correct SEO decisions. If you want us to audit your properties, plan a migration or tidy up user permissions, you can request a quote on our SEO consulting page. We fix the issue on your site and then track it with regular reports.

To sum up, the domain property is the foundation for the full view, and URL-prefix properties add order by section and team. Set them up together, keep ownership in the company account, and you can rely on your Search Console data for years.

Core guide: What Is Digital Marketing? Its types, examples and how it is done, on one page with an interactive film that travels through the brain.