Your blog doesn’t exist until Google says so
We had six posts live, a valid sitemap and clean markup. Google had never heard of any of it. What we found when we finally opened Search Console for our own site.
We moved this site from a headless CMS to code, added a blog, and published six posts. The sitemap listed every one of them. The markup had a canonical URL and structured data on every page. By any check you can run from a terminal, the site was ready to be found.
Then we opened Google Search Console. Of the pages on hypermetron.com, Google had indexed two: the home page and a contact page that no longer exists. The blog was not “not indexed”. It was unknown. Google had never fetched it, had no sitemap pointing to it, and had seen no page linking to it.
None of this was a bug in the code. It was the gap between shipping a site and telling Google about it, and it is easy to fall into. Here is what we found, and the checklist we now run.
The sitemap Google had was from 2015
Search Console keeps the sitemaps you submit and rereads them on its own schedule. Ours had one entry: http://hypermetron.com/sitemap.xml, submitted in September 2015 and last read in October 2025. Two pages discovered. Note the http: it predates the site moving to HTTPS, and it predates everything currently on it.
Our live sitemap was fine. It returned valid XML with the home page, the blog index and every post, each with a lastmod date. robots.txt pointed to it. But a sitemap that robots.txt names is a hint Google picks up when it gets around to it. A sitemap submitted in Search Console is one Google tracks and reports on. Nobody had submitted the new one, so Google kept reading the old one.
The fix took a minute: submit https://hypermetron.com/sitemap.xml. Even that had a wrinkle. Straight after submitting, Search Console reported “Couldn’t fetch” with zero pages, while the same URL returned a clean 200 from our terminal. A brand-new sitemap often shows that status until Google’s first real read. Check the live file yourself before treating it as an error, then look again in a few days.
Half the “indexed” pages weren’t ours
The overview said six pages were indexed. Four of them were on hypersync.hypermetron.com, the site for our Shopify app. A domain property in Search Console covers every subdomain, so its totals mix sites that have nothing to do with each other. If a product lives on a subdomain, read the URLs before you read the numbers.
Most of “not indexed” was correct
Six pages were listed as not indexed, which sounds bad until you open them:
- Four were redirects:
http://,www.and the HTTP version of the subdomain. They all point to the real HTTPS address, so Google is right not to index them. - One was `/index.md`, the markdown copy of our home page that we serve to AI agents. It sends a
Link: rel="canonical"header pointing to the HTML page, so Google crawled it and chose the HTML version. That is the intended outcome. - One was a manifest file on the subdomain. Not a page at all.
Sorting these is most of the work. A count of “not indexed” pages tells you nothing on its own. Open each reason, look at the URLs, and decide whether it is expected, already fixed or a real problem. For us, only one item was a real problem, and it didn’t appear under any reason: the pages Google had never seen.
Request indexing is rationed
URL Inspection lets you ask Google to crawl a specific page soon. We planned to request the blog index and the three newest posts. One request went through. The next came back “Quota Exceeded: try again tomorrow”. The daily limit is small, and on a domain property every subdomain draws on the same allowance.
So spend requests on the pages that matter most and aren’t reachable any other way. A page listed in a freshly submitted sitemap will be found anyway. A request only moves it up the queue.
What we check now
Every look at Search Console now follows the same steps, and each one is written down so the next check has numbers to compare against:
- Read the Sitemaps page itself, not the sitemap filter on the indexing report. Make sure the submitted sitemap is the current one, on HTTPS, and was read recently.
- Look up a few important URLs in URL Inspection. “URL is unknown to Google” means discovery is broken, not content.
- On a domain property, separate the subdomains before drawing conclusions.
- Open every “not indexed” reason and sort its URLs into expected, already fixed or needs work. Redirects and canonical alternates are usually expected.
- Keep the few indexing requests for pages that can’t wait.
- Log the numbers, even when nothing changed.
None of this is advanced SEO. It is the plumbing that has to work before content, keywords or links can matter at all. Shipping the site is half the job. The other half is checking that Google can find it, and it is worth doing the day you launch, not months later.