TrafficTriage

Vercel Site Not Showing Up on Google? The 60-Second Triage

By Ugur Saritepe · July 4, 2026

Your site is deployed on Vercel, it loads fine in the browser, and Google acts like it doesn't exist. Before you rewrite your meta tags or buy an SEO tool, know this: in almost every case it's one of eight specific causes, and you can find out which one is yours in about a minute. This guide covers both the Vercel-side causes and the Next.js-side ones — most sites hit exactly one of them.

The 60-second self-diagnosis

Open Google and search for site:yourdomain.com (your real domain, no spaces). The result tells you which problem family you are in:

One more thing before the causes: be precise about which URL you are testing. A something.vercel.appaddress and your custom domain are two different sites in Google's eyes. Half the confusion in Vercel community threads comes from checking one while the problem lives in the other.

Vercel-side causes (the hosting layer)

1. You're looking at a preview deployment

As of July 2026, Vercel adds an X-Robots-Tag: noindex header to every preview deployment. That's a feature — it stops your work-in-progress branches from getting indexed — but if the URL you shared everywhere is a preview URL, Google is politely obeying your no-entry sign.

30-second check: run this in a terminal and look for x-robots-tag in the output:

curl -sI https://yourdomain.com | grep -i x-robots-tag
If you see noindex: this is your whole problem. Promote a production deployment, point your custom domain at it, and share that URL from now on. Nothing else on this page matters until this is fixed.

2. Your .vercel.app twin is competing with your domain

Your production site is reachable at both yourproject.vercel.app and yourdomain.com. Same content, two addresses — and Google sometimes picks the .vercel.appone as the “real” version, leaving your custom domain looking invisible.

30-second check: search site:yourproject.vercel.app. If that shows results while your domain shows none, Google indexed the twin.

Fix: redirect the .vercel.appURL to your custom domain (Vercel project settings → Domains lets you set the custom domain as primary with a redirect), and make sure your canonical tags point at the custom domain. The twin's pages will drop out on their own after recrawl.

3. You never actually told Google you exist

A brand-new domain with no links pointing at it can take weeks to be discovered on its own. If you launched recently, haven't verified the site in Google Search Console, and haven't submitted a sitemap, there may be nothing broken at all — Google just hasn't met you yet.

Fix: verify your domain in Search Console, submit yourdomain.com/sitemap.xml, and use URL Inspection → Request Indexing on your homepage. First pages typically appear within days after that; a full small site takes one to two weeks. If four or more weeks pass with Search Console verified and still nothing, stop waiting — one of the other causes is blocking you.

Framework-side causes (Next.js and friends)

4. Your HTML is an empty shell

This is the big one for single-page apps deployed to Vercel — Vite or Create React App builds especially. The server sends a nearly empty <div id="root"> and JavaScript fills in the content afterwards. Google can render JavaScript, but rendering is queued, delayed, and unforgiving of errors — many SPA pages simply never make it. Next.js App Router sites are mostly safe here because they render on the server, but content fetched client-side after mount has the same problem.

30-second check: open view-source:https://yourdomain.com(view source, not “inspect element” — inspect shows the page after JavaScript ran) and search for a sentence that appears on your page. Not there? Google has to run your JavaScript to see anything.

Fix: server-render the content that matters. In Next.js, fetch data in Server Components instead of useEffect. For a Vite SPA, pre-render your public pages or migrate the marketing pages to a framework that renders HTML on the server.

5. Redirect chains are eating your crawl

A surprisingly common Next.js self-inflicted wound: setting trailingSlash: true in next.config makes every slash-less URL answer with a 308 redirect. Stack that on top of http → https and www → non-www hops and Googlebot spends its visit bouncing between redirects instead of reading pages — especially if your sitemap lists the pre-redirect URLs.

30-second check:

curl -sIL https://www.yourdomain.com/some-page | grep -i "^HTTP\|^location"

More than one redirect hop before the final 200 is a problem. Fix: make every URL in your sitemap the final, canonical form — same protocol, same host, same trailing-slash style — and collapse the hops so any variant reaches the real URL in one redirect.

6. Your canonical tag points at the wrong site

If your page lives at https://yourdomain.com but its canonical tag says https://www.yourdomain.com — or worse, still says yourproject.vercel.app from before you attached the domain — you have formally instructed Google to ignore the page it just crawled. This usually comes from a hardcoded metadataBase or a copied template.

30-second check: in view-source, find rel="canonical" and read the URL character by character. It must match the address bar exactly.

Fix: set metadataBase (or whatever builds your canonical URLs) to the custom domain, redeploy, and re-check view-source on the live page.

7. A leftover robots block or noindex

Two classics: a robots.txt that blocks /_next/(Google then can't load your JavaScript and CSS, so rendering breaks), and a noindex left in your metadata from staging. 30-second check: open yourdomain.com/robots.txt and make sure nothing disallows /_next/ or /; then search view-source for “noindex”.

8. Middleware treats Googlebot like a stranger

Next.js middleware that redirects logged-out visitors, forces a locale picker, or gates by country will do the same to Googlebot — which is always logged out and crawls mostly from the US. You see your site; Google sees a login page.

30-second check: fetch your page as Googlebot and read the status lines. A 200 on the page itself is good; a 307 or 302 pointing at a login page or locale path means Googlebot is being turned away:

curl -sIL -A "Googlebot" https://yourdomain.com

Fix: let logged-out visitors reach your public pages. Serve a default version at the plain URL and offer the login or language switch on the page — never as a forced redirect in front of it.

The verdict: fix exactly one thing this week

Run the checks in this order and stop at the first hit:

  1. x-robots-tag: noindex in your headers → fix the deployment/domain setup (cause 1). Everything else can wait.
  2. Your content missing from view-source → server-render it (cause 4). Nothing ranks if Google can't read it.
  3. Canonical pointing at the wrong host → fix it and the .vercel.app redirect together (causes 2 + 6). They are usually the same misconfiguration.
  4. Redirect chains or robots/noindex leftovers → tidy them (causes 5 + 7).
  5. None of the above and the site is under four weeks old → you are cause 3. Submit the sitemap, request indexing, and genuinely wait. Impatience here leads to breaking things that were fine.

How to confirm the fix worked

Re-run the 30-second check that caught your cause — the header grep, the view-source search, the redirect trace. It should now show the good output. Then open URL Inspection in Search Console for the page you fixed and click Request Indexing. Recrawl typically happens within days; give it a full week before deciding the fix didn't take. If the check passes but pages still don't appear after that week, go back down the verdict list — a second cause was hiding behind the first.

Hosting somewhere other than Vercel? The same triage exists for other hosts in our platform guides.

From experience: it's never exotic

I went through this with my own Next.js site on Vercel, game-scout.app. I launched, watched Search Console show nothing for weeks, and convinced myself something deep was broken. It wasn't — it was ordinary indexing lag plus pages that were too thin to earn a spot. The first real clicks eventually came from specific long-tail pages, not the homepage, and not from any clever trick. The lesson baked into this guide: find the one real blocker, fix it, and put the rest of your energy into pages worth indexing.

FAQ

How long until a new Vercel site shows up on Google?

With Search Console verified and a sitemap submitted: first pages typically within days, a small site fully within one to two weeks. Without them, discovery can take much longer. Past four weeks with Search Console verified and zero pages indexed, assume a blocker from the list above.

Does hosting on Vercel hurt SEO?

No. The platform serves fast, crawlable pages, and its one aggressive default — noindexing preview deployments — protects you. Every “Vercel SEO problem” in this guide is a configuration issue, not a platform penalty.

Is Next.js bad for SEO?

The opposite, when used as designed: the App Router server-renders by default, which is exactly what Google wants. Problems come from client-only content, mismatched canonicals, and redirect chains — all fixable in an afternoon.

Not sure which cause is yours?

Get a free Triage Report: eight checks run from your URL alone — no Search Console access needed — each scored Critical / Monitor / Healthy, ending with the one thing to fix this week. Delivered by email within 48 hours.

Request your free Triage Report →