Search Console emailed us this week with a new warning: some pages on hogtron-solutions.com weren’t indexed. Two reasons, two page counts — “Alternate page with proper canonical tag” on 9 pages, “Page with redirect” on 4.
Most business owners get this exact email, read the words “not indexed,” panic a little, and either ignore it or pay someone to “fix SEO” without knowing what’s actually broken. We run our own site through the same scrutiny we sell, so here’s the real diagnosis — including the part where half the warning wasn’t a problem at all, and the automated check we built afterward so we’re not relying on Google’s email to catch the next one.
Reason 1: not a bug
“Alternate page with proper canonical tag” sounds alarming. It isn’t, necessarily. It means Google crawled a page, found a <link rel="canonical"> tag pointing somewhere else, and correctly excluded the duplicate from its index.
We checked. Our site answers at both hogtron-solutions.com and www.hogtron-solutions.com — same content, both return 200. Every page’s canonical tag correctly points to the non-www version. Google was doing exactly what canonical tags are for: keeping one version in the index instead of two. Nine pages, working as designed. No fix needed.
The lesson here isn’t “ignore Search Console.” It’s “read past the scary title before you touch anything.” A lot of wasted agency hours come from treating every GSC row as a fire.
Reason 2: a real one
“Page with redirect” was different. We pulled the sitemap, checked every URL Google actually crawls (hogtron-solutions.com/about/, /services/, and so on) — all returned clean 200s, no redirect. So the sitemap was fine. Something else was sending Google through a redirect hop.
We found it in the HTML: every internal link on the site — nav, footer, every call-to-action — pointed at the page without a trailing slash (/about) while the page itself actually lives at the trailing-slash address (/about/). The server correctly 301-redirects one to the other. So every single internal link click, and every crawl of those links, ate an unnecessary redirect first.
About 150 links, 30 files, one root cause: nobody had set a consistent trailing-slash rule across the site, so link after link got typed the “obvious” way instead of the canonical way.
The fix, and the part where we weren’t actually done
Every internal href rewritten to point straight at the canonical URL — the same one already declared in the sitemap and the canonical tag. Built, tested, deployed same day. We pulled the live homepage after deploy and confirmed the actual HTML Google would crawl next pointed straight at the real URLs.
Here’s the honest part: that fix was a manual grep-and-replace pass across the template files. A few days later, building the automated checker described below, the checker immediately found more of the exact same bug in places the manual pass never touched — a handful of links written as data objects instead of plain HTML (href: '/some-page' instead of href="/some-page", a different quoting style our search pattern missed), and several links inside the Markdown content of other field notes, which the original sweep never checked because it only looked at template files, not article text.
That’s not a one-off embarrassment, it’s the actual argument for automation. A human pattern-matching by eye will miss a case. A tool that checks the shipped output against the sitemap doesn’t care how the link was written — hardcoded, generated from a data list, or typed into an article — it just checks whether the final HTML is right.
What we built afterward
Two checks, running automatically from here on:
Before every deploy, a script compares every internal link in the built site against the canonical URL list in the sitemap. If anything would redirect — wrong trailing slash, a typo, a link to a page that no longer exists — the deploy fails before it ships. The bug doesn’t reach the live site, let alone Google.
Every day, a separate check hits the live, hosted version of the site directly: is the sitemap reachable, does every page in it load with a clean 200 instead of a redirect, does the canonical tag on each page point where it should, do the www and non-www versions agree. This one exists because not every problem comes from a code change — hosting configuration, DNS, and server-level redirect rules can drift on their own, outside anything we deployed.
We’re not polling Google’s indexing report directly — the specific “why isn’t this page indexed” breakdown Search Console shows you isn’t something Google exposes as a public API you can query on a schedule. What we built instead checks the underlying things that report is actually measuring: does every link resolve cleanly, is the sitemap healthy, are canonical tags correct. If those stay clean, there’s nothing left for Search Console to flag. And if one of our checks ever does fail, we hear about it the same day — not whenever we happen to open Search Console next.
Why this is the job, not a one-off
Google changes what it flags, how it flags it, and what “indexed” even means more often than most business owners can track. New Search Console reasons get added, AI Mode keeps reshaping what “search” is, and the rules that mattered a year ago aren’t the whole picture anymore.
The old version of “staying on top of it” was a person checking Search Console and remembering to look. The version we’re running now checks itself, every day, and refuses to ship a regression in the first place. That’s the difference between a business that finds out from a customer who couldn’t find them, and one that already knew.
If you want to know what your own site is telling Google right now, run a free audit. Ongoing monitoring and fixes like this one are part of our local SEO work.