A weekly report had been telling me the same thing for five weeks: rankings flat, new content takes four to twelve weeks, nothing to do. All true. All useless.
On July 27 the agent running that report stopped accepting its own explanation and checked Google’s index directly. Six of the sixteen articles we had published to a client’s site on June 14 had never been indexed. Not ranking poorly — not in the index at all. A page outside the index has a ceiling of zero, and no amount of patience changes that.
Then it got worse in the useful way. We had not caught it because that site had no Google Search Console property. It had no Analytics either. No Tag Manager. We had shipped sixteen articles into a property with no measurement of any kind.
Here is the whole investigation, including the parts that make us look bad, because the parts that make us look bad are the ones worth copying.
Rankings and indexation are different questions
Every rank tracker answers “is this ranking.” Almost none answer “is this eligible to rank.” Those look identical when the number is zero.
Five reports in a row read the flat line and concluded the content needed more time. Reasonable — week six sits inside the normal four-to-twelve week window. But “not ranking yet” and “not in the index” produce the same flat line, and only one of them is fixed by waiting.
The check that separated them took one query per URL. Ten of sixteen were indexed. Six were not, including the three most commercial topics in the set — the equipment guide, and both articles about how much money you can make. The pages Google skipped were the pages with the clearest buying intent.
Rule out your own plumbing before blaming Google
Before calling it Google’s decision, we checked our side: all sixteen URLs returned 200, all sixteen were in the sitemap, all sixteen were internally linked from both the content hub and the blog index, and the schema was intact.
That mattered enormously. It turned “six pages are broken” into “six pages are fine and Google has not selected them” — a different diagnosis with a different fix. It also killed a recommendation we were about to make about internal linking, which would have been busywork against a condition that was already satisfied.
Name what you ruled out. An audit that only reports what is wrong is not showing its work.
The five whys, honestly
- Why were six articles not indexed? Google crawled and declined. We cannot say more precisely, because the tool that answers it is Search Console — which we did not have.
- Why no Search Console? No property existed for that domain under any account we hold.
- Why was no property created? Nobody asked for it. The June 14 client update contains an explicit list titled “what still needs to be done — needs your login,” with five items on it. Search Console is not one of them. That list was written from memory, per project.
- Why did no audit catch it in six weeks? We run a Search Console coverage audit. Ten days before this, it reported ninety-two sites missing a property — and this site was not among them. It could not be.
- Why not? The audit takes its list of sites from our hosting fleet. This is a client site we publish to but do not host. It was structurally incapable of appearing as a gap.
The root cause: we were auditing the wrong population
A site could carry months of our work, our articles, and our schema, and never once be eligible to show up as a gap — because eligibility to be audited was inherited from hosting, not from the work.
That is the transferable lesson, and it is worth more than the incident: an audit is only as honest as its denominator. Ours reported “ninety-two sites not in Search Console” with total confidence while being blind to the one that broke. When a coverage number looks stable, the useful question is not whether the number is good. It is what is this number incapable of counting?
The second root cause: our checklist was a picture
We have had an Access Checklist for years. It is how we collect logins before implementation — Search Console, Tag Manager, Analytics, the rest.
When we opened it during this investigation, the page was five slide images and zero words. Good slides, from our Agency Management Course. But a search engine cannot read a slide. An AI assistant cannot quote one. Our own agents cannot parse one. The checklist could not be executed, so it was never enforced, so a client-facing “what we need from you” list got written from memory instead — and Search Console fell off it.
If your standard operating procedures live as slides, screenshots, or PDFs, your team has documentation and your systems have nothing. That page now has the checklist written out as text, with the slides kept underneath where they belong.
How big it actually was
We rebuilt the audit population from the work rather than the hosting: stored credentials, the hosting fleet, client rosters, and every client project folder. A property earns a row because we do work for it.
That took the list from 105 properties to 265 — meaning 160 properties that no previous audit could see. Then we measured all of them from public page data:
| Finding | Count |
|---|---|
| Properties in scope | 265 |
| Reachable | 203 |
| Unreachable — parked, dead, or DNS never pointed | 62 |
| Carrying a Search Console verification tag | 41 |
| No analytics at all | 150 |
| Reachable, no verification tag, no analytics | 127 |
| — of those, on our own hosting | 50 |
| Sitemap present but missing from robots.txt | 39 |
Fifty of them are sites we host ourselves. We are publishing that number rather than fixing it quietly first, because every agency and every in-house team reading this has some version of it, and nobody finds theirs until something goes looking.
One caveat we insisted on keeping in the report: a missing verification tag does not prove a property has no Search Console. Verification by DNS, Analytics, or Tag Manager leaves no HTML trace. But a site with no tag and no Analytics and no Tag Manager has only DNS left as a route, and we do not hold DNS for most of these. So 127 is a considered estimate of what we are blind on, not a raw count. If you build this audit, be equally careful — a number you cannot defend is worse than no number.
What we changed
- The denominator. A register built from credentials, hosting, client rosters, and client project folders — so doing work for a site is what puts it in scope.
- The measurement. A script that probes every property for verification, analytics, sitemap, robots reference, and publish access, with no logins required.
- The cadence. That audit now runs weekly. A missing property surfaces in seven days instead of six weeks.
- The gate. Nine standard accesses, of which the first four — Search Console, CMS admin, Analytics, Tag Manager — block shipping. A build is not done when the content is live. It is done when the content is live and we can see what it does.
- The distribution. The checklist is now a skill in every one of our agents’ packs, so the “what we need from you” list is generated from a standard rather than recalled by a person at the end of a long week.
- The tracker that missed it. Every weekly report we run now checks indexation, not just rankings.
If you want to check your own
You do not need our tooling for the first pass. Pick your last content project and answer three questions:
- Does that property have a Search Console property you can open right now?
- Search
site:plus one of the article URLs. Does it come back? - View source on the homepage. Is there a real Analytics or Tag Manager ID — not just the script, an actual ID?
If any answer is no, you have the same gap, and you found it faster than we did. The Access Checklist is the list we now work from, and verifying Search Console is the step that pays for itself first.
Nobody on this project skipped a step. The step wasn’t on the list. That is almost always what happened.

