How to set up Google Search Console: verification, sitemaps and the first checks

Set up Search Console with a Google account the business controls. Choose the right property, prove ownership and submit the live sitemap. Verification gives you access to the tools. It doesn't make Google index or rank anything.

Search Console is free. You don't need an agency, GA4 or a Google Ads account to use it. Adding a property won't lift rankings on its own either. Once it's running, our guide to reading and acting on Search Console reports covers what the data means.

Check access before you create anything

Start by finding out whether a property already exists. A past developer or agency may have set one up years ago. If someone has shared it with you, it appears in the property selector. If not, ask the current owner, or verify control yourself.

Don't create a new property with a different scope just to get around an access problem. You'll end up with overlapping properties and nobody sure which one is right.

Use a named Google account that belongs to the business. Then set it up properly:

• give it a recovery phone or email the business controls

• turn on two step verification

• add people as users, and never share the password

A common mistake is a developer verifying the site under their own Gmail. It works until they move on. Then the business has to prove ownership all over again.

Record who controls each service before you touch anything. The domain registrar, the DNS service, the web host and the email provider can be four different companies. Here's an example access map:

Swap in the real suppliers for each layer. Where a layer is shared, name the business person who can still get in if the supplier disappears. If nobody knows who controls DNS, ask whoever manages the domain before changing anything.

Choose the right property

Search Console offers two kinds of website property. They cover different amounts of the site:

For a Domain property, enter the bare domain, such as "example.com.au". Leave out "https://", "www" and any path. Google's page on adding a property explains the format.

A URL prefix property needs the full address, including the protocol and a trailing slash, such as "https://www.example.com.au/". Only URLs that start with exactly that prefix are included.

A Domain property takes in every subdomain, including a staging subdomain. It doesn't filter unfinished content out of the reports. Running both types on purpose is fine. Overlapping data isn't extra traffic, though.

Search Console also offers platform properties for YouTube, Instagram, TikTok and X profiles. A YouTube channel property isn't your website, so keep the two apart. The reports guide linked at the top covers what those properties report.

Verify through the right DNS provider

DNS verification works for both property types. It's the only route for a Domain property. Treat it as a controlled change to a live system:

1. Find the DNS service that actually answers for the domain. Its nameservers decide that. If they point away from the registrar, edits at the registrar do nothing.

2. In Search Console, choose the DNS method and copy the record Google issues. Note its type, host and value.

3. Add that record without touching anything else in the zone. The zone is the list of records for your domain.

4. Check the record shows up in public DNS before you click Verify.

5. Verify, then leave the record in place.

Here's a typical trap. The domain is registered with one Australian company. Its nameservers point to Cloudflare, though. So a record added at the registrar never goes live.

Look up the domain's NS (nameserver) records first. Then edit the zone at whichever service they name.

TXT is the common record type. Some flows use a CNAME instead, with a different name and target. Never turn a CNAME instruction into a guessed TXT record.

The host field varies by provider. Some want "@", some want it blank and some want the full name. Follow your provider's own help for that field. Here's what the settings look like, as a teaching example:

Type: TXT
Host: USE_YOUR_PROVIDER_REQUIRED_HOST
Value: google-site-verification=REPLACE_WITH_YOUR_OWN_TOKEN

Copy your own generated value. The placeholder above won't verify anything. And keep your real token out of public screenshots.

Leave everything else in the zone alone, including:

• the records that point to your website

• mail records, such as MX and SPF

• other services' verification records

Changing nameservers or mail settings is never part of verifying Search Console.

Before clicking Verify, check the record is live using your provider's tools or Google's Admin Toolbox Dig. If the value isn't showing, fix the zone, host or saved value first. Google says manually added records can take up to two or three days to be served. So don't promise anyone a few minutes.

Google rechecks verification over time, according to its page on verifying site ownership. So the record stays after success. If you change DNS providers, carry the verification records across in the migration.

A second authorised person can verify with their own token. Don't overwrite another valid owner's token. A homepage tag doesn't back up a Domain property either.

A private site can still be verified

DNS proves control of the domain. It doesn't need the pages to be public. So a business can verify while a new site stays behind a password.

Don't lift a password, remove a noindex tag or publish unfinished pages just to pass an HTML method. Schedule the indexing checks for launch day instead. Our website launch checklist covers that moment. Once the site is live, its public pages must be crawlable.

Use another method or your platform's route

URL prefix properties can use four more methods. Pick one the business can maintain. Don't install a new analytics or tag tool just to avoid a DNS step.

The HTML tag suits a site where you control the theme. Analytics or Tag Manager suit a site that already runs them with the right permissions. DNS still outlasts all of them.

The Analytics and Tag Manager methods need more than a tag on the page. You must sign in with the same Google account. That account also needs the right permission.

The HTML tag goes inside the homepage's head section. It looks like this, with your own token in place of the placeholder:

<meta name="google-site-verification" content="REPLACE_WITH_YOUR_OWN_TOKEN">

Some platforms have a field labelled verification ID. That field wants only the code inside the content quotes, not the whole tag. Keep straight quotes when you paste a full tag. Curly quotes break it.

Platform routes

Menu names change, so check the platform's current help before you start. These are the usual routes:

• WordPress: Use DNS, or Google's Site Kit plugin. A WordPress administrator signs in with the business's Google account and follows the prompts. Then check Site Kit's settings show the intended property. Our guide to WordPress access and security covers admin hygiene.

• Shopify: Use the HTML tag. In the admin, open Online Store, Themes, then Edit code. Paste the full tag on a blank line below the opening head tag in "theme.liquid". Shopify's sitemap and verification help has the detail.

• Webflow: Open the site's Settings, then the SEO tab. Paste only the ID from Google's tag into the Google site verification field. Save, publish to the production domain, then verify. Webflow's verification help shows the field.

• Squarespace: Open Analytics, then Search keywords, and connect the business's Google account. Or use DNS. Reconnect if the primary domain changes.

• Wix: The SEO Setup Checklist connects Google for you. Wix's connection help says it needs a Premium plan and a connected domain. Only the site owner or an admin collaborator can do it.

Two catches are worth knowing. A Shopify theme change can drop a tag you pasted into the old theme. And Shopify's private mode blocks Google. Shopify suggests turning private mode off to verify. If the shop isn't ready, use DNS or wait for launch.

Set access and protect ownership

Search Console has two kinds of owner. A verified owner proved control with their own token. A delegated owner was given ownership by another owner. Both have broad powers. But delegated ownership isn't independent proof of control.

That matters when the business owner gets added, because an invitation doesn't make them a verified owner. Have the business's own account complete its own verification. Keep at least one verified owner and a working recovery path. A second named person helps with continuity.

Add people under Settings, then Users and permissions. Only owners can add users. Give each person the least access their job needs. Full users can take some consequential actions, so think before granting it.

Search Console access doesn't extend to DNS, the CMS, GA4 or Tag Manager. Each of those has its own permissions to manage.

If a past supplier won't hand over access

You don't need their cooperation to get back in. Verify control yourself, usually through DNS. The business account then becomes a verified owner.

Then review the user list and remove access that's no longer needed. Ask the old supplier to remove their tokens. Where you control the location, remove them yourself.

When someone leaves

Removing a former owner from the user list isn't enough. Google's page on owners, users and permissions explains why. Their verification token stays behind. That lets them verify again and get back in. Work through the handover in order:

Google lists leftover tokens under Unused ownership tokens. Remove each one from where it lives, such as a DNS record or a homepage tag. Some tokens also verify other Google services, so check before deleting.

Keep the tokens of legitimate owners. Never delete every Google record in the zone, or remove the last verified owner. Then test access from the business account. Note what changed and when, because the next person will need it.

Ownership is one of the things we check in a website audit. Our audit sample is 100 website audits from May 2023 to September 2026. In about 1 in 4 audits, the business couldn't get owner access to its own property.

Find and submit the sitemap

Your platform or SEO plugin creates the sitemap. Find the real one before you submit anything. Common addresses include "/sitemap.xml", "/sitemap_index.xml" and WordPress's own "/wp-sitemap.xml". These are alternatives to check, not three files every site needs.

WordPress has generated "/wp-sitemap.xml" since version 5.5, as the core team's announcement explains. SEO plugins often replace it with their own.

Open the sitemap address in a browser. Check it's a sitemap or sitemap index for the live site. Then sample some of its URLs:

• the production host and https, not staging

• the canonical (main) version of each page

• no redirects, private pages or unintended noindex URLs

In Search Console, open Sitemaps and enter the address. A URL prefix property may already show the prefix in the field, so don't type it twice. In a Domain property, enter the sitemap's full address. Check the submitted address and the status that comes back.

A Success status means Google can read the file. Google's Sitemaps report help says listed URLs are only queued for crawling. Nothing guarantees indexing. Removing a sitemap from the report won't remove pages from Google either.

A big site may have a sitemap index. That's a file listing several sitemaps. Submit the index once rather than each file.

If an integration already submitted the right sitemap, just confirm it. Then record what you checked:

Run the first checks

Four checks turn a verified property into a useful one. Do them in the first week:

Google says data collection starts when someone first adds the property, even before verification. Data usually appears within a few days. So an empty report on day one isn't a failed setup. If the property already existed, a new owner sees the data collected since it was first added.

Treat a manual action or security warning as an investigation, not a box to tick. Make sure a responsible person gets the account's emails.

The first week also catches the classic launch mistakes. Watch for these:

• a noindex tag (an instruction not to index the page) left over from staging

• a sitemap listing the staging host or http addresses

• canonical tags pointing at the staging site

• a robots.txt rule blocking the whole site from crawlers

Keep setup acceptance to what you control. That's the right property, authorised access, valid verification, an accessible sitemap and recorded findings. Indexing and search performance come later. They're separate outcomes, so don't mark a setup failed because a new site has no clicks yet.

For a private site that hasn't launched, record the indexing checks as pending launch. Don't remove its protection to tick them off.

Link Search Console to GA4

Linking is optional. It makes Search Console's search reports available inside Analytics. It doesn't install GA4, set up key events or prove forms are measured properly.

Check two things first. The GA4 property and its web data stream must cover the same website. And the person linking needs the Editor role in GA4 plus verified owner status in Search Console. Google's Search Console integration help sets out both. Delegated ownership isn't enough.

The steps are short:

That last step trips people up. The report collection is unpublished by default. Until someone publishes it, the reports stay hidden.

Each web stream links to one Search Console property. Each property links to one stream too. Check for an existing link before replacing it. To change the stream, remove the link and create a new one.

Data starts from the later of the stream's creation or the verification date. Don't expect clicks and sessions to match. Our guide to setting up and using GA4 covers the analytics side.

Optionally import the site into Bing

Bing is a separate search engine with its own webmaster tools. Once the Google setup is stable, you can import it rather than verifying again.

In Bing Webmaster Tools, open My Sites and choose Import. Sign in with the business's Google account, allow access and select only the intended sites. Their sitemaps come across too. Bing's import announcement explains the flow.

Bing keeps checking ownership by syncing with Search Console. If that Google access is revoked, reconnect or verify another way. Manual verification avoids the dependency altogether. Importing doesn't promise indexing or rankings. Nor does it promise citations in Copilot.

Troubleshoot the setup

Most failures come down to the wrong place, the wrong account or the wrong value. For DNS, work through the checks in order:

A visible token isn't proof on its own. It has to be the one issued to this account, for this property. For everything else, match the symptom to the next check:

Don't keep adding duplicate properties when data looks thin. And don't wait forever if the record is plainly wrong or the site returns an error. Fix the cause first.

Moves are the riskiest moment for verification. A new theme, host or DNS provider can drop a token without warning. Our guide to preserving SEO during a website move covers token continuity in a migration.

Record the setup and hand it over

A setup isn't finished until someone else could pick it up. Record the essentials somewhere secure:

Keep passwords, recovery codes and verification tokens out of the handover document. Store them in the business's password manager instead.

Set one review rhythm and stick to it. A monthly review is a sensible default for a small business. That reports guide, linked above, covers what to check each time.

What we recommend at Elev8d

FAQ

Next steps

Written by Ajay K.Co-founder, Elev8d

Ajay is the co-founder of Elev8d and writes most of what you will read here. Psychology grad turned marketer, which is a fancy way of saying he cares about why people click, not just where things rank. Every guide is written in plain English for Australian businesses, tested on real campaigns before it earns a spot on this site.