Vercel Site Not Showing Up on Google? 8 Causes to Check

By Ugur Saritepe · August 9, 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:

• Zero results.Google hasn't indexed anything. Your problem is one of causes 1–4 below.
• Only the homepage shows. Google found you but is skipping your pages. Look at causes 5–8.
• Pages show, but you get no clicks.This isn't an indexing problem — it's a ranking and content problem, and none of the fixes below will move it. Start with your title tags — they decide whether an impression becomes a click — and for the full picture that case needs a different diagnosis (it's what our Triage Report is built for).

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 — documented in Vercel's knowledge base and confirmed on our own previews while writing this. 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. With Deployment Protection on, previews don't even get that far: they answer 302 straight to a Vercel login page, so a crawler never sees the content at all.

30-second check: run this in a terminal:

curl -sI https://yourdomain.com | grep -i x-robots-tag

Good:nothing prints — production deployments on your own domain don't carry the header. Bad: x-robots-tag: noindex.

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

Your production site is reachable at both yourproject.vercel.app and yourdomain.com — and Vercel does not redirect the twin to your custom domain on its own. We checked our own project while writing this: traffictriage.vercel.app answers 200 with the full page, no redirect, no noindex. 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:two layers. First, make every page's canonical tag — the line that tells Google which URL is the “real” one — point at the custom domain. That's what keeps our own twin harmless: view-source on traffictriage.vercel.app shows <link rel="canonical" href="https://traffictriage.com"/>. Second, redirect the twin: in project Settings → Domains, edit the .vercel.app entry and set it to redirect to your 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. During that wait Search Console often labels your pages Discovered - currently not indexed — normal at this stage, and that status has its own fixes if it persists. 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 pages wait in a render queue and rendering is unforgiving of errors — Google's JavaScript SEO documentation describes the deferred second wave — and 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. Good: your real copy is in the raw HTML. Bad:it's 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.

This is the check worth repeating after every deploy, and it's tedious by hand. If you already work in Claude Code or Cursor, the TrafficTriage MCP server gives your assistant a run_triagetool that answers “is my content in the raw HTML?” in the same chat that can see the component causing it — so the diagnosis and the fix are one conversation.

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 permanent 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"

Good: at most one redirect, then a 200. Bad: two or more HTTP lines before the final 200. 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.

Related symptoms readers search for

Google shows “Vercel” as my site name with no logo, even though my metadata is correct

This is a different problem from everything above: your pages can be indexed and ranking while Google still shows the wrong label under the title link. Google generates the site name in search results automatically. Its documentation on site names says WebSite structured data on your home page is the most important way to state a preference, and that it also considers og:site_name, your <title> element, headings, and other home page text, without promising any order among those. If those sources do not agree on a clear, consistent name, Google can pick something else off the page instead of the name you meant to give it.

30-second check: open view-source on your home page and search for "@type": "WebSite", og:site_name, and <title>, then read the name each one carries. Good: all three exist and agree on the name you want shown. Bad: the WebSite block is missing, or the sources disagree, which leaves Google to guess from whatever else is on the page.

Fix: add WebSite structured data to your home page with a name property set to what you want shown (an alternateName gives Google a second option if the first is rejected), and make sure og:site_name and your <title> say the same thing. The logo follows its own set of requirements: Google only shows a favicon that is a square image, at least 8×8 pixels and ideally larger than 48×48, served through a proper <link rel="icon"> tag. Meeting the requirements still does not guarantee it appears. Both changes need a recrawl to take effect, which Google puts at days to weeks; request one for your homepage in URL Inspection instead of waiting it out.

My yourproject.vercel.app address is ranking instead of my real domain

That is cause 2 above, not a new problem: the .vercel.app twin competing with your domain. Search site:yourproject.vercel.app to confirm it, then fix the canonical tag and redirect the twin the way described there.

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, including the Netlify version — the closest sibling to this one, with the same preview-noindex trap — and the Bubble version.

From experience: the Vercel layer is usually clean

Of the 23 sites we ran through the Triage engine on July 7–8, 2026, four ran on Vercel — and not one of the four failed a hosting-layer check. No stray noindex, canonicals present and pointing at the right host, one site version each. The only flags were second-priority: a temporary 302 redirect where a permanent 308 belongs, one heavy page, and a homepage that opted out of caching. Small sample, but it matches what we see week to week.

It also matches my own launch. My Next.js site on Vercel, game-scout.app, showed nothing in Search Console for weeks and I convinced myself something deep was broken. It wasn't — ordinary indexing lag plus pages too thin to earn a spot. That's the pattern worth remembering: these eight causes are quick to create but also quick to rule out, and once all the checks pass, the blocker is almost never the platform — it's discovery time, or the pages themselves.

FAQ

Why is my Vercel website not showing in Google search results?

In almost every case it's one of eight causes: a preview deployment's noindex header, the .vercel.app twin competing with your domain, Google never being told the site exists, an empty client-rendered HTML shell, redirect chains, a wrong canonical, a leftover robots block, or middleware turning Googlebot away. Search site:yourdomain.com, then run the checks in this guide in order — you'll usually find your cause in about a minute.

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.

Will my Vercel website appear in Google search?

Yes, by default. Production deployments serve normal, indexable HTML with no noindex header, so nothing on Vercel's side keeps your site out of Google. What Google won't do is find it instantly: verify the domain in Search Console, submit your sitemap, and expect the first pages within days rather than hours. Preview deployments are the one exception — Vercel noindexes those on purpose.

Do I need a custom domain for my Vercel site to show up on Google?

No. A production yourproject.vercel.app site returns a normal 200 with no noindex, and Google does index .vercel.app addresses — that's exactly why cause 2 above exists. But the moment you attach a custom domain, handle causes 2 and 6 together: point every canonical at the new domain and redirect the .vercel.app twin, or the two addresses compete and your custom domain looks invisible while the twin keeps the rankings.

In your AI assistant

Ask your AI about your own site

TrafficTriage plugs into Claude, Cursor, and ChatGPT. Your assistant runs the 8 checks, reads your Search Console data, and can even check your site every morning. Free account, no API key, nothing to install.

Sign up freeSee how it works