DEV Community: mathew lam

Scaling a Content Site to 5 Languages with Next.js + next-intl (Zero Manual Translation)

mathew lam — Tue, 12 May 2026 14:17:13 +0000

Why Multi-Language?

I run a niche content site about NBA jerseys. Basketball is global — fans in China, Japan, Korea, and Latin America search for the same jerseys in their own languages. By adding 4 additional locales, I 5x'd my addressable search traffic overnight.

But manually translating 60+ articles into 4 languages? Not happening.

The Stack

Next.js 16 App Router
next-intl v4 for routing and message handling
MDX for content
Claude API for translation
Custom pipeline for batch processing

Architecture: Locale-First File Structure

content/
├── en/
│   └── jerseys/
│       └── michael-jordan/
│           └── bulls-pinstripe.mdx
├── zh/
├── ja/
├── ko/
└── es/

Each locale gets its own content directory. The English version is the source of truth.

Routing with next-intl

export const locales = ['en', 'zh', 'ja', 'ko', 'es'] as const;

export const routing = defineRouting({
  locales,
  defaultLocale: 'en',
  localePrefix: 'as-needed',
});

The as-needed prefix means English URLs stay clean while other locales get their prefix.

The Translation Pipeline

I built a batch translator that reads English MDX, checks which translations are missing, sends to Claude API, and writes translated files preserving frontmatter.

Hreflang: The Critical SEO Piece

Every page needs alternates pointing to its translations. Both in page metadata AND in the sitemap.

Content Fallback Strategy

Missing translations gracefully fall back to English. No 404s.

Results

63 English source articles → 267 total pages across 5 locales
Zero manual translation work
Build time: ~45 seconds for all 267 pages

The site: JerseyToMe

How I Got 98 Pages Indexed by Google in 24 Hours (Without Waiting for Crawlers)

mathew lam — Tue, 12 May 2026 13:22:09 +0000

The Problem With New Sites

You deploy a content site with 100+ pages. You submit your sitemap to Google Search Console. Then you wait.

And wait.

After two weeks, Google has crawled maybe 15 pages. Your carefully written content is invisible. Sound familiar?

I ran into this exact problem with my side project — a 270-page content site across 5 locales. After a week, only ~35 pages were indexed. I needed a faster way.

The Solution: Google Indexing API + Bing URL Submission

Most developers don't know that Google has an Indexing API that lets you proactively notify Google when pages are created or updated. It's not just for job postings anymore — it works for any URL you own.

Step 1: Set Up OAuth2 Credentials

You need a Google Cloud project with the Indexing API enabled:

Go to GCP Console
Create an OAuth 2.0 Client ID (Desktop app type)
Enable the "Web Search Indexing API"
Run the OAuth flow once to get a refresh token

// Exchange refresh token for access token
const response = await fetch('https://oauth2.googleapis.com/token', {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({
    client_id: process.env.GOOGLE_CLIENT_ID,
    client_secret: process.env.GOOGLE_CLIENT_SECRET,
    refresh_token: process.env.GOOGLE_REFRESH_TOKEN,
    grant_type: 'refresh_token',
  }),
});

Step 2: Submit URLs Programmatically

Once you have an access token, pushing a URL is one API call:

async function submitToGoogle(url: string, accessToken: string) {
  const response = await fetch(
    'https://indexing.googleapis.com/v3/urlNotifications:publish',
    {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        Authorization: `Bearer ${accessToken}`,
      },
      body: JSON.stringify({
        url,
        type: 'URL_UPDATED',
      }),
    }
  );
  return response.ok;
}

Step 3: Generate URLs From Your Content

Don't hardcode URLs. Read them from your content directory:

function getAllIndexableUrls(): string[] {
  const urls: string[] = [];
  const contentDir = path.join(process.cwd(), 'content/en');

  // Walk content directory
  for (const file of walkDir(contentDir)) {
    if (file.endsWith('.mdx')) {
      const slug = file.replace(contentDir, '').replace('.mdx', '');
      urls.push(`${SITE_URL}${slug}`);
    }
  }

  return urls;
}

Step 4: Add Bing for Free

Bing's URL Submission API is even simpler — just an API key:

async function submitToBing(url: string) {
  await fetch(
    `https://ssl.bing.com/webmaster/api.svc/json/SubmitUrl?apikey=${BING_KEY}&siteUrl=${SITE}`,
    {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ siteUrl: SITE, url }),
    }
  );
}

Step 5: Run on Every Deploy

Add to your CI/CD pipeline or run manually after deploying new content:

# Submit all URLs
npx tsx scripts/indexing.ts --all

# Or just recently modified
npx tsx scripts/indexing.ts --recent 7

Results

I ran this against 98 URLs on my site. All 98 were accepted by Google's Indexing API in a single run. Within 48 hours, Google Search Console showed a significant jump in indexed pages.

The rate limit is 200 URLs per day, which is plenty for most content sites.

Key Takeaways

Don't rely on passive crawling for new sites — Google may take weeks to discover your pages through sitemap alone
The Indexing API is underused — most tutorials only mention it for job postings, but it works for any verified site
Combine with proper structured data — submit URLs that already have JSON-LD (Article, Product, FAQ schemas) so Google processes rich results on first crawl
Automate it — wire it into your deploy pipeline so new content gets pushed immediately

Bonus: Sitemap Best Practices

While you're at it, fix your sitemap lastModified dates. I see so many Next.js sites doing this:

// ❌ Bad — every page looks "modified today" on every build
lastModified: new Date()

// ✅ Good — use actual content modification dates
lastModified: article.meta.dateModified
  ? new Date(article.meta.dateModified)
  : new Date('2024-01-01')  // fallback to a real date

Google uses lastModified to prioritize which pages to re-crawl. If everything says "today", it trusts nothing.

Full implementation is in my side project: JerseyToMe — an NBA jersey encyclopedia with 270+ pages across 5 languages. The indexing script processes all URLs in under 30 seconds.

I Built a Real-Time NBA Jersey Price Tracker with Next.js, MDX, and Web Scraping

mathew lam — Tue, 12 May 2026 13:18:37 +0000

The Problem

NBA jersey prices are all over the place. The same Mitchell & Ness jersey can be $250 on one site and $180 on another. Resale prices on eBay fluctuate daily. If you're a collector, you're constantly checking multiple platforms to find fair prices.

I wanted a single tool that shows real-time market pricing across retailers — so I built one.

The Stack

Next.js 16 (App Router, static generation)
MDX for content (each jersey has its own article with structured pricing data)
Tailwind CSS 4 for UI
TypeScript end-to-end
Vercel for deployment + analytics
Custom scraping pipeline for price updates

Architecture

The site has 270+ pages across 5 locales (EN, ZH, JA, KO, ES). Every jersey article contains structured pricing data in its MDX frontmatter:

pricing:
  fanatics:
    price: 129.99
    url: "https://..."
  mitchellNess:
    price: 299.99
    url: "https://..."
  ebayAvg: 185
  trend: "rising"

A scheduled agent script scrapes current prices and updates the frontmatter. On build, Next.js generates static pages with Product JSON-LD schema — so Google sees structured pricing data.

The Valuation Tool

The most interesting part is the Jersey Valuation Tool. Users select a player + jersey, and it shows:

Current retail prices (Fanatics, Mitchell & Ness)
eBay average sold price (last 30 days)
Price trend (rising/stable/declining)
Estimated collector value based on era, condition, and rarity

All computed client-side from the static pricing data — no API calls needed at runtime.

SEO Strategy That Actually Works

This is a content site, so organic traffic is everything. Some things that worked:

1. Structured Data on Every Page

Every jersey page has Article + Product + FAQ + BreadcrumbList schemas. Google Rich Results are the goal — showing prices directly in search results.

2. Multi-locale with Proper Hreflang

Using next-intl with 5 locales. Every page has full hreflang alternates in both the HTML <head> and sitemap. This opens up non-English search traffic (huge for basketball content in Asia).

3. Programmatic Content at Scale

Each player hub page is auto-generated from their jersey collection. Team pages aggregate by franchise. Number pages group by jersey number. This creates a dense internal linking structure without manual work.

4. Active Indexing

Passive sitemap submission is too slow for new sites. I built a script that pushes URLs directly to Google's Indexing API and Bing's URL Submission API on every deploy. 98 URLs indexed within days instead of weeks.

Challenges

Affiliate compliance: Every pricing link needs FTC disclosure. Built a component that auto-injects disclaimers.
Stale prices: Prices change daily. The scraping pipeline runs on a schedule, but I still need to handle the "price was X when we checked" transparency.
Image generation: Needed unique hero images for 45+ jerseys. Used AI image generation with careful prompts to avoid trademark issues.

Results So Far

270+ pages indexed
5 language variants
Sub-1s LCP on all pages (static generation FTW)
Structured data validated on 100% of product pages

Still early on traffic — the site is only a few weeks old — but the technical foundation is solid.

Open Source?

Not yet, but thinking about it. The content pipeline (MDX + frontmatter pricing + automated scraping + multi-locale) is pretty reusable for any product comparison site.

If you're building something similar, happy to answer questions about the architecture.

Check it out: JerseyToMe — NBA Jersey Encyclopedia & Price Guide

The valuation tool: Jersey Valuation Tool