DEV Community

Ted
Ted

Posted on • Originally published at tedagentic.com

Your Vercel Redirect Is Backwards and Google Is Ignoring Your Site

#vercel #seo #webdev #devops

A week after launching this blog I had one page indexed — the homepage. Every post showed "URL is unknown to Google." No crawl attempts, no impressions, no signal at all.

The site scored 100 on all Core Web Vitals. Sitemap was submitted to GSC on day one. Content was real. There was no obvious technical failure anywhere.

The actual cause: Vercel had www.tedagentic.com set as the primary domain and was redirecting tedagentic.com to it. My GSC property was tedagentic.com. That single configuration mismatch broke the entire indexing chain silently.

What the misconfiguration looks like

Vercel lets you attach multiple domains to a project. One is primary — it serves the content. The others redirect to it. The default when you add both www and non-www is often to make www the primary.

In my case:

tedagentic.com       → 307 redirect → www.tedagentic.com
www.tedagentic.com   → 200 (primary, serves content)
Enter fullscreen mode Exit fullscreen mode

The browser doesn't care. You type tedagentic.com, land on www.tedagentic.com, read the post. Everything looks fine.

Google cares.

Why this kills indexing

The problem compounds across three layers:

1. GSC property mismatch

My Google Search Console property was tedagentic.com (non-www). The site was actually serving from www.tedagentic.com. GSC tracks coverage per property. Pages Google found at www. weren't being credited to the non-www property I was monitoring.

2. Sitemap URLs were wrong

The sitemap is generated dynamically from site.url in the codebase. That value was set to https://tedagentic.com — but because the site was redirecting there, Astro was sometimes resolving the build-time base URL to the www version. The live sitemap was serving this:

<loc>https://www.tedagentic.com/posts/how-to-set-up-local-ai-agent/</loc>
Enter fullscreen mode Exit fullscreen mode

Google downloaded the sitemap from tedagentic.com/sitemap.xml, saw URLs pointing to www.tedagentic.com, and hit contradictory signals on every entry: the sitemap said www, the canonical said non-www, the GSC property was non-www, and the domain had no trust history to resolve the ambiguity. 47 submitted, 0 indexed.

3. Canonical tags contradicted the sitemap

The canonical tags in the HTML were correct — pointing to tedagentic.com. But the sitemap was pointing to www.tedagentic.com. Google had two signals contradicting each other with no clear authority signal to break the tie. On a new domain with no trust built up, it appeared to just stop.

The diagnosis

Run these three checks on any new site before assuming it's a crawl delay:

Check the redirect chain:

curl -sI https://yourdomain.com | grep -E "HTTP|location"
curl -sI https://www.yourdomain.com | grep -E "HTTP|location"
Enter fullscreen mode Exit fullscreen mode

You want yourdomain.com to return 200 and www.yourdomain.com to 308 redirect to yourdomain.com — or the reverse, consistently, as long as it matches your GSC property.

Check sitemap URLs match your canonical domain:

curl -s https://yourdomain.com/sitemap.xml | grep "<loc>" | head -5
Enter fullscreen mode Exit fullscreen mode

Every URL in the sitemap should use the same domain as your GSC property. No exceptions.

Check your GSC property:

Go to GSC and confirm whether you added tedagentic.com or www.tedagentic.com as the property. Then confirm your sitemap URLs and canonical tags use that exact version. All three must match.

The fix

Step 1 — Flip the Vercel redirect via API:

TOKEN="your-vercel-token"
TEAM="your-team-id"
PROJECT="your-project-id"

# Remove both domains
curl -X DELETE "https://api.vercel.com/v9/projects/${PROJECT}/domains/yourdomain.com?teamId=${TEAM}" \
  -H "Authorization: Bearer $TOKEN"

curl -X DELETE "https://api.vercel.com/v9/projects/${PROJECT}/domains/www.yourdomain.com?teamId=${TEAM}" \
  -H "Authorization: Bearer $TOKEN"

# Re-add with correct direction
curl -X POST "https://api.vercel.com/v10/projects/${PROJECT}/domains?teamId=${TEAM}" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"yourdomain.com"}'

curl -X POST "https://api.vercel.com/v10/projects/${PROJECT}/domains?teamId=${TEAM}" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"www.yourdomain.com","redirect":"yourdomain.com","redirectStatusCode":308}'
Enter fullscreen mode Exit fullscreen mode

Step 2 — Fix the site URL in code and redeploy:

Make sure site.url (or equivalent) matches exactly, commit, and push. Vercel will rebuild the sitemap with correct URLs.

Step 3 — Resubmit sitemap and request indexing:

service.sitemaps().submit(
    siteUrl='sc-domain:yourdomain.com',
    feedpath='https://yourdomain.com/sitemap.xml'
).execute()
Enter fullscreen mode Exit fullscreen mode

Then use the URL Inspection API or GSC manually to request indexing on your key posts.

What it cost

Roughly 6 days of early crawl and indexing momentum on a new domain. The site looked healthy the entire time — no errors in GSC, no warnings, no failed crawls. The mismatch was invisible until I ran the redirect check and compared it against the GSC property.

On a new domain, early crawl signals matter more than on an established one. Google is deciding how much trust to extend. A canonical inconsistency during that window is harder to recover from than it would be six months in.

The fix took ten minutes once diagnosed. The diagnosis took a week because there was no visible error to chase.

Quick checklist for new sites on Vercel

  • [ ] Confirm which domain is primary in Vercel (Settings → Domains)
  • [ ] Confirm GSC property matches that exact domain (www vs non-www)
  • [ ] Confirm sitemap <loc> URLs use the same domain
  • [ ] Confirm canonical tags in HTML use the same domain
  • [ ] Verify with curl -sI that the redirect direction is correct
  • [ ] Use 308 (permanent) not 307 (temporary) for the www redirect

Top comments (0)