I Generated 7,681 Static Pages From 78 Units of Data — Here's the Architecture

Most unit converter websites are React SPAs with a single page. Google indexes one URL and calls it a day. I wanted to see what happens when you treat every possible conversion as its own page — with its own title tag, its own FAQ schema, and its own educational content. So I built metriqcon.co and generated 7,681 static HTML pages from just 78 units of source data.

Here's how the architecture works and what I learned.

The Math: How 78 Units Become 7,681 Pages

The unit data covers 8 categories: length, weight, temperature, area, volume, speed, time, and data storage. Each category has 4–12 units. The page generation logic creates three types of URLs:

Category hub pages — one per category (8 total)
/convert/length, /convert/weight, etc.

Unit pair pages — every permutation of from→to within a category
/convert/length/meters-to-feet
That's n × (n-1) pages per category. With 12 length units, that's 132 pair pages for length alone. Across all categories: 548 pair pages.

Value pages — 13 popular values (1, 2, 5, 10, 15, 20, 25, 30, 50, 100, 200, 500, 1000) for each pair
/convert/length/15-meters-to-feet
That's 548 × 13 = 7,124 value pages.

Total: 1 homepage + 8 hubs + 548 pairs + 7,124 values = 7,681 pages.

The SEO Trick: Answer in the Title Tag

The most important decision was what goes in the <title> tag of value pages. Compare these two approaches:

❌ "Meters to Feet Converter | Metriqcon"
✅ "15 Meters to Feet = 49.2126 ft | Metriqcon"

The second version puts the exact answer in the title. When Google renders this in search results, users see the conversion result without clicking. Counterintuitively, this increases CTR — people click to verify or explore further because the snippet proved the site has the exact answer they need.

Tech Stack: Astro + React Islands

The site uses Astro for static site generation with React islands for interactivity.

src/
├── data/
│   ├── units.js          # Single source of truth: 78 units with conversion functions
│   └── content.js        # Educational content engine: real-world examples, facts, FAQs
├── layouts/
│   └── Base.astro        # Shared HTML shell with SEO head
├── pages/
│   ├── index.astro       # Homepage (React island: client:load)
│   └── convert/
│       ├── [category].astro        # Hub pages (pure static HTML)
│       └── [category]/[slug].astro # Pair + value pages (static HTML + React island)
└── react/
    ├── Metriqcon.jsx       # Full interactive converter (homepage)
    └── ConverterIsland.jsx # Lightweight converter (conversion pages)

The key architectural decision: the conversion pages are 90% static HTML, 10% React. The answer, the formula, the FAQ, the conversion table, the real-world examples — all rendered at build time as plain HTML. The only React island is the interactive converter input, which hydrates after the page loads.

This means Google's crawler sees the full content immediately, without executing JavaScript.

The Thin Content Problem (And How I Solved It)

Here's what I didn't anticipate. After deploying 7,681 pages, Google crawled about 200 of them and put 7,639 in "Discovered - currently not indexed." The reason: Google saw thousands of pages with identical structure and minimal text variation, and classified them as thin content.

The fix was building a content engine that generates genuinely unique text for every unit pair:

// src/data/content.js

const REAL_WORLD = {
  kg: {
    examples: [
      "a bag of sugar (1 kg)",
      "an average adult man (about 80 kg)",
      "a grand piano (about 300 kg)"
    ],
    context: "The kilogram is the base SI unit of mass..."
  },
  lb: {
    examples: [
      "a loaf of bread (about 1 lb)",
      "a newborn baby (about 7.5 lb)",
      "an adult golden retriever (65–75 lb)"
    ],
    context: "Pounds are the primary weight unit in the US..."
  },
};

Each conversion page now renders unique paragraphs combining the from unit's context, the to unit's context, real-world examples for both, historical "did you know" facts, category-specific use cases, and 7 FAQ items (up from 3). The FAQ items also generate JSON-LD structured data for Google rich results.

The Live Math Parser

One feature that differentiates the converter: the input field accepts math expressions, not just numbers. Type (12 * 4) + 6.5 and it evaluates live, then converts the result across all units simultaneously.

The parser is sandboxed — no eval(). It validates the input against a whitelist of safe characters, then uses a new Function() in strict mode:

function parseExpression(expr) {
  if (!/^[\d\s\+\-\*\/\(\)\.\,\^%]+$/.test(cleaned)) {
    return { value: null, error: "Invalid characters" };
  }
  const safe = cleaned.replace(/,/g, ".").replace(/\^/g, "**");
  const result = new Function(`"use strict"; return (${safe})`)();
  return { value: result, error: null };
}

This catches engineers and developers who are calculating something before converting — a use case no other converter site handles.

Build Performance

Astro builds all 7,681 pages in under 25 seconds on a standard machine. The output is about 180MB of static HTML, deployed to Vercel's edge network. Total hosting cost: $0 (Vercel free tier).

✓ sitemap.xml: 7,681 URLs
✓ Built in 20.35s
✓ Deployed to Vercel edge network

What I'd Do Differently

Start with fewer pages. 7,681 pages on a brand-new domain triggered Google's thin content filters. Starting with 500–1,000 of the highest-traffic conversion pairs, then expanding after building domain authority, would have been smarter.

Add a blog from day one. Programmatic pages alone don't build topical authority. A handful of articles like "How to convert cooking measurements" or "Understanding metric vs imperial" would have given Google a clearer signal about what the site is about.

Try It

The site is live at metriqcon.co. The full source generates from a single units.js data file — every page, the sitemap, and the converter all import from the same place.

Interested in hearing what features you'd add or how you'd approach the SEO challenge differently.