How to Serve ads.txt with Next.js and Verify AdSense Detection
Place ads.txt in Next.js public, then verify status, media type, publisher ID, robots access, and the separate AdSense recrawl state.
3 min read

In Next.js, a file at public/ads.txt can be served as /ads.txt. Its presence in the repository, however, does not prove successful AdSense detection. The actual Production response and body still need to be checked.
1. Copy the authorized line from AdSense
Use Google's ads.txt guide and copy the line shown for the site. A typical shape is:
google.com, pub-your-account-specific-id, DIRECT, f08c47fec0942fa0
Do not copy or guess the pub-... value from an example. When the file has multiple records, remove blank and exact duplicate lines, but keep the records actually supplied by AdSense or another advertising partner in use.
2. Save it as public/ads.txt
The official Next.js public folder documentation states that files in public are referenced from the base URL.
public/ads.txt → https://registered-host.example/ads.txt
A static record does not need a Route Handler. Keep it outside authentication, HTML templates, and locale prefixes, and save it as plain text.
3. Test the local Production server
Check the production build, not only the development server.
curl -i http://localhost:3000/ads.txt
The expected result is:
- HTTP 200;
- a
text/plainmedia type; - a non-empty body;
- a publisher ID matching the ad loader;
- no HTML, login page, or encoding damage; and
- no exact duplicate records.
4. Test the Production host
After deployment, request the same host that is registered with AdSense:
curl -i https://registered-host.example/ads.txt
Following Google's ads.txt troubleshooting page, verify a root-level HTTP 200 response and make sure robots.txt does not prevent crawling. If a redirect occurs, record the final URL and inspect the final body.
5. Separate deployment time from recrawl time
Record when the Production response was corrected separately from the AdSense dashboard state. Google explains that the file must be recrawled and that a low volume of ad requests can make the process take up to a month.
An unchanged dashboard immediately after an HTTP fix is not evidence that the file should be repeatedly edited. Recheck the response body, publisher ID, and robots rules, then use the dashboard's update check when that option is available.
Symptom checklist
| Symptom | First check |
|---|---|
| 404 | public/ads.txt placement and the Production deployment |
| HTML response | middleware, authentication, locale redirect, or error handling |
| Unauthorized | publisher ID supplied by AdSense versus the file |
| Corrupt text | file encoding and response body |
| Warning remains | deployment timestamp versus recrawl delay |
Compare publisher numbers, not different prefixes
An AdSense ads.txt entry normally uses pub-, while the ad-code client value uses ca-pub-. Compare the corresponding publisher number. Do not change ads.txt to ca-pub- merely because the complete strings differ. Obtain the actual entry from your own dashboard.
After editing, compare the saved file, Git diff, and production response. HTTP 200 does not establish the correct account relationship if the publisher number was copied from someone else's article.
Conclusion
Completion means more than creating a file: /ads.txt on the registered host must return the intended plain text with HTTP 200, and its publisher ID must match the ad code. Running the same checks locally and in Production keeps a placement error separate from an AdSense recrawl delay.
Primary sources checked
Important claims should also link to the relevant source in the article body.
- public FolderVercel · official-documentation · Checked: 2026-07-26
- ads.txt guideGoogle · official-help · Checked: 2026-07-26
- Fix ads.txt issuesGoogle · official-help · Checked: 2026-07-26