How to Verify Your Website in Google Search Console
Verification is the gate everything else waits behind. The steps take minutes and are not the useful part. What matters is the choice you make while doing it, because that decides how much of your site the reporting covers and how easily it breaks.
The Method You Choose Has Consequences
Verification looks like a formality, so most people take whichever option appears first and move on. The methods are not equivalent. They differ in how much of your site they cover and in how easily they can be undone by somebody who does not know what they are looking at.
What verification is actually doing. Proving control.
Google will not report on a site to anybody who asks. You demonstrate that you control it, then in return you get the reporting for it. That is the whole transaction.
Why the choice gets made badly. It feels like paperwork.
Nobody approaches this as a decision. It sits between signing in and seeing data, so it gets clicked through in thirty seconds and never revisited until something looks wrong.
What a careless choice produces. A property that reports almost nothing.
That is worse than having no property, because it looks like it is working. A business can read a nearly empty report for a year and conclude the site gets no search traffic.
The two things to get right. Coverage and durability.
How much of the site the property covers, which is block two, plus how likely the verification is to survive the next redesign, which is block four. Everything else is detail.
Domain Against URL Prefix
Properties come in two kinds. One covers a whole domain. The other covers one exact version of an address. They report on different amounts of your site. Choosing the narrow one by accident is the commonest setup mistake we find.
What a domain property covers. Everything on the domain.
Both protocols, the version with the www prefix and the version without it, plus any subdomains. One property, whole picture, however people arrive.
What a prefix property covers. One version, exactly.
The address as you entered it and nothing else. A different protocol or a different prefix is, as far as that property is concerned, a different site entirely.
Which to choose. The domain, nearly always.
It is broader, it survives changes to how the site is served and it removes an entire category of confusion. For a normal business site there is very little argument for the narrow one.
When the narrow one is right. Genuine separation.
Where a subdomain is effectively a separate operation, perhaps a shop or a client portal run by different people, reporting on it separately is reasonable. That is a deliberate choice rather than an accident.
Why the broader one is harder to set up. It has to be the domain.
A domain property is proved at the domain level rather than by adding something to the site, which means somebody needs access to where the domain is managed. That is the only reason most people end up with the narrow option.
Which Version Are You Even Looking At
A business can be verified on one version of its address while the site serves another. The property is perfectly valid, the reporting is technically accurate and it describes something almost nobody visits. This is the single likeliest reason a property looks empty.
How many versions exist. More than people realise.
The same site can be reachable with and without the www prefix, on the secure protocol and the insecure one. Those are four addresses describing one business. A prefix property covers one of them.
How the mismatch happens. A change nobody connected.
The site moves to the secure protocol. Perhaps the prefix changes during a redesign. The property set up years earlier keeps reporting faithfully on the version that no longer serves anything.
What it looks like. Suspiciously quiet.
Very few impressions, almost no queries and an indexing report showing a handful of pages. Businesses interpret that as a search problem rather than a measurement one.
How to check. Compare two things.
Look at what your site resolves to when you type the domain into a browser, then look at exactly what the property covers. If they differ, that is your answer and it takes a minute to find.
What to do about it. Add a domain property.
Rather than repairing the narrow one, verify at domain level and use that from now on. Keep the old property if it holds useful history, since the new one starts from today.
The Methods And How They Break
The available methods change over time, so what follows is the shape of them rather than a definitive list. What is worth knowing is not which exist today. It is which of them quietly stop working.
Something added at the domain level. The durable one.
A record added where the domain is managed, which is how a domain property is proved. It survives redesigns, platform changes and new developers, because none of those touch it.
Something uploaded to the site. Fragile.
A file placed on the server. It works until somebody rebuilds the site, migrates the hosting or tidies up files nobody recognises, at which point the verification vanishes silently.
Something placed in the page code. Equally fragile.
A snippet in the site's markup. A new theme, a template change or a cautious developer removing unexplained code all take it with them.
A connection to another Google product. Convenient and dependent.
Where an existing product is already installed, that connection can prove control. It then depends on that product staying in place and on whoever administers it.
What breaking looks like. Silence, then a warning.
Reporting stops accumulating and the property eventually complains. Businesses that check monthly notice. Businesses that do not can lose a year of data before anybody looks.
What we do. Domain level, plus a second method.
Verify at domain level for durability, then keep a second method in place as a fallback. Two verifications cost nothing and mean a redesign cannot cost you the property.
Verify Before A Migration, Not After
During a site move you need both the old and the new properly verified, in place before anything switches over. Setting up the new one afterwards means the most informative fortnight in the whole project went unrecorded.
Why both. They tell you different things.
The old property shows what was working before, which becomes your comparison. The new one shows what is happening now. Without the first, you have nothing to judge the second against.
What the old property tells you afterwards. Whether redirects took.
Old addresses reported as errors, as redirected or as still indexed all describe how well the move was executed. That information disappears if the old property was never verified.
Why afterwards is too late. No backfill.
Data starts at verification. A property created after launch has nothing from before it, so the question of whether the move cost you anything becomes unanswerable.
What else to do first. Export the old figures.
Take your own record of performance and indexing before the switch. The window in the tool is limited, so the pre-migration picture will eventually vanish from it.
Where the rest of this sits. The migrations material.
Our guidance on site moves owns the sequence, the redirect mapping and what to watch afterwards. This page only owns the part that has to be in place before you start.
Who Should Hold It
Whoever verifies a property owns it. That is decided in the thirty seconds nobody thinks about. It determines whether your search history is yours in three years' time.
The correct arrangement. The business verifies.
On an account the business controls, ideally not the personal address of one member of staff who might leave. Suppliers are then added as users and removed when arrangements change.
What happens otherwise. The data walks out.
An agency that verified the property holds it. Nothing sinister needs to be intended for the outcome to be that the history goes when they do. History cannot be recreated.
Why it matters more here than elsewhere. Verification is the root.
Access can be granted and revoked easily. Verification is the thing underneath it, which is why this is the decision to get right rather than the permissions.
What to ask a supplier. Two questions.
Which account verified the property, then whether the business can be made an owner today. Both answers are informative and a reasonable supplier sorts it the same afternoon.
Where to go next. Build the habit.
A verified property nobody opens achieves nothing. How to use Google Search Console covers the rhythm. Everything sits on the Google Search Console guide.
Whoever
verifies it
is the one
who owns it.
Most properties we inherit are verified on a supplier's account, cover one version of an address and depend on a file somebody could delete during the next redesign. None of that shows up as a problem until the day it matters, which is usually the day you need the history.
How we set one up:
If your property has been quiet for years, check which version of your address it actually covers before assuming anything else.
Every guide.
One tool.
Getting set up and verified, using the reports properly, the performance and indexing data, finding what is broken, finding what is being passed over and turning any of it into work worth doing.
