So I built Nutrinfo: one fast page per food, generated straight from USDA data, plus a few calculators and an AI meal analyzer. This post covers how it is put together, with the real code.

Disclosure: this article was written with AI, based on the project's actual code and data. It was first published on DEV.

The stack

• Astro for static generation, with output: 'static'
• Cloudflare Pages for hosting, with one Pages Function for the AI endpoint
• GitHub Actions to build and deploy on every push to main
• USDA FoodData Central, SR Legacy as the data source (7,793 foods, up to 150 nutrients each)

No database and no server. Every food page is plain HTML on Cloudflare's edge.

Step 1: turning a 200 MB JSON file into site data

USDA ships SR Legacy as one large JSON file. A Node script reads it once and writes two compact files:

1. src/data/foods.json with the nutrients Astro needs at build time
2. public/search-index.json, a tiny array-of-arrays index for client-side search

The interesting parts are the slugs and the serving sizes:

const slugify = (s) =>
  s.toLowerCase()
    .normalize('NFKD').replace(/[\u0300-\u036f]/g, '')
    .replace(/%/g, ' percent ')
    .replace(/&/g, ' and ')
    .replace(/[^a-z0-9]+/g, '-')
    .replace(/^-+|-+$/g, '')
    .slice(0, 90)
    .replace(/-+$/, '');

// Duplicate names exist in USDA data, so fall back to the FDC ID.
let slug = slugify(name);
if (seen.has(slug)) slug = `${slug}-${f.fdcId}`;

USDA also publishes household measures ("1 cup, sliced", "1 medium") with gram weights, so each page gets a serving picker for free.

The search index stores each food as [slug, name, kcal, protein, carbs, fat, categoryIndex]. For 7,793 foods that is about 1 MB, small enough to fetch once and search in the browser with no backend.

Step 2: one Astro page per food

Astro's getStaticPaths does the heavy lifting:

---
import { foods } from '../../lib/data.mjs';

export function getStaticPaths() {
  return foods.map((food) => ({ params: { slug: food.slug }, props: { food } }));
}
const { food } = Astro.props;
---

Each page has a nutrition label, a calorie breakdown, the full nutrient tables with % Daily Value, a comparison against the category average, and links to similar foods. You can see one here: bananas, raw.

A full build produces about 7,860 pages and takes around five minutes. That is fine for a site where the data changes rarely.

Pages that are not thin

The risk with programmatic pages is that 7,800 near-identical templates get ignored by search engines. Every page computes things that are specific to that food:

• a short summary sentence ("It is an excellent source of vitamin C (98% DV)...")
• how it compares to its category average, in percent
• an FAQ block answering calories, protein, carbs and micronutrients in 30 to 50 words, which is the format featured snippets and AI answer engines pick up
• "alternatives" from the same category with more protein for similar calories, or fewer calories

There are also "foods high in X" ranking pages, like foods high in iron, which link down to the food pages. That gives the site a clear hub-and-spoke structure instead of 7,800 orphans.

Step 3: an AI meal analyzer on a Pages Function

Static pages are great for single foods, but people eat meals. The AI meal analyzer takes a text description or a photo and returns an estimate as structured JSON.

It runs as a Cloudflare Pages Function at functions/api/ai.js. Text goes to a model on Groq, photos go to Gemini, and Gemini also acts as the fallback. The system prompt asks for strict JSON matching a schema:

const MEAL_SCHEMA = `{
  "items": [{ "name": string, "portion": string, "grams": number, "kcal": number, "protein": number, "carbs": number, "fat": number }],
  "total": { "kcal": number, "protein": number, "carbs": number, "fat": number },
  "score": number,
  "summary": string,
  "tips": [string]
}`;

The part I am happiest with is rate limiting without any extra service. The Cache API is available in every Pages Function, so it doubles as a best-effort counter:

async function rateLimited(ip) {
  const cache = caches.default;
  const now = Date.now();
  const windows = [
    { key: `m/${Math.floor(now / 60_000)}`, max: 8, ttl: 60 },
    { key: `d/${Math.floor(now / 86_400_000)}`, max: 60, ttl: 86_400 },
  ];
  for (const w of windows) {
    const req = new Request(`https://rl.nutrinfo.internal/${encodeURIComponent(ip)}/${w.key}`);
    const hit = await cache.match(req);
    const count = hit ? parseInt(await hit.text(), 10) || 0 : 0;
    if (count >= w.max) return true;
    await cache.put(req, new Response(String(count + 1), { headers: { 'cache-control': `max-age=${w.ttl}` } }));
  }
  return false;
}

It is per data center, not global, so it is not exact. For keeping a free tool from being drained by one script, it is enough, and it needs no KV, D1 or Durable Object.

Step 4: deploying 270 MB of HTML

Uploading the whole dist/ folder from a home connection was slow, so the build moved to GitHub Actions:

- run: npm ci
- run: npm run build
- run: npx wrangler pages deploy dist --project-name nutrinfo --branch main --commit-hash ${{ github.sha }}
  env:
    CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
    CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}

Wrangler only uploads files whose hash changed, so later deploys are much faster than the first one.

Step 5: the SEO plumbing

Getting 7,800 URLs discovered matters as much as building them.

Split sitemaps. @astrojs/sitemap supports chunks, so foods, list pages and everything else get separate sitemaps. Search Console then reports index coverage per section, which tells you quickly if the food pages are being skipped.

sitemap({
  chunks: {
    foods: (item) => (new URL(item.url).pathname.startsWith('/food/') ? item : undefined),
    lists: (item) => (/^\/(category|high-in)\//.test(new URL(item.url).pathname) ? item : undefined),
  },
}),

IndexNow. Bing, Yandex and others accept IndexNow pings. A small script reads the built sitemaps and posts URLs in batches of 10,000, and the deploy workflow has an optional input to run it for given path prefixes.

One gotcha cost me a run: triggering the workflow from Git Bash on Windows with -f indexnow=/methodology/ silently turned the input into C:/Program Files/Git/methodology/. The run succeeded and submitted zero URLs. MSYS_NO_PATHCONV=1 fixes it.

Structured data. Each food page has WebPage (with isBasedOn pointing at the USDA dataset), BreadcrumbList and FAQPage JSON-LD.

Step 6: performance fixes from an audit

An SEO audit flagged a few things I had missed:

• Render-blocking fonts. Google Fonts CSS blocked the first paint. I self-hosted the latin subsets of Inter and Fraunces as variable woff2 files and preloaded them.
• Render-blocking CSS. The whole stylesheet is about 6 KB, so build.inlineStylesheets: 'always' inlines it into every page. No stylesheet request at all.
• Missing HSTS and favicon.ico. Both are a one-line fix in _headers and a generated icon set.

On real visits, Cloudflare Web Analytics shows 86% of page loads with a good Largest Contentful Paint.

Where it is now

The site is about a week old. Search engines are crawling it, a handful of real people visit each day, and most pages are still waiting to be indexed. I will write a follow-up with real numbers once Search Console has something to say.

What I would do differently: plan the internal linking and the "foods high in" pages from day one instead of adding them after launch. They are the pages people actually link to.

If you want to look around, it is at nutrinfo.net. Feedback on the data pages or the meal analyzer is very welcome, especially if a number looks wrong. Every page links to its USDA source, so it is easy to check.