The first thing I do after a site goes live is open Search Console. The second thing I do, more often than I would like, is find something embarrassing.
On one of my own sites I had replaced an old static HTML site with WordPress and left the robots.txt untouched. It pointed Google at /sitemap.xml, which was still the index file the old static site had generated. So the sitemap I was handing Google listed twenty-seven URLs from a site that no longer existed, while WordPress was quietly publishing its real sitemap at /wp-sitemap.xml, which nothing pointed at. Google was crawling a map of a demolished building.
That is the kind of thing this checklist exists to catch. It is not a growth strategy and it will not get you traffic. It is the dull mechanical pass that makes sure Google can find, read and correctly identify what you have published, and it takes about forty minutes per site. Everything below is what I run on my own sites: two WordPress blogs on shared hosting, a small SaaS on a VPS, and a static site on Cloudflare Pages.
Verify the domain, not the URL prefix
Search Console offers two property types. The URL-prefix property covers exactly one protocol and hostname, which means https://example.com and https://www.example.com are two separate properties with two separate sets of data. The domain property covers every subdomain and both protocols at once, and it is verified with a DNS TXT record rather than a file or a meta tag.
I use the domain property every time. On Hostinger that means going into hPanel, opening the DNS zone editor for the domain, and pasting the google-site-verification= string as a TXT record on the root. Verification usually completes within a few minutes, though DNS propagation can make you wait longer; if it fails on the first attempt, wait rather than changing anything.
One trap worth knowing: if your domain contains a non-ASCII character, Search Console will not take it as typed. One of my domains has an ñ in it, and entering it with the ñ produced an error with no useful explanation. It has to go in as the punycode form, the xn-- version of the hostname. Your registrar or any punycode converter will give you that string. Nothing about the error message tells you this.
Submit the sitemap as a full URL
In the Sitemaps panel, submit the complete address, https://yourdomain.com/sitemap.xml, not the bare filename. Search Console shows a greyed-out domain prefix next to the input box, which makes it look like typing sitemap.xml is what it wants. It is a mistake I have made myself, and the resulting “couldn’t fetch” status can sit there for days without explaining itself.
Find out which sitemap your site actually serves before you submit anything. WordPress core generates /wp-sitemap.xml. Most SEO plugins replace that with their own, usually /sitemap_index.xml or /sitemap.xml. Open the URL in a browser and read it. If it lists posts you deleted or a section that no longer exists, you have found your problem before Google did.
Delete the sitemaps that are lying
This is the step almost nobody does, and it is the one that fixed my own mess. Search Console keeps every sitemap you have ever submitted, including the ones from the previous version of the site, and it keeps reporting errors against them forever.
Go through the list and remove anything that is not the current, correct sitemap: leftovers from an old CMS, a file that returns 404, a sitemap index that points at children you have deleted. Removing a sitemap from the list does not remove the pages from the index, so there is no risk in cleaning up. Then submit the correct one, once.
After any significant change to the site structure, submit the same sitemap again. Resubmitting is how you tell Google the file changed; it is not a request for priority, and it does not do anything if the file itself has not been updated. If your plugin caches the sitemap, load the URL in a private window first and confirm you are looking at the current version.
Read your robots.txt as if a stranger wrote it
Open https://yourdomain.com/robots.txt in a browser, on the live site, not in a plugin’s settings screen. Three things to check, in this order:
- Does the
Sitemap:line point at the file you just submitted? Mine pointed at a dead one for months. - Is anything important blocked? WordPress blocks
/wp-admin/by default and that is correct. A strayDisallow: /left over from a staging site is not, and it is the single most expensive typo in this whole list. - If you intend to run ads, make sure you have not blocked Google’s ad crawler,
Mediapartners-Google. It is a separate user agent from Googlebot, and blocking it stops ads serving on pages that are otherwise indexed perfectly well.
Worth remembering that robots.txt controls crawling, not indexing. A URL you block can still appear in results if other pages link to it, just without a description. If you genuinely want something out, the tool is a noindex tag on a page Google is allowed to crawl, which is the opposite of what most people’s instinct tells them.
Inspect the URLs that matter, and only those
The URL inspection tool tells you what Google currently knows about a single page: whether it is indexed, when it was last crawled, which canonical it picked, and whether the version it fetched matches what you see. That last part is the useful bit. “Test live URL” fetches the page as Googlebot right now and shows you the rendered HTML, which is how you find out that your theme hides your content behind JavaScript, or that your hosting is serving a cached copy from before your fix.
Then request indexing. On a new site I do this for the home page, the About page, the privacy policy and four or five of the strongest posts. Not the whole site. There is a daily quota, requests are queued rather than executed, and firing off fifty of them does not speed anything up. Requesting indexing does not influence ranking either; it only asks Google to come and look sooner.
Expect this to take time. In my own launches, pages requested this way have typically been crawled within a few days, but I have also had pages sit unindexed for weeks with the status “Discovered – currently not indexed”, which usually means Google found the URL and decided it was not worth fetching yet. There is no button for that. The answer is a better page, not another request.
If the site will carry ads, check ads.txt now
Google calls ads.txt not mandatory but highly recommended in its AdSense documentation, with one important catch: if the file exists and does not contain your publisher ID, ad requests for your site get treated as unauthorised. A wrong file is worse than no file.
The line goes in the domain root and looks like google.com, pub-XXXXXXXXXXXXXXXX, DIRECT, f08c47fec0942fa0. My own version of this mistake is a good one: on this site the file once said DIRECTO, the Spanish word, instead of DIRECT, because the line had been translated along with everything around it. The file loaded, returned 200, looked completely normal, and was invalid. It is four fixed fields. Copy them, do not retype them, and open the URL afterwards to confirm the server actually returns the file rather than a themed 404 page.
Changes to the file take time to register on Google’s side, and the documentation warns this can stretch out on sites with little traffic. That is one more reason to get it right on day one rather than during a review.
What I deliberately do not do at this stage
I do not chase server speed on a new blog. I did measure my own sites on 20 September 2026, and the one thing that measurement was genuinely good for, finding that neither of my WordPress blogs returns a page-cache header at all, has nothing to do with whether Google indexes you. The figures and their caveats are in the write-up of my own setup.
I also do not touch backlinks in the first months, and I do not add structured data to posts that do not need it. Both are real, but neither is what is stopping a two-week-old site from ranking.
What the checklist will and will not buy you
It gets you found. It does not get you read. Here are my own numbers, which is the least flattering thing in this article. Search Console gave this site 15 clicks in the three months to 19 September 2026, at an average position of 67; my other blog got 5 clicks from 6,710 impressions, at 63. Both are in Search Console with their sitemaps submitted and their main URLs inspected. Position 63 means page seven.
So the checklist did its job and the content did not do its. That was the correct diagnosis, and I wrote up what the export of those posts actually showed in the content mistakes that got this blog rejected by AdSense. If you are choosing what to publish next, the contrast between keyword tools and what your own Search Console already reports is the most useful thing I know, and it is the subject of checking AI keyword ideas against real Search Console data. For the free tools that cover most of this, see the SEO tools I actually use as a beginner, and for wiring your posts together once they exist, how I mapped a hundred posts into clusters.
Run this list once per site, keep it in a text file, and stop looking at Search Console every morning for a month. The first honest signal on a new site arrives in months, not weeks, and there is nothing in the panel that reacts to being refreshed.