Is Google indexing your vercel.app address? How to keep previews and duplicates out of search

Every Vercel project has more addresses than the one on your business card. There is your domain, www.yourcompany.com. There is the production address Vercel creates, your-project.vercel.app. And every deploy gets its own address, plus one per branch for previews.

Most of these never appear in Google, because Vercel takes care of them. One of them usually does, and it competes with your real domain for the same searches. This article explains which is which and how to close the gap.

What Vercel already does #

Vercel adds an X-Robots-Tag: noindex header, which tells search engines not to index the page, to:

• every preview deployment, that is, every deploy from a branch other than production;
• old production deployments: when a new deploy is promoted, the previous one starts answering with noindex.

The current production deployment is left alone, because that is the site you want in search. You can confirm what an address sends with one command:

curl -sI https://your-project-git-feature-team.vercel.app | grep -i x-robots-tag

The two gaps #

1. The production vercel.app address #

your-project.vercel.app serves the same production pages as your domain, without noindex. If Google finds a link to it (an old README, a test you shared, a directory that lists Vercel projects), it has two copies of every page and has to pick one. Duplicates don’t bring a penalty, but they split signals, and Google sometimes picks the address you don’t want.

2. A custom domain on a preview branch #

If you gave a non-production branch its own domain, such as staging.yourcompany.com, Vercel does not add noindex to it. A staging site in Google shows unfinished pages, test prices and duplicate content under your brand.

The fixes #

Redirect the vercel.app address to your domain #

The cleanest fix is a permanent redirect that matches only that host and keeps the path, so your-project.vercel.app/pricing?plan=pro lands on www.yourcompany.com/pricing?plan=pro:

{
  "redirects": [
    {
      "source": "/:path*",
      "has": [{ "type": "host", "value": "your-project.vercel.app" }],
      "destination": "https://www.yourcompany.com/:path*",
      "permanent": true
    }
  ]
}

Matching the exact host matters: a rule without it would redirect your real domain to itself, and a broad pattern would also catch the preview addresses you still need.

Test with a deep page and a query string. You should see a 308 and the right Location:

curl -sI "https://your-project.vercel.app/pricing?plan=pro" | grep -iE "^HTTP|^location"

Make canonicals absolute, on your domain #

Every page should declare its own address on your domain as canonical, written in full: <link rel="canonical" href="https://www.yourcompany.com/pricing">. Two common mistakes:

• Canonicals built from the request host: on your-project.vercel.app, the page declares the vercel.app address as the main one, and the duplicate confirms itself. Build them from a fixed site URL setting.
• Every page pointing to the home page. That asks Google to ignore all your other pages.

Add noindex to preview branches with a custom domain #

For staging.yourcompany.com, add the header yourself, scoped to that host:

{
  "headers": [
    {
      "source": "/:path*",
      "has": [{ "type": "host", "value": "staging.yourcompany.com" }],
      "headers": [{ "key": "X-Robots-Tag", "value": "noindex" }]
    }
  ]
}

Don’t block it in robots.txt instead. A page blocked from crawling can’t be read, so Google never sees its noindex, and the address can still appear in results from links alone.

Turn on Deployment Protection for everything that isn’t production #

In the project settings, Deployment Protection with Standard Protection requires a Vercel login for every address except your production domains, and it is available on every plan. Previews stop being public, which is also good for anything you haven’t announced yet. If an outside service needs to reach a protected preview (a test runner, a client reviewing), Vercel has bypass options for that.

Clean up what Google already has #

If the vercel.app address or a staging domain is already in Google:

1. Deploy the redirect or the noindex first. Google removes pages when it next visits them and sees the change.
2. Search site:your-project.vercel.app to see what is indexed.
3. To hide a page faster, Search Console has a Removals tool. It hides the address for about six months; the redirect or noindex is what makes it permanent.

Don’t delete the project or the domain to make the problem go away: an address that suddenly returns errors leaves Google with nothing to follow, while a redirect passes its history to your domain.

After every deploy #

Settings like these break quietly: a new vercel.json drops the redirect, a framework upgrade changes how canonicals are built. When you check the important pages after a deploy, as in what a deploy can break in your SEO, include the canonical and one request to the vercel.app address.