Optimize tool page SEO with unique meta tags and content

A framework-agnostic technical-SEO playbook for sites with large collections of tool, product, or feature pages (Django, Rails, Laravel, Express, Next.js, Nuxt, Astro, WordPress, or static HTML), derived from a real audit that found 93 of 105 tool pages sharing identical template prose and ranking at average position 68. It runs as an ordered sequence of phases, starting with codebase reconnaissance (locating URL routing, the shared head/meta template, and any tool/page registry, then confirming whether each tool has its own content fields or falls back to shared prose). Phase 1 fixes meta titles and descriptions - a shared title template swapped only by tool name is the single most common reason tool sites rank poorly, since Google treats near-identical titles as duplicates - with a {Tool Name} | {Outcome} - {Brand} title formula under 60 characters (keyword in the first 40), a 120-160 character description formula built from action verbs, and a validate_meta.py script that blocks a deploy on any missing, too-short, or too-long title/description. Phase 2, the highest-leverage fix, replaces that shared template prose with a per-tool content registry entry (meta_title, meta_description, an 80+ word unique introduction, best_practices, how_to_steps, faqs, related_tools), completing one tool's entry fully before starting the next. Later phases enforce one unique <h1> per page with a strict, never-skipped heading hierarchy (Phase 3); aria-labels on icon-only buttons, since accessibility failures lower Core Web Vitals, a direct ranking signal (Phase 4); a hub-and-spoke internal-linking model where every tool links to and is linked from at least two others so nothing is an orphan (Phase 5); clean, keyword-only URL slugs with 301 redirects on any rename (Phase 6); and E-E-A-T signals - an author byline, a last-updated date, and a real about/author page, the single highest-impact fix for solo-built tool sites (Phase 7). Phase 8 covers scaling the registry pattern to 100+ tools: a batch-completion gate that blocks committing a partial batch (e.g. 93 of 105 done signals inconsistent content to Google), a writing order prioritized by Search-Console impressions then most-linked categories then alphabetically, and a build check before every commit.

Use it when the user mentions poor rankings, tool pages not getting indexed, every tool page ranking the same, duplicate-content warnings, "how do I make each tool page unique," thin content, or Google simply not ranking the tool pages. Once the core technical fixes are live, Phase 9 addresses a follow-on symptom - informational keywords ("how to write meta descriptions") stuck at position 50-68 because a tool page is the wrong content format for them - by writing targeted 1,000-1,500 word blog posts with at least two contextual inline links (not just a sidebar) back to the relevant tool. It is not the tool for pure technical performance work: page speed, Core Web Vitals, and render-blocking issues are explicitly delegated to a separate pagespeed-enhancer skill, JSON-LD schema markup to schema-markup-generator, and full crawl/redirect audits to indexing-issue-auditor. The content-registry approach also assumes a structured data source (JSON, YAML, or a database) - a purely static HTML tool site needs a migration step first.

### Count tools with introduction content vs total tools
python3 -c "
import json
tools = json.load(open('data/tools.json'))
total   = len(tools)
done    = sum(1 for t in tools if t.get('introduction','').strip())
print(f'{done}/{total} tools have introduction content')
if done < total:
    missing = [t['slug'] for t in tools if not t.get('introduction','').strip()]
    print('Missing:', missing)
"

Input is the site's tool/page registry plus its live URLs; output is a fully unique registry entry per tool and a series of pass/fail gates. Phase 10 verifies the live deployment itself, not just a clean build - checking that key pages return 200, an invalid slug returns a proper 404 rather than a soft 404, a canonical tag and favicon are present, and each tool page carries at least one application/ld+json schema block. Phase 11 runs pre-commit validation: the meta-length/completeness check, a duplicate-title detector across the whole registry, and a report of which slugs are still missing an introduction. A commit is only safe once every check passes at 100% - a partial batch is treated as still broken.

Works against whatever URL-routing and templating system the site already uses (Rails, Django, Express, Next.js, Nuxt, Astro, WordPress, or static HTML) and a structured tools registry (JSON, YAML, or DB columns), cross-referencing Google Search Console position data to prioritize both the batch-writing order and which informational keywords need a supporting blog post. It hands off to five sibling skills for adjacent work: schema-markup-generator for JSON-LD, social-metadata-hardening for OG tags, indexing-issue-auditor for crawl/redirect audits, pagespeed-enhancer for Core Web Vitals, and a WordPress-specific blog-writing skill for the Phase 9 content.

Teams running a catalog of 10 to 100+ tool, product, or feature pages that all rank around the same mediocre position because they share template prose, thin content, weak internal linking, or missing E-E-A-T signals, who need a phase-ordered fix rather than a one-off tweak - from a solo-built site adding its first author byline to a site scaling unique registry content across 100+ pages.