We Published 16 Blog Posts and Got Two Clicks

In June we switched our own journal to an automated schedule. A new post every two days, written properly, fact-checked, covering things we actually know. Sixteen of them shipped between late June and late August.

Then Chris asked the only question that matters: has this helped my SEO?

We pulled Search Console instead of guessing. Three months of data, and here is what it said.

Site-wide: 63 clicks, 24,300 impressions, a 0.3% click-through rate, average position 34.3. Every journal post URL combined: 2 clicks. The /journal/ index page itself: 2,738 impressions and zero clicks.

And then the part that reframed the whole thing. Both of those two clicks came from two legacy posts that predate the automation. Of the sixteen posts the engine had published, only four had ever registered a single impression. Sixty-one impressions on one, twelve on another, nine, then three. The other twelve had never been shown to anyone for anything.

That is not underperformance. That is not being in the race.

The first instinct was wrong

The obvious read is that the content is not good enough, or that the keywords are too competitive. That is the read most people go with, and it leads to rewriting things that were never the problem.

Site indexing told a different story. 73 URLs indexed against 236 not indexed. Inside the not-indexed group, 84 sat under “Crawled, currently not indexed” and 16 under “Discovered, currently not indexed.”

Those two statuses mean very different things and the difference is the whole diagnosis.

“Crawled, currently not indexed” means Google fetched the page, read it, and chose not to index it. That is a content and quality judgment, and it is a fair fight you can win with better work.

“Discovered, currently not indexed” means Google knows the URL exists and has never fetched it. The posts in that bucket showed Last crawl: N/A. Google had seen them listed in our sitemap and had not spent a single request on them.

You cannot fix a page Google has never read by rewriting it.

Cause one: a sitemap with no dates on it

Our sitemap listed 89 URLs and carried zero <lastmod> values. Not wrong dates. None at all.

lastmod is how a sitemap tells a crawler which URLs have changed and are worth another look. With the field absent everywhere, Google had no freshness signal from us at all, and it behaved exactly the way you would expect: it last read our sitemap on August 15, for posts published on August 18 and August 20.

The crawl stats confirmed it from the other direction. Google’s crawl purpose split was 84% Refresh and 16% Discovery. It was spending almost all of its attention re-checking pages it already knew and almost none of it finding new ones. New posts went into the sitemap and simply waited.

The fix was to stamp each post’s real publication date into the sitemap at build time. There is a discipline in doing that correctly, and it matters more than the code: we only stamp URLs where a genuine date exists. Thirty-one of the 89. The rest get nothing.

The temptation is to stamp every URL with the deploy date so the whole sitemap looks fresh. That is the fastest way to make the field worthless. A sitemap claiming all 89 pages changed on every deploy teaches a crawler to stop believing your dates, and once it stops believing them you have thrown away the only lever you had.

Cause two: we were serving the whole site twice

https://www.reliablepr.net/ returned a full 200 response with a complete copy of the site instead of redirecting to the apex domain.

The rankings side of that was fine. Canonical tags on the www version correctly pointed at the apex, so authority consolidated where it should have. This is the reason a duplicate host can sit there for a long time without anybody noticing.

The crawl side was not fine. Googlebot spent 305 of 2,843 crawl requests on the duplicate host. Roughly 11% of everything Google was willing to spend on us went to fetching a second copy of pages it already had, while sixteen blog posts sat in the queue never fetched at all.

Crawl budget is a real, finite thing and most small sites are told they do not need to think about it. That advice is right up to the moment you start publishing on a schedule. Then the arithmetic changes, because you are now asking for a steady stream of discovery requests out of a pool you are quietly wasting eleven percent of.

Worth knowing if you are on Cloudflare Pages: this one cannot be fixed in the _redirects file. That file only accepts a URL path in the from field, so a hostname rule is silently ignored. No error, no warning, no effect. It has to be a Redirect Rule at the zone level in the Cloudflare dashboard. We tried the file approach, verified it was inert, and left a comment in the file so nobody wastes an afternoon retrying it.

Cause three: nothing on the site linked to the posts

This is the one that should be embarrassing for a marketing agency, so we will say it plainly.

The homepage was the only page on our entire website that linked to a journal post. Every post’s sole other inbound link was the /journal/ index. Posts did not link to each other. Service pages did not link down into them. Industry pages did not either.

So the crawl path to a new post ran through exactly one route, and once a post fell off the homepage module it had almost nothing pointing at it. Meanwhile our service and industry pages, the ones that are indexed and get impressions, sat there passing authority to nothing.

The fix was internal linking done deliberately. 566 internal post links now, and every one of our 38 live posts has at least one inbound link from an indexed page. Service pages, industry pages, city pages, the strategy page and the resources page all carry a related reading block, and posts link to their siblings.

One decision inside that is worth stealing. The page-to-post mapping is hand-built, not generated from tags. A tag-derived list will happily pair every post tagged “strategy” with every page that mentions strategy, which produces pairings that are technically related and obviously mechanical. It reads like an SEO bolt-on because it is one. Choosing the posts by hand takes an afternoon once, and the block reads like a recommendation instead of a widget.

The same block also fixed the dead-end problem. A visitor who lands on a post from search now has somewhere to go that is not the back button.

What was not the problem

Two things looked like causes and were not, and both were worth ruling out before touching anything.

Speed and crawl health were fine. 133ms average response time, 86% of fetches returning OK, “No problems” reported on both hosts, and Googlebot pulling a full post in 172ms at 81KB. There was no performance story here at all. If we had gone chasing Core Web Vitals we would have spent two weeks improving something that was already good.

A near-miss on tag pages is worth repeating as a method note. We checked a tag URL, saw it return index, follow, and briefly concluded the site was publishing 94 thin indexable tag pages that were diluting everything. Then we checked whether that URL returned 200. It did not. It was a 404, and the platform’s 404 page carries a default index, follow. The real tag pages return noindex, follow and are excluded from the sitemap, exactly as intended.

Confirm a page returns 200 before you call it misconfigured. A 404 page’s meta tags are not that page’s meta tags. That one check saved us from “fixing” something that was already correct.

What we are not claiming

We are not going to tell you this produced a traffic recovery, because it is too early to know and anyone who tells you otherwise on a two-week-old technical fix is selling something.

What we can say is what was submitted and what was verified. The sitemap was resubmitted, which forces a re-read and picks up the new dates. Indexing was requested manually for the twelve posts that had never earned an impression, all confirmed. The internal linking is live and verified by counting inbound links per post in the built output. The lastmod values are verified live at 31 stamped out of 89 URLs.

We also set up IndexNow, with one caveat that matters: Google does not support IndexNow. Bing and Copilot do, and Yandex does. It is a useful ping for those surfaces and it is never a substitute for the sitemap.

The www redirect is still open, because it needs a click in a dashboard nobody had open that day.

The general lesson

If you publish on a schedule and see nothing, run the diagnosis in this order.

One: are the pages indexed? Check Search Console’s indexing report, not your rankings. Separate “crawled, not indexed” from “discovered, not indexed.” They are different problems with different fixes.

Two: has Google ever fetched them? Last crawl: N/A on a page that has existed for weeks is the loudest signal in the entire tool.

Three: is your sitemap telling the truth? Real lastmod values on the URLs that genuinely changed, and none on the ones that did not.

Four: are you serving your site more than once? www and apex, http and https, trailing slash and not, staging subdomains left open. Every duplicate copy is spending crawl requests you wanted for something else.

Five: does anything link to the post? If the only path is a paginated index, you have published into a room with no door.

Only after all five does content quality become the interesting question. It usually is not the first problem, and it is almost always the first thing people rewrite.

Our SEO and website service page covers how we run this for clients, and the free audit checks the same things on yours.

FAQ

What does “Discovered, currently not indexed” actually mean?

Google knows the URL exists, usually from your sitemap or an internal link, and has not fetched it yet. The page has never been read. It is a crawl scheduling problem, not a quality problem, and rewriting the page will not change it. Look at internal links, sitemap freshness signals, and whether crawl requests are being wasted elsewhere on the site.

How is that different from “Crawled, currently not indexed”?

Crawled means Google fetched the page, evaluated it, and decided not to index it. That is a quality and value judgment. Better content, stronger internal linking, clearer purpose, and removing near-duplicate pages all help there. The two statuses look similar in the report and require completely different responses.

Do small sites really need to think about crawl budget?

Usually not, until you start publishing regularly. A static brochure site that never changes gets crawled plenty. A site adding pages every few days is making a continuous request for discovery attention, and anything wasting that attention starts to matter. Duplicate hosts, endless faceted URLs, and dead redirect chains are the usual culprits.

Will IndexNow get me into Google faster?

No. Google does not support IndexNow. Bing, Copilot and Yandex do, and submitting there is quick and worth doing. For Google, an accurate sitemap with real lastmod values, solid internal linking, and manual indexing requests for priority pages are the levers available to you.

How many internal links should a blog post have pointing at it?

At least one from a page that is already indexed and earning impressions. That is the floor, and a surprising number of blogs do not clear it. Being reachable from an established page is what puts a post on a path a crawler already walks. Beyond that, relevance beats volume, and hand-picked beats auto-generated.

Publish into a room with a door

Content that nobody has read cannot be judged on quality. Before you rewrite a single post, prove the pages are being fetched, prove your sitemap is honest, and prove something on your site links to them.

We ran this diagnosis on ourselves and found three real causes, none of which were the writing. Yours will probably look similar.

Want us to run it on your site? Book a 15-minute call. No deck, no fluff. Strategy first. Tactics second. The work works.

Reliable PR & Marketing is a strategy-first marketing agency in Bakersfield, California. We run integrated SEO, PR, web, and content for founder-led companies across Kern County and nationwide. Strategy first. Execution always.