How to Fix the ads.txt 500 Error on Next.js App Router with Vercel

bi kai — Fri, 15 May 2026 07:22:07 +0000

If you've ever tried to apply for Google AdSense with a Next.js App Router site deployed on Vercel, you may have run into a frustrating issue: visiting your-domain.com/ads.txt returns a 500 Internal Server Error, even though the file exists in your public/ directory and works fine in local development.

This post explains why it happens and shares the cleanest fix I found while preparing my own site for AdSense submission.

The Problem

The conventional way to serve ads.txt is to drop it into the public/ directory.

In a Pages Router project, this works without issue. But with the App Router on Vercel, you might see one of these symptoms:

your-domain.com/ads.txt returns 500 in production
The file works fine on localhost:3000 during next dev
AdSense crawler reports the file as unreachable
DevTools shows a non-zero response but empty content, or a hard server error

This is particularly annoying because AdSense requires a properly served ads.txt for site authorization, and the failure mode is silent — you only notice when AdSense flags your site weeks later.

Why It Happens

The root cause is a routing precedence quirk between App Router's matching system and Vercel's static file handling.

In App Router, file-based routes are evaluated before static assets in public/ in certain edge cases. When ads.txt is requested:

App Router tries to match /ads.txt against its route tree
Because .txt isn't a recognized App Router file extension, the matcher enters an undefined state
On Vercel's edge runtime, this manifests as a 500 instead of falling through to the static file
Locally, the dev server's looser matching often masks the issue

The behavior is inconsistent enough that it slips past local testing and only shows up after deployment.

The Fix: Route Handler

Instead of relying on public/, define ads.txt as an App Router Route Handler at app/ads.txt/route.ts with this content:

export async function GET() {
  const publisherId = process.env.ADSENSE_PUBLISHER_ID ?? '';

  // ads.txt requires the "pub-" form without the "ca-" prefix
  const cleanId = publisherId.replace(/^ca-/, '');

  const content = cleanId
    ? `google.com, ${cleanId}, DIRECT, f08c47fec0942fa0`
    : '';

  return new Response(content, {
    headers: {
      'Content-Type': 'text/plain',
      'Cache-Control': 'public, max-age=0, must-revalidate',
    },
  });
}

A few details worth noting:

The handler reads your publisher ID from an environment variable, so the same code works across staging and production.
ca-pub-XXXXXXXXXXXXXXXX is the format AdSense gives you, but ads.txt wants pub-XXXXXXXXXXXXXXXX — the regex strips the ca- prefix automatically.
Cache-Control: must-revalidate ensures AdSense always sees the latest content if you ever rotate IDs.
When ADSENSE_PUBLISHER_ID is not set, the route returns an empty 200 response instead of crashing — useful during AdSense pre-approval when you don't have a publisher ID yet.

Setting the Environment Variable on Vercel

Once your AdSense application is approved and you have your publisher ID:

Go to your Vercel project, then Settings, then Environment Variables
Add ADSENSE_PUBLISHER_ID with value ca-pub-XXXXXXXXXXXXXXXX
Apply to Production (and optionally Preview/Development)
Trigger a redeploy — environment variables don't apply retroactively to existing deployments

Verifying It Works

After deployment, verify the response headers with curl:

curl -I https://your-domain.com/ads.txt

You should see HTTP/2 200 and content-type: text/plain.

Then check the body:

curl https://your-domain.com/ads.txt

The expected output is google.com, pub-XXXXXXXXXXXXXXXX, DIRECT, f08c47fec0942fa0.

For additional validation, paste your domain into the adstxt.guru validator — it parses the file the same way AdSense does and catches formatting issues.

Common Mistakes to Avoid

A few things I tripped over during my own setup.

Don't leave the ca- prefix in the output. The format google.com, ca-pub-XXX, DIRECT, ... is invalid. AdSense's verification will fail silently. Always strip it.

Don't forget to redeploy after changing the environment variable. Vercel does not apply env var changes to existing deployments — only new builds pick them up.

Don't test only on localhost. This entire bug is invisible in next dev. Always verify the deployed URL.

Don't add multiple files. If you have both public/ads.txt and app/ads.txt/route.ts, the behavior is undefined. Pick one — the Route Handler is more reliable.

Closing Notes

I ran into this exact issue while preparing my own side project for AdSense — a free browser-based harmonium for Indian classical music practice at playharmonium.com. The site uses Next.js App Router on Vercel, and the ads.txt 500 error was the last thing blocking the application. The Route Handler approach above is what I ended up shipping, and the file has been served reliably since.

If you're going through AdSense setup yourself and hit the same wall, I hope this saves you a few hours of head-scratching. Drop a comment if you've found other quirks worth documenting.

DEV Community: bi kai