Search console verification by HTML file failed because my host redirected .html

What I expected

When I launched this site in September, one of the first jobs was registering it with Google Search Console, so the search engine would know the site existed and I could submit a sitemap.

The console offers several ways to prove you own a site. The one that looked simplest was the HTML file: download a small file from the console, put it in the site’s public folder, deploy, and press Verify. The site is a static build, the file was in the build output, and the deploy went through. I expected the check to pass on the first try.

What actually happened

It did not pass. The file was there, and the deploy had worked. But the address the console asked for, ending in .html, did not answer with the file. The host answered with a redirect to the same address without .html, using status 308.

Here is how the setup went, from the site’s progress log:

When	Step	Result
Launch day	Verify with the uploaded HTML file	Did not pass: the .html address redirects (308)
Launch day	Verify with the HTML meta tag	Ownership confirmed; sitemap submitted
Right after submitting	Sitemap status	“Couldn’t fetch” (normal just after submission; left alone)
Two days later	Sitemap status	Success, 21 URLs discovered
Three days later	A second search engine’s webmaster tool	Verified once its meta tag was deployed

Why

Two reasonable rules met each other.

The host’s rule. Many static hosts serve “clean URLs”: a page built as /contact.html is served at /contact, and a request for the .html version is redirected there. The documentation for my host says this directly: it redirects HTML pages to their extension-less counterparts. For normal pages that is a feature. It keeps addresses short and avoids two addresses for one page.

The console’s rule. Google’s help page for the file method says it does not follow redirects when looking for the verification file. It asks for the exact address and expects the file itself in the response. A redirect, even to a page with the same content, counts as not found.

Neither side was broken. The verification file is an .html file, so the host treated it like any other page, and the console treated the redirect as a missing file. The meta tag method behaves differently: the tag sits in the homepage, and Google’s help page says it looks for tags on the page a visitor lands on after any redirect.

What I changed

I switched to the meta tag method. Instead of pasting the tag into one page by hand, I added the verification value to the site’s configuration file, so every build carries it and it cannot be lost in a later redesign. The console confirmed ownership, and I submitted the sitemap the same day.

I left the uploaded file in place. It is harmless, and deleting it would have been one more change with no benefit.

Two smaller things came out of the same setup:

• I did not resubmit the sitemap when it said “Couldn’t fetch”. That status is shown right after a new submission. Two days later it read success. Resubmitting would only have reset the wait.
• The tag method worked for the next console too. When I added the site to a second search engine’s webmaster tool three days later, verification sat waiting until I added its meta tag to the same configuration file and redeployed; then it passed.

What this has to do with hiring someone

If a freelancer builds your website, landing page or blog, “connect it to Search Console” is often a line in the brief. This incident is small, but it shows two things worth putting in writing.

Check through the live address, the way the outside service sees it. The file existed in the build; it just was not what the live address returned. That is the same lesson as the acceptance checklist for unattended jobs: test with the thing that will actually use the result, not with the file on disk. For a website, that means opening the real URL, or asking the builder to show the console’s own “verified” screen.

Verification belongs in your account. The console property should be created in an account you own, with the builder added as a user you can remove. The same principle applies to every login an automation uses, as the maintenance guide sets out under access and hand-over.

Finally, ask which method they will use. On hosts with clean URLs, the meta tag or DNS method avoids this problem entirely. If your site feeds into an automation, for example a form that should land in a spreadsheet, the workflow automation brief is where the rest of those requirements go.