Blog essays vs handbook pages
On elangodev.com I keep two content surfaces. The blog is narrative and time-stamped — deep dives with first-person production notes. The handbook is reference: stable pages people return to when they need a pattern, not a story. Mixing those intents produced thin overlapping URLs, so I separated them under /handbook with its own IA.
This write-up covers how I route handbook entries, keep bodies long enough for AdSense quality bars, and avoid turning the handbook into another AI-tutorial dump.
Routing and discovery
Handbook entries live under the App Router with a list page and slug pages, similar to blog but with different metadata tone. List pages emphasize curricula (frontend, backend, testing) rather than publish dates. Detail pages still expose author, last updated, and related blog posts so E-E-A-T signals stay intact.
// Conceptual structure
app/handbook/page.jsx // index of topics
app/handbook/[slug]/page.jsx // long-form reference
I include handbook URLs in robots.ts CONTENT_ALLOW and the sitemap so Googlebot can crawl them alongside blog posts. Utility apps like chat and file drop stay disallowed — those are products, not editorial content.
Body length and structure
Handbook pages follow the same word-count floor I enforce for AdSense readiness: substantial sections, code samples, and concrete file paths from this repo. A handbook page that is only a bullet list of links fails the same “low value” smell as a 300-word blog stub.
Typical outline I use:
- When to use the pattern on this stack
- Minimal working example from elangodev.com
- Failure modes I hit in production
- Links to related blog essays for deeper narrative
Shared rendering helpers
Blog and handbook both render HTML through shared helpers so typography and code blocks stay consistent. That reuse matters for maintenance: when I tighten XSS sanitization or heading styles, both surfaces inherit the fix. I avoid inventing a second content pipeline for “docs” that drifts from the blog renderer.
// Shared idea — render trusted HTML bodies
export function renderContent(html) {
return { __html: html };
}
Keeping the handbook original
I do not auto-publish Gemini drafts into the handbook. Generated text lands as drafts; I rewrite with project-specific paths (next.config.ts, Supabase tables, consent helpers) before publish. That editorial gate is documented on /editorial and is the main defense against thin, templated reference pages.
When two handbook topics start overlapping a blog post, I consolidate. Duplicate outlines across /blog and /handbook look like doorway pages to reviewers even when the HTML differs slightly.
SEO and internal links
Every handbook page links up to the handbook index, sideways to sibling topics, and out to one or two blog posts that expand the narrative. The homepage overview section also points people to the handbook so the crawl graph is not blog-only.
Structured data stays honest: handbook pages are learning resources, blog posts are articles. I do not mark utility dashboards as Article just to inflate rich results.
What I would change next
I want stronger “last reviewed” stamps on handbook entries and a dashboard checklist that flags pages under the word floor before publish. The same AdSense readiness script that audits blog posts should eventually score handbook bodies. Until then, I review handbook length manually whenever I ship a cluster of updates.
Separating essays from reference made the site easier to defend as high-value content: each URL has a job, and that job is visible in the copy.
Example: linking handbook topics to production files
When I write a handbook page about Consent Mode, I reference lib/consent.js, components/CookieConsent.jsx, and components/AdSenseScript.jsx by name. When I write about blog quality, I point at lib/blogContent.js and the AdSense readiness scripts. That habit forces the handbook to stay tied to this codebase instead of floating as generic documentation scraped from the web.
// Mental model for handbook authors (me)
// 1. Name the real files
// 2. Show a minimal snippet that matches production
// 3. Describe the failure I hit when the snippet was wrong
// 4. Link a blog post if the narrative needs more room
I also avoid stuffing the handbook with every npm playground or interactive tool URL. Those apps are useful products, but they are not reference content. Keeping them noindex protects the handbook and blog from being diluted by interactive shells that have little unique prose.
Over time the handbook should become the fastest way for a visitor — or a reviewer — to see that elangodev.com is a maintained engineering site with durable explanations, not a rotating set of thin generated posts.
When two handbook drafts start repeating the same outline, I merge them before publish. Consolidation is part of content architecture, not an afterthought reserved for AdSense emergencies.
I also keep a simple inventory of handbook slugs next to blog slugs when I plan editorial work for the month. If the inventory shows three near-identical React performance pages, I delete or merge before writing a fourth. That discipline is how a small site stays dense with value instead of wide with filler.
Handbook architecture will keep evolving with the product, but the rule stays fixed: reference pages earn their URL with unique explanations tied to this codebase, or they do not ship.
