ANSWER

Quick answer

Use the public or static convention of the deployed framework. Custom Build Output API projects place public files in .vercel/output/static, where they are exposed from the deployment root without renamed extensions.

Last verified
July 31, 2026
Evidence
Primary documentation plus a route-specific implementation example
Primary sources
2
01

Project paths and constraints

Use the public or static convention of the deployed framework. Custom Build Output API projects place public files in .vercel/output/static, where they are exposed from the deployment root without renamed extensions.

Every deployment has its own immutable URL while the production alias advances. Framework metadata conventions and Output API static files must ultimately resolve in that deployment.

Connected next stepGitHub Pages Favicons: Base Paths and Deployment for the closest prerequisite or comparison.

02

Declare favicon metadata once

Keep link declarations in the framework’s shared document metadata layer. Verify that a rewrite or function route does not shadow /favicon.ico, /favicon.svg, or site.webmanifest.

Let the deployed framework own head generation and keep static assets in its supported public convention. Check route and rewrite rules for collisions with favicon.ico, favicon.svg, and site.webmanifest.

Connected next stepCloudflare Pages Favicons: Assets, Headers and Cache for the next connected implementation decision.

03

Build, deploy, and verify

Check the Resources view for static assets, request each file on the production domain, and compare the preview deployment when a change appears stale. Static files are cached through Vercel’s CDN.

A successful preview does not prove the production alias was promoted, and a rewrite can intercept an asset even when it appears in build output. Compare both responses.

Connected next stepOpen the most relevant production tool and verify the decision with a working output.

04

Compare the immutable preview with the production alias

Open the exact deployment URL first and verify that the expected static resources were included. Then test the production alias after promotion; these hostnames can expose different deployments even though they share a project dashboard.

For every icon response, capture x-vercel-cache, Cache-Control, Content-Type, and final bytes. If a rewrite or function returns application HTML, exclude the asset path before purging the CDN because cache invalidation cannot create an omitted file.

BUILD

Production file tree and code: Vercel static assets and cache policy

The framework should emit these public files before vercel.json applies response headers. Exclude them from catch-all rewrites so the CDN caches image bytes rather than an application page.

FILE TREE
public/
├── favicon.svg
├── favicon.ico
├── apple-touch-icon.png
└── site.webmanifest
vercel.json
JSON
{
  "headers": [{
    "source": "/(favicon\.ico|favicon\.svg|site\.webmanifest)",
    "headers": [{ "key": "Cache-Control", "value": "public, max-age=86400" }]
  }]
}
DOWNLOADABLE EVIDENCE

Review the headings, sources, implementation artifact, and update record for this guide as structured JSON.

Download guide evidence ↓
Primary references
Evidence scope
Guide
Vercel Favicons: Static Files, Rewrites and CDN Cache
Coverage
Client behavior can change by browser, operating system, platform version, cache state and deployment configuration. Unperformed manual observations are not claimed.
Q&A

Questions, answered

Why is the new favicon visible on preview only?+

The production alias may still reference an older deployment, or its CDN object may differ. Confirm promotion and compare the response headers and bytes on both hostnames.

Can vercel.json fix a file absent from the build?+

No. Headers and rewrites operate on deployed output; first ensure the framework copied the icon into its public build result.