Setting Up Google Search Console: Domain Property or URL Prefix?

Google Search Console starts with the right property. Here, I explain the difference between a domain property and a URL prefix in an easy-to-understand way.

This article was last updated on June 18, 2026.

info
Written by Saskia Teichmann
on June 18, 2026
Sending
User Review
0 (0 votes)
Comments Rating 0 (0 reviews)
Humorvolles 50er-Jahre-Werbeplakat mit Frau, Schlüssel und zwei Türen als Bild für die Wahl zwischen Domain-Property und URL-Präfix in der Google Search Console.

As of June 2026. Before you submit sitemaps, read indexing reports, or interpret CTR figures, you need a properly set up Google Search Console. The first hurdle is almost always the same: Should I create a domain property or a URL prefix property?

The short answer: If you have access to your domain's DNS settings, the domain property is usually the more robust choice. If you don't have DNS access or only want to check a clearly defined range, a URL prefix property may be useful.

Why Choosing the Right Property Is Important

Search Console always displays data for the selected property. If you only https://www.example.com/ Once you've created it, you won't automatically see all the data for https://example.com/, subdomains, or other protocols. This may sound like a minor technical detail, but it can quickly lead to incorrect conclusions later on.

Especially after relaunches, domain changes, or legacy www/non-www configurations, choosing the right property is no small matter. It determines whether you see your entire website or just a portion of it.

The good news: You won't break anything on your website by doing this. Creating a property in Search Console doesn't affect your ranking or push anything live. For now, it's just the foundation that lets you view data and analyze it effectively later on.

Domain Property: The Big Picture

According to Google, a domain property consists of a domain without a protocol or path. It can include subdomains and different protocols. For most websites, this is usually the best place to start, because it prevents you from accidentally analyzing only one version of your website.

  • Advantage: You'll get a more complete picture of the domain.
  • Disadvantage: You need access to the DNS management interface.
  • Good for: Company websites, blogs, online stores, relaunches, and long-term monitoring.

So for a domain property, you don't enter https:// and do not enter a path. Instead, https://www.example.com/blog/ For example, the domain property would be example.com.

URL prefix: a precise view of an address

A URL prefix property consists of exactly the specified prefix, including the protocol. https://example.com/ is therefore not the same as https://www.example.com/. This is useful if you specifically want to monitor only a certain variant, subdomain, or directory.

  • Advantage: Verification is often easier, even without DNS access.
  • Disadvantage: You will only see the specified area.
  • Good for: Customer scenarios without DNS access, individual subdomains, directories, or tests.

When it comes to URL prefix properties, details are important. If your website is at https://example.com/ is running, then http://example.com/ not the same property. And https://www.example.com/ is also a different address.

Domain property or URL prefix: the decision

If you just want to know where to start, here's how you can decide:

  • Your own website with DNS access: Create a domain property.
  • Client project without DNS access: Create a URL prefix property or request DNS access.
  • Check only one subdomain: Use a URL prefix or an appropriate domain property for this subdomain.
  • Multilingual website with subdirectories: Domain property as an overview; if necessary, additional URL prefix properties for individual language directories.
  • Relaunch or domain migration: Domain property serves as a stable foundation, so you're not just tracking an old URL variant.

My recommendation for WordPress websites: If it's your own website and you have access to DNS, start with the domain property. After that, you can also create a URL prefix property if you want to track a specific variant very closely.

Here's how to set up the property

  1. Open Google Search Console.
  2. In the property selection, click on Add Property.
  3. Select Domain, if you have DNS access, or URL prefix, if you just want to verify a specific address.
  4. Follow the verification method that Google shows you.
  5. After verification, check to make sure you've selected the correct property.

For a domain property, verification is done via a DNS record. This means that Google provides you with a TXT record, and you add it to the location where your DNS zone is managed. This could be with your domain registrar, your hosting provider, or a DNS service like Cloudflare.

For a URL prefix property, you have several options, such as an HTML file, an HTML meta tag, Google Analytics, or Google Tag Manager. Choose the method that you can actually maintain long-term. Google will recheck the verification later. If the proof disappears, you may lose access.

What WordPress and Yoast Have to Do with It

Yoast plays only a minor role in setting up Search Console. The plugin can help you add an HTML meta tag to the head section of your website. This is useful for URL prefix properties. For a domain property, however, you need DNS verification, and that doesn't happen in WordPress.

More importantly, WordPress itself needs to be properly configured: the correct website URL, valid HTTPS, no confusing www/non-www variations, and no old redirect logic lingering somewhere. Search Console shows you data. It doesn't fix your website's structure.

Once the property is set up, the next logical step is the sitemap. For Yoast, the sitemap index is usually below /sitemap_index.xml. I'll show you the actual submission process in the next article: Submit the Yoast Sitemap to Google Search Console.

Common Mistakes

  • Create the incorrect URL variant: http, https, www In URL prefix properties, "www" and "non-www" are different addresses.
  • Delete DNS verification: The TXT record should remain in place permanently, not just until the first successful verification.
  • Evaluate only one specific property: If you use only a URL prefix property, you may overlook subdomains or older versions.
  • Confusing Search Console with Ranking Boost: The tool provides data. It does not automatically improve rankings.
  • Getting nervous too soon: Data does not always appear immediately. Google itself notes that it may take a few days for the data to become visible.

FAQ

Do I have to create http, https, www, and non-www versions separately?

Not the standard approach. The whole point of a domain property is that it gives you a broader view of the domain. Older guides that list four separate properties have often evolved over time. An additional URL prefix property can still be useful if you want to track a specific variant separately.

Can I switch later?

You can add more properties. However, the data remains property-specific. That's why it's worth planning carefully from the start, rather than having to interpret multiple incomplete data views side by side later on.

Do I need Yoast for Search Console verification?

No. Yoast is just one option for setting up the HTML meta tag. DNS verification, an HTML file, and other methods also work. You'll need DNS access for a domain property anyway.

When will I see the first data?

Google begins collecting data for a property as soon as it is added to Search Console. However, the data may not appear immediately. If nothing appears after a few days, first check to make sure you've created the correct property type.

Which property should I create for customers?

If you are responsible for SEO or monitoring on a long-term basis, request DNS access and create a domain property. If that is not possible, use a URL prefix property for the actual website address and document this limitation.

Sources

<span class="castledown-font">Saskia Teichmann</span>

Saskia Teichmann

Saskia Teichmann is a certified AI strategist (MMAI®) and full stack web developer. She supports SMEs and industry in integrating AI, GDPR, the EU AI Regulation and modern web technologies into a future-proof, legally compliant digital strategy.

To put it simply:
As a technical reality translator, she works at the interface of AI, web development and operational reality. She develops AI-supported workflows for companies and agencies - with the aim of ensuring that technology not only impresses in the demo, but also works in everyday life.

Submit a project requestServing coffee

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Sending