In Part 3, I handled the baseline SEO: Open Graph tags, JSON-LD structured data, robots.txt, Google Search Console. The technical foundation. This post picks up where that left off with a question I wasn’t sure how to answer: How do I optimize my content and SEO strategy for my small blog use case? The surprisingly banal answer turned out to be: ‘Just do SEO.’

The 44 Pages Google Doesn’t Want

A week after going live, Google Search Console showed 7 pages indexed and 44 marked “Discovered - currently not indexed.” That sounds alarming until you look at the breakdown. My sitemap had 66 URLs: 7 blog posts, 4 static pages, 3 listing pages, 2 category pages, 49 tag pages, and the homepage. The 44 unindexed pages were almost entirely tag pages.

Hugo generates a page for every tag in your taxonomy. That was a feature I specifically wanted when I chose Hugo (see Part 1). The problem is what those pages looked like: a bare H1 with the tag name, a list of post titles, and nothing else. No description, no meta tags, no structured data, no context for why someone would want to read a page called “cloudflare-pages” that lists three posts.

Google’s response to these pages was exactly right. “Discovered - currently not indexed” isn’t an error; it’s Google telling you the page doesn’t justify a spot in the index. That matches Google’s own posture on partial indexing:

“It's completely normal that we don't index everything off of the website.”

John Mueller, Search Advocate, Google. Source: Google: It's Normal for Pages of a Site to Not Be Indexed (Search Engine Journal, Aug 2021)

So the question isn’t how to force these pages into the index. The question is whether they deserve to be there, and for mine the answer was no. Not yet. The fix had to be structural (better pages), not procedural (more re-index requests).

What Actually Matters for a Small Blog

Before building anything, I spent time researching what the SEO landscape actually looks like in 2026 for a small, new site. Claude and I dug through Google’s official documentation, community discussions, and practitioner write-ups. Some of what we found was solid; some of it was vendor marketing dressed up as best practice. Here’s what held up to scrutiny.

Topical authority is the real lever. Google evaluates whether your site demonstrates depth on a topic, not just whether individual pages are optimized. Interconnected content on the same subject outperforms isolated posts. This is mechanically sound: internal links pass signals, and covering a topic from multiple angles gives Google more context about what your site is about.

Internal linking is the connective tissue. Without it, each post is an island. Google discovers and understands relationships between your pages through links. This isn’t guru wisdom; it’s how crawlers work. We are, after all, on the world wide web.

Search intent alignment matters. If your title and description promise something different from what the post delivers, or if nobody searches for what your title says, the optimization is wasted effort.

Content freshness has real ROI. Updating existing content can outperform publishing new content for driving search traffic. The mechanism makes sense: Google re-crawls updated pages, and the content becomes more relevant over time.

What doesn’t matter much anymore: keyword density, exact-match keywords in URLs (good slugs are enough), meta keywords (Google ignores them entirely), and the specific traffic percentages that SEO tool vendors cite to sell products.

Don’t Kill Your Darlings; Teach Them to Sing

Ultimately, I needed to convert these findings into a workflow that “Just Works” in connecting me with my target audience: potential clients and partners. I chose Hugo because I wanted those tag pages, they were my darlings. To appease the SEO gods, I could either throw them into the volcano at the center of the web, or… I could teach them to sing the siren song of SEO and lull Google to do my bidding. I chose the latter, naturally. This would be accomplished by modifying the Hugo project to create more meaningful tag pages that Google would care about.

Conveniently, that exact dilemma is one Mueller has been on record about:

“Unless you focus on improving the actual quality, it's easy to just spend a lot of time reducing the number of indexable pages, but not actually making the website better.”

John Mueller, Search Advocate, Google. Source: Google On Fixing Discovered Currently Not Indexed (Search Engine Journal, Jul 2023)

So volcano-tossing was off the table on principle. Hand-writing 49 tag descriptions was also off the table, since most of those tags currently live on a single post and that’s its own shape of busywork. The middle path: teach the whole choir to sing automatically, then give individual coaching to the few standouts that earn it. Two layers of automation make that tractable.

Layer 1: Vocal lessons for every tag page. I updated Hugo’s taxonomy template to render post descriptions (not just titles), show categories and dates, display related tags pulled from co-occurring tags across posts, and generate dynamic meta descriptions. I also added JSON-LD using CollectionPage, which is the correct schema.org type for listing pages. Every tag page got better at build time with zero ongoing maintenance.

Layer 2: Solo coaching for the standouts. A data/tags.yaml file maps tag slugs to hand-written descriptions. The template checks for a matching entry and uses it as intro text, meta description, and OG description. Tags without entries fall back to the auto-generated Layer 1 version.

The criteria for who gets a solo: the tag appears on 3+ published posts, represents a core expertise area, or targets queries a potential client might search for. Geographic tags and single-use technical tags stay in the chorus until they earn the spotlight. A shell script audits the current state so the casting calls are always based on live data, not a stale list.

Two Catches, Two Calls

Two implementation glitches popped up in this session, and they really demonstrate the worth of an AI partner like Claude in this process. In “The Old Way” of doing software development, these would surface as high-impact, low-visibility issues way too late in the project’s lifetime. With Claude catching and flagging the details, I was able to leverage domain knowledge to turn silent issues into quick decisions.

The Hugo 0.146 template lookup change. Claude compared the rendered taxonomy pages against the updated template and flagged that the enrichments weren’t showing up. Hugo 0.146 shipped a new template system that changed the lookup order: individual tag pages now use taxonomy.html instead of term.html for the default HTML output format (confirmed on the Hugo forum when other people hit the same wall). The old and new templates had been identical, so the change had been silently in effect for weeks with no visible impact until we tried to edit one of them.

The call: update taxonomy.html with the enriched template, keep term.html in sync as a fallback, and write the behavior into the skill documentation. Cheap insurance plus a breadcrumb for future-me. Two minutes of decision once you know Hugo well enough to see that’s all it needs.

The JSON-LD double-quoting bug. While we were inspecting the rendered <script> tags to verify the new CollectionPage schema, Claude noticed the existing BlogPosting output had double-quoted strings: "headline": "\"Own Your Stack, Part 0: The What\"". Not valid JSON. The cause was Hugo’s jsonify producing properly quoted JSON, then Hugo’s template engine applying a second layer of JavaScript context escaping inside the <script> tag. The fix is piping through safeJS after jsonify. A one-line change per field, but every post had been feeding Google malformed structured data since launch.

The call: fix it now rather than file it. Structured data matters for search, malformed JSON-LD is a silent correctness bug that won’t surface in any visual check, and the fix was cheap. Five minutes, tops.

Neither catch was a flash of insight on my part. Both were Claude reading output I’d have skimmed, flagging what didn’t look right, and letting me decide whether it warranted a detour. The domain knowledge isn’t what found the bugs. It’s what turned the finds into a few fast calls instead of a rabbit hole.

Internal Linking: The Missing Mesh

The other discovery was that my Own Your Stack series had a linking problem. Part 0 linked forward to Part 1. Part 1 linked back to Part 0 and mentioned Part 2 (without a hyperlink). Part 2 mentioned Part 3 (without a hyperlink). Part 3 only linked back to Part 1. The DNS cutover companion post linked into the series but nothing linked back to it.

For a content cluster, this is exactly backward. A web works because every strand connects to several others; pull on one and the whole thing holds. What I’d built was a daisy chain: each post tied to the next with a single thread, nothing crossing back. A reader landing on Part 3 from search had no easy path to Part 0 or Part 1. Authority wasn’t flowing through the cluster; it was pooling at the endpoints. Calling that a “web” would be generous.

The fix: every post in the series now carries a complete series listing at the end, with links to all other parts and the companion post. The current post is marked “(you’re here)” and isn’t a link. When a new post is added to the series, the listing gets updated across all existing posts and their lastmod dates get bumped.

That lastmod bump isn’t cosmetic. Hugo uses it to set <lastmod> in the sitemap, which is the primary signal to crawlers that content has changed. The BlogPosting JSON-LD dateModified field reads from it too. Without the update, crawlers have no reason to re-fetch the page. With it, they know something changed and will come back to look.

The Meta-Lesson (Again)

The take away is consistent with lessonss learned while working with Claude as my AI assistant elsewhere. It’s an efficiency boosting tool that follows instructions better than the most precocious and dedicated intern, but it is no substitute for human thought and insights. An intern might not have the depth of domain knowldge i’m able to bring to bear, but they would (hopefully) have the critical thinking and analysis skills to catch Claude’s mistakes. Thos mistakes are almost always in regard to reasoning through a bigger picture, which makes sense when you understand how the tool itself operates. For this use, SEO research, the collaboration was genuinely useful. Claude pulled together findings from Google’s docs, community discussions, and practitioner write-ups; I separated the signal (topical authority, internal linking, content freshness) from the vendor marketing (specific traffic percentages, keyword density rules, promises that schema drives indexing). The end result was that I went from zero knoeldge to a good enough understanding of SEO to apply my judgment to Claude’s findings and recommendations.

That said, credit is due to Claude in catching the two most technical issues in this post. Claude caught that the rendered taxonomy pages didn’t match the updated template, which is what surfaced the Hugo 0.146 lookup change. Claude also caught the JSON-LD double-quoting bug that had been shipping on every post since Part 3. I’d have missed for certain in my push to move forward rapidly. I’d have said “ship it,” and likely wouldn’t have realized I had this problem until I spotted it in the wild. That would have been double or triple the time to resolution based on troubleshooting alone, and Claude saved me from that headache.

The Series

  • Part 0: The What: Why I built a publishing pipeline instead of just writing more posts on the platform I already had.
  • Part 1: The Why: Technology selection, the napkin math, standing up the project with Claude Code, and the theme trap that reminded me to plan before I build, even when I’m excited about building.
  • Part 2: The How: Custom theme implementation, the three-color section system, contact form integration, and deploying to Cloudflare Pages.
  • Part 3: Baseline SEO: A 30-year technologist who’s never done SEO uses Claude to learn the basics and optimize a Hugo static site.
  • Part 4: Content SEO (you’re here): Making every page worth indexing. Tag page enrichment, internal linking, and the SEO that actually matters for a small site.
  • Companion: DNS Cutover: The full DNS migration to Cloudflare, and why AI-assisted planning is no substitute for infrastructure review.

The Clouditect helps businesses simplify their technology. If you’re building a web presence and want every page working as hard as you are, let’s talk.