Forem: Ted

A Vercel Catch-All Rewrite Caused 190 Pages to Canonicalize to the Homepage

Ted — Tue, 26 May 2026 07:56:21 +0000

I run a React/Vite SPA deployed on Vercel. The site had been live for months. GSC was showing 190+ pages in the "Discovered — currently not indexed" bucket. Not penalised, not crawled and rejected — just never indexed.

The cause turned out to be one line in vercel.json.

How a catch-all rewrite breaks indexing

Vercel needs to know what to serve when someone hits a client-side route like /city/denver directly. Since there's no dist/city/denver/index.html, the default behavior is to rewrite all unmatched paths to dist/index.html — the homepage shell.

{
  "rewrites": [{ "source": "/(.*)", "destination": "/index.html" }]
}

The homepage shell has a canonical tag:

<link rel="canonical" href="https://example.com/" />

So when Googlebot hits /city/denver, it receives the homepage HTML and reads canonical: https://example.com/. On a low-trust domain, Google appeared to deprioritize further crawling of those routes — treating them as duplicates of the homepage rather than returning to index them independently.

┌──────────────────────────────────────────────────────────┐
│              WHAT GOOGLEBOT SAW                          │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  GET /city/denver                                        │
│       │                                                  │
│       ▼                                                  │
│  Vercel catch-all: serves dist/index.html               │
│       │                                                  │
│       ▼                                                  │
│  <link rel="canonical" href="https://example.com/" />   │
│       │                                                  │
│       ▼                                                  │
│  Google: signals duplicate of homepage                  │
│          deprioritizes further crawling                  │
│                                                          │
│  Result: 190 pages sitting in "Discovered, not indexed" │
└──────────────────────────────────────────────────────────┘

The fix is to generate a real dist/[path]/index.html for every route before Vercel deploys. That way the catch-all never fires for known routes — Vercel serves the real file.

The prerender system

The build command:

"build": "vite build && node scripts/prerender.mjs"

prerender.mjs runs after Vite. It walks STATIC_ROUTES — a flat array of every known path — and writes a proper dist/[path]/index.html for each one. Each file gets:

A correct <title> for the route
<meta name="description"> with real content
<link rel="canonical"> pointing to the actual URL
Injected body content inside #root so Googlebot sees real text without executing JS

For detail pages, the script fetches live data from the database at build time and writes real names, ratings, addresses, and descriptions into the HTML.

If a path is in STATIC_ROUTES, Vercel finds the pre-built file and serves it directly. The catch-all only fires for paths that genuinely don't exist.

The 4-commit audit

Once I confirmed the mechanism, I audited every route type and ran four commits in sequence.

Commit 1 — Blog slugs

Seven blog posts were missing from STATIC_ROUTES. They had been published directly without updating the prerender list. Every one of them was being served as the homepage.

Added the slugs, rewrote thin bodies on three entries using GSC impression data — queries with 60–70 impressions and zero clicks, showing Google was finding the topic but landing on content that couldn't hold it.

Commit 2 — Crawl budget

The site had out-of-state listing pages — pages for locations outside the primary geography with no real search demand. They weren't indexed but they were being crawled on every Googlebot pass.

Added noindex: true flag support to the HTML generator and set seven of these pages to noindex. Googlebot stops spending crawl budget on them.

function generateHtml({ path, title, description, canonical, body, noindex = false }) {
  const robotsMeta = noindex
    ? '<meta name="robots" content="noindex, nofollow" />'
    : '<meta name="robots" content="index, follow" />';
  // ...
}

Eight additional ghost-town pages were also noindexed — locations with no tourism infrastructure, no search volume, and no database data to populate them with.

Commit 3 — City pages

29 city-level pages existed in STATIC_ROUTES but had generic one-sentence bodies:

Browse listings in Denver.

Replaced each with unique content — elevation, specific listing names, local context, tourism details. Not template-swapped: each city got its own paragraph based on what made it distinct.

┌─────────────────────────────────────────────────────────┐
│                BEFORE / AFTER                            │
├─────────────────────────────────────────────────────────┤
│                                                          │
│  BEFORE                                                  │
│  "Browse listings in Denver."                           │
│                                                          │
│  AFTER                                                   │
│  "Denver sits at 5,280 feet. [Listing A] in RiNo and   │
│  [Listing B] near Capitol Hill are highest-rated.       │
│  Most visitors from sea level report altitude effects   │
│  within the first day — start low."                     │
│                                                          │
└─────────────────────────────────────────────────────────┘

Commit 4 — Detail page enrichment

Individual listing pages were getting auto-generated one-liners. The prerender already had the database connection — it just wasn't using it for detail pages.

Added two enrichment loops that pull real data per slug:

for (const [slug, data] of Object.entries(dispensariesBySlug)) {
  const path = `/listing/${slug}`;
  routes[path] = {
    title: `${data.name} — Directory`,
    description: `${data.name} in ${data.city}. Rating: ${data.rating}/5.`,
    body: buildDetailHtml(data),
  };
}

Every matched detail page now has real name, rating, review count, type, address, and description injected at build time.

What got submitted to GSC

After the four commits deployed, I submitted blog URLs via GSC's URL Inspection tool and queued the rest for the following day after hitting the daily limit. City and detail pages surface through the sitemap on the next crawl cycle.

┌─────────────────────────────────────────────────────────┐
│                  ROUTE STATUS AFTER AUDIT                │
├─────────────────────────────────────────────────────────┤
│                                                          │
│  Blog pages              →  correct canonical + body    │
│  Out-of-state listings   →  noindexed                   │
│  Ghost town pages        →  noindexed                   │
│  City pages (29)         →  unique content injected     │
│  Detail pages            →  real DB data injected       │
│                                                          │
│  Catch-all fires only for paths that don't exist        │
└─────────────────────────────────────────────────────────┘

The check that catches it

After any prerender change, before pushing:

npm run build
curl -s http://localhost:4173/your-route | grep -i 'canonical'

If you see canonical: / on a page that isn't the homepage, the catch-all is winning. A route is missing from STATIC_ROUTES or the prerender write failed silently.

The other check is in Vercel build logs — the prerender should log a row count for every data fetch. If it logs zero or logs nothing, the database connection failed and detail pages are running on fallback content. Treat zero as a failure, not a warning.

Why this is easy to miss

The system behaved correctly at every layer. Vite built the bundle. The prerender ran. Vercel deployed green. The site worked perfectly in a browser — React hydrated immediately and the correct content appeared.

Only a raw HTTP request exposed the problem:

curl -s "https://example.com/city/denver" | grep canonical
# <link rel="canonical" href="https://example.com/" />

Googlebot doesn't execute JavaScript. It reads what the server sends. Everything the human-facing monitoring stack measured was post-hydration. The failure existed entirely in the gap between what the server sent and what the browser rendered — a gap that only matters to crawlers.

OpenClaw vs Hermes Agent: Similarities, Differences, and Where Each Shines

Ted — Sun, 24 May 2026 02:14:39 +0000

Both OpenClaw and Hermes Agent are open-source, self-hosted, and connect to Telegram. If you're evaluating which one to run, that surface-level similarity makes the choice look harder than it is. They're built on different philosophies and solve different problems.

Here's a direct breakdown from someone running both on the same machine.

What they have in common

Open-source and self-hosted — no SaaS dependency
Connect to Telegram (and other messaging platforms)
Support multiple LLM providers via OpenRouter, Ollama, Anthropic, and others
Run as persistent background services (systemd)
Have memory systems for retaining context
Support tool use — terminal access, file operations, web browsing
Can be triggered on demand or on a schedule

The core difference

OpenClaw is gateway-first. Hermes is agent-first.

OpenClaw is designed around a messaging hub. You connect it to your platforms, configure plugins and models, and it becomes a command center for executing tasks and delivering scheduled outputs. The workflow is defined by you upfront.

Hermes is designed around an agent that learns. The messaging integration is how you reach it — but the focus is on the agent building knowledge about you over time and using that to work with less steering.

Memory: same feature, different approach

Both have memory. The difference is how it works.

OpenClaw uses structured, file-based memory — Markdown files, a vector-indexed memory-wiki, and periodic consolidation. You control what gets stored. You can read and edit the files directly. It's transparent and predictable, but requires some manual involvement to stay useful.

Hermes writes memory automatically after every session. Hermes autonomously decides what to persist — your preferences, your stack, your patterns — without you configuring anything. It compounds over time on its own.

Where OpenClaw shines

Scheduled automation — cron job delivery, morning reports, recurring alerts
Multi-platform routing — Telegram, Discord, Slack, WhatsApp from one gateway
Plugin ecosystem — mature, community-built skills and integrations
Reliability — designed to run 24/7 without intervention
Transparency — you define exactly what it does and when
Predictability — deterministic workflows mean easier debugging, no operational drift, and explicit control over every boundary

Best for: operators who want dependable, configured automation running on a schedule — and who prefer constrained systems where behavior is always explainable.

Where Hermes shines

Persistent memory — autonomously builds and maintains context across sessions
Reduced steering — the longer it runs, the less you have to repeat yourself
Autonomous task decomposition — give it a vague goal, it figures out the steps
Skill authoring — turns successful workflows into reusable, versioned skills
System awareness — can scan your machine and build a working model of your setup

Best for: operators who want an agent that gets more useful over time without manual configuration.

Where each falls short

OpenClaw — long-term continuity requires deliberate memory maintenance from the operator. The system is only as aware as what you've explicitly stored. Heavy orchestration workflows also need upfront plugin work.

Hermes — newer, heavier to set up, smaller ecosystem. Free models handle light tasks but will struggle with deep reasoning. Still building the community and skill library that OpenClaw already has.

In practice: the same task, two different behaviors

Task	OpenClaw	Hermes
Morning SEO report	Deterministic cron — runs at 8:30am, delivers the same structured output every day	Contextual — can flag anomalies, cross-reference previous sessions, surface patterns
Telegram command	Fast execution, plugin-defined scope	More contextual responses, draws on accumulated session history
Follow-up 3 days later	Requires explicit context — you re-explain your setup	Retains prior context automatically — no re-steering needed
New automation task	You define the plugin/prompt upfront	Can decompose the goal into steps and build a reusable skill
System awareness	Knows what you configured it to know	Can scan the machine and build its own working model

The verdict

They're not competing for the same job — which means you don't have to choose.

Run OpenClaw for execution: scheduled scripts, cron delivery, real-time Telegram commands, monitoring. It's the better runtime.

Run Hermes for intelligence: tasks where context from previous sessions matters, complex planning, anything where you want the agent to reduce how much hand-holding it needs over time.

The strongest setup is both as a stack: OpenClaw for orchestration, Hermes for adaptive reasoning and continuity.

Your Vercel Redirect Is Backwards and Google Is Ignoring Your Site

Ted — Sun, 24 May 2026 02:13:08 +0000

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)

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>

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"

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

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}'

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()

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

Google Was Rewriting My Title. The Cause Was a Single JSX Element.

Ted — Fri, 22 May 2026 06:19:02 +0000

A page I manage was sitting at position 1 for its primary keyword. Over about three weeks it slid to position 9. When I checked the SERP on mobile vs desktop, the title showing in results was different on each device — and neither matched the title tag in the HTML.

That's the tell. Google doesn't rewrite titles randomly. It rewrites them when the page gives it a better candidate string than the one in <title>. I had done exactly that, without realising it.

The two causes

1. Title tag over the display limit

Google's rendered title in search results is constrained to roughly 600px width — around 55–60 characters depending on the character set. When the <title> tag exceeds that, Google looks for a shorter, cleaner alternative on the page: the H1, a prominent heading, or any large text near the top of the document.

My title tag was 69 characters. Not catastrophic on its own, but it opened the door.

2. Subtitle span nested inside the H1

This was the actual cause. The pattern looked like this — examples below are illustrative, but this structure appears on any content page with a heading and a subtitle:

<h1 className="text-4xl font-bold">
  Best Coffee Shops in Austin
  <span className="text-muted-foreground text-2xl">
    2026 Neighborhood Guide – Updated Weekly
  </span>
</h1>

To a human reading the rendered page, this looks like a heading with a subtitle underneath it. To Google's parser, it reads the entire <h1> content as one string:

Best Coffee Shops in Austin 2026 Neighborhood Guide – Updated Weekly

That's longer than intended — and in my case it also contained stale data that had since changed. Google preferred the H1 string, started using it, and because it was being pulled from the DOM rather than the <title> tag, it varied depending on how the page rendered (full JS execution on desktop vs partial on mobile), producing different titles per device.

The fix

Two changes:

1. Shorten the title tag to under 60 characters

<!-- before: 69 chars — over the display limit -->
<title>Best Coffee Shops in Austin — 2026 Neighborhood Guide by Area</title>

<!-- after: under 60 chars -->
<title>Best Coffee Shops in Austin 2026 — By Neighborhood</title>

2. Move the subtitle out of the H1

// before — subtitle inside H1, Google reads as one string
<h1 className="text-4xl font-bold">
  Best Coffee Shops in Austin
  <span className="text-2xl text-muted-foreground">
    2026 Neighborhood Guide – Updated Weekly
  </span>
</h1>

// after — separate elements, Google reads H1 cleanly
<h1 className="text-4xl font-bold">
  Best Coffee Shops <span className="text-accent">in Austin</span>
</h1>
<p className="text-2xl text-muted-foreground">
  2026 Neighborhood Guide – Updated Weekly
</p>

The <p> is no longer semantically part of the heading. Google now has a much cleaner, more consistent title candidate from the <title> tag and one matching candidate from the <h1>. No competition, no rewriting.

What GSC showed after

Position movement on the main queries within one week of the fix:

Query	6-month avg	7-day post-fix
primary head term	6.5	3.6
secondary variant	6.8	3.0
branded + modifier	5.3	4.1
long-tail variant	6.4	4.7

CTR also moved from 9.9% (6-month baseline) to 11.6% in the first week — the clean title converts better in the result snippet because it's not being truncated or substituted.

The pattern to watch for

In React and JSX, it's easy to put display-only text inside a heading element for layout convenience. A <span> with reduced font size inside an <h1> looks like a subtitle visually but is semantically part of the heading. Google sees the full concatenated string.

Any time you have secondary text near a heading — a date, a price, a tagline — check whether it's inside the heading element or adjacent to it. If it's inside, and your title tag is already near the character limit, you're handing Google an alternate title it may decide to use.

The fix is always the same: move the secondary text to a <p> or <span> outside the heading. One element change. The heading stays visually identical; the semantic structure is now correct.

The Confidence Gap: How AI Introduces Silent Errors on Production Sites

Ted — Thu, 21 May 2026 04:39:34 +0000

The task looked routine. Update a comparison table on a live page — add a new property, adjust a few rows, push to production. The AI completed it, reported it done, and I moved on.

Two months later, a third-party analysis flagged an entity conflict: a property was listed in the wrong city. Not the wrong building or the wrong street — the wrong city entirely. One was 100+ miles from where the page said it was. The page had been live, indexed, and receiving organic traffic the whole time.

The page loaded fine. No build errors. No type errors. No 404s. Nothing indicated anything was wrong.

That's the confidence gap.

What happened

The AI was tasked with building a property comparison table from scratch. It needed names, locations, prices, and policies for each entry. Some values existed in the database. Others the AI inferred from surrounding page content and previously generated text.

It didn't label those inferences as guesses. It just wrote them. And then reported the task complete.

Here's what the error looked like — anonymised, but structurally identical to the real failure:

Property	Correct city	What the page said
Property A	Morrison	Pueblo
Property B	Manitou Springs	Colorado Springs
Property C	Denver	Fort Collins

Three properties. Three wrong cities. All live, all indexed, all quietly sending wrong signals to Google's entity model.

The specific mechanism: one property's city field was inferred from surrounding prose on the page — prose that had itself been written by a previous AI task. The error was already baked in before the table was built. When the AI read that text as context, it accepted it as fact, and propagated it forward into the new table.

AI wrote it wrong. AI read it back. AI wrote it wrong again.

That's not a hallucination — it's a feedback loop. And unlike a hallucination, it's internally consistent. Nothing on the page contradicts itself. The error is coherent. That's what makes it invisible.

Why the feedback loop matters

Google's entity model doesn't just read your content — it cross-references it. When a page describes a property as being near a specific landmark, but the location field places it 100 miles away, that's a geographic contradiction. The entity resolver flags it. That's a real SEO signal, and it works against you silently, the same way the error was introduced.

This is the part that makes the feedback loop worse than a one-time mistake. A single wrong fact might degrade one page. A wrong fact that gets read back and propagated spreads across the site — each new page adding another source of the same contradiction, compounding the entity signal problem.

Why confidence is the actual problem

Most AI failures are obvious. The code doesn't compile. The page crashes. The API returns an error. You see it immediately.

This failure class is different. The output is syntactically and visually correct. A human skimming the table would not notice unless they already knew the right answer. The AI's tone when reporting completion — "done, pushed" — is identical whether it verified the fact or invented it.

That's the confidence gap: the signal you'd use to detect a problem (confident completion) is the same signal the AI emits when everything is fine.

The gap is especially dangerous on commercial sites because:

Content is published and indexed fast
Errors compound across pages — wrong fact in one place gets read back and written into the next
The business stakes are real — wrong location data affects SEO entity signals, user trust, and affiliate conversions

A developer making this mistake would usually notice when they went to verify the property existed. The AI skips that verification step entirely unless it's explicitly required.

The audit

After finding the first error, the right move was a full audit — not just fixing the one instance and moving on.

The process:

Query the database directly for source-of-truth values on every property: name, city, address
Compare each hardcoded reference on each page against the DB record — not against other page content
Flag discrepancies before touching anything
Fix only confirmed errors, one at a time, with a pre-push summary table every time

Across 40 pages audited, the full damage report:

Error type	Count
Wrong city	3 properties
Wrong name	2 properties
Inconsistent rating	6 instances
Total corrections	9+

All of these had been live. None had triggered any automated alert.

The key discipline: the database is the source of truth, not the page. Auditing a page against itself finds nothing — it just confirms the error is internally consistent. You have to go upstream.

The process change

Going forward, the rule is simple: no property detail gets written without a verified source. If the city isn't in the DB record, you ask for it. You don't fill the gap.

Before every push to a commercial site, a pre-push summary table is required:

File	Field	Before	After
ExamplePage.tsx	location	Old value	Verified value

The human reviews that table before the commit happens. Not after.

This doesn't eliminate AI mistakes — it makes them visible before they go live. That's the only realistic bar. AI tools will continue to infer values from context when they don't have a verified source. The operator's job is to build a process that catches that gap before it ships.

What this means for operators

If you're using AI to build or maintain a commercial site, assume there are errors you haven't found yet. The absence of visible problems is not evidence of accuracy.

The most dangerous AI outputs are the ones that look right. Code that doesn't compile gets fixed immediately. Content that's factually wrong but grammatically perfect sits in production for months — getting indexed, getting read back, getting propagated.

Run your audit from the source of truth, not from the page. Build the pre-push review into the workflow before something gets indexed. And treat AI confidence as a neutral signal — it tells you the task completed, not that the output is correct.

The gap between those two things is where production errors live.

Vercel Stopped Deploying. No Alert. No Error. Just Old Code.

Ted — Wed, 20 May 2026 03:04:56 +0000

I pushed a set of changes to a production site — new page sections, updated prerender content, a comparison table entry. Checked the live site an hour later. Nothing had changed.

Checked Vercel. Project showed healthy. No red deployments, no failure notifications, no emails. The dashboard looked completely normal.

Checked the Deployments tab. Last deployment: 10 hours ago. Not two minutes ago when I pushed. Ten hours.

Every commit had gone to GitHub fine — verified with git log, confirmed the remote had the latest SHA. Vercel simply hadn't picked any of them up.

What I ruled out first

GitHub webhook disconnected. Possible on any project if the GitHub app gets uninstalled or permissions change. But the Vercel project still showed the repo as connected. No indication of a broken webhook in settings.

Root directory misconfigured. There was a nested subfolder in the repo that had previously been used as the build root. That subfolder had been deleted. If Vercel was building from that path, every build would fail with a missing directory error. But the Root Directory setting showed ./ — the repo root. Ruled out.

Build command issue. Nothing had changed in package.json or vite.config.ts. The build had worked before.

Forcing a deploy to see the actual error

With the GitHub webhook not triggering, the only way to get a build log was to force a deploy manually. Used the Vercel CLI:

vercel --prod

Immediate error:

{
  "status": "error",
  "reason": "deploy_failed",
  "message": "Redirect at index 0 cannot define both `permanent` and `statusCode` properties."
}

There it was.

The config conflict

In vercel.json, the first redirect — a www-to-non-www canonical redirect — had been written with both properties:

{
  "source": "/(.*)",
  "has": [{ "type": "host", "value": "www.yourdomain.com" }],
  "destination": "https://yourdomain.com/$1",
  "permanent": true,
  "statusCode": 301
}

permanent: true and statusCode: 301 are redundant — permanent: true already means 301. Vercel's config validator rejects any redirect that specifies both. The fix is one line:

{
  "source": "/(.*)",
  "has": [{ "type": "host", "value": "www.yourdomain.com" }],
  "destination": "https://yourdomain.com/$1",
  "permanent": true
}

Why it was silent

This is the part worth documenting.

When a vercel.json config error fails validation, the GitHub webhook fires, Vercel receives it, validation fails before the build even starts, and the whole thing is discarded quietly. In this case, Vercel surfaced no visible failure notification in the dashboard or by email. The dashboard keeps showing the last successful deployment as if nothing happened.

The only visible sign is that the "Last deployment" timestamp stops advancing. If you're not actively checking that timestamp, you won't notice.

The failure was introduced with a commit that added statusCode: 301 to an existing redirect that already had permanent: true. The intent was clarity. The effect was silently breaking every deployment after it.

Secondary issue: CLI upload was stalling on node_modules

When I first ran vercel --prod to diagnose, the upload stalled at ~150MB and had to be killed. There was no .vercelignore in the repo, so the CLI was uploading node_modules (357MB) along with the source.

Fix:

# .vercelignore
node_modules
dist
.git
*.log

With that in place the upload dropped to ~39MB and completed in seconds.

What to check when Vercel stops auto-deploying

If pushes are going to GitHub but Vercel isn't deploying:

Check the Deployments tab timestamp — if it stopped advancing, builds are failing before they start
Force a deploy via CLI (vercel --prod) — the CLI surfaces the actual error immediately, the dashboard won't
Look at vercel.json first — config validation errors fail silently and are the most common cause of webhook builds being discarded without notification
Check for redundant redirect properties — permanent and statusCode on the same redirect is the specific conflict Vercel rejects

The GitHub integration kept working. The pushes were fine. The config was wrong. Vercel's silence on the failure is the thing that made it hard to find.

Lovable Shipped SSR. Here's What That Actually Changes.

Ted — Wed, 20 May 2026 03:01:39 +0000

Today Lovable's co-founder announced they're shipping SEO as a first-class feature: new apps are now server-side rendered, and existing apps get pre-rendering automatically.

The timing is notable. I published a post about a prerender pipeline I built manually for a Lovable site — one that ran on every deploy, silently failed for six months because of missing environment variables, and left four directory pages with zero GSC impressions the entire time. Lovable just made that class of problem their problem, not yours.

So: does this change the argument from Part 1?

The short answer is: partially. It fixes the crawlability problem. It doesn't close the performance gap, and the two paths they've shipped are actually quite different.

What they shipped

New apps: server-side rendering. Every request hits a server, which renders HTML dynamically and sends it to the browser. Googlebot gets real content on the first request — same as SSR frameworks like Next.js in default mode. The CSR crawlability problem is gone for new projects.

Existing apps: automatic pre-rendering. Build-time pre-rendering injects static HTML into the page before the React bundle runs. This is exactly the approach I was doing manually — a script that fetches data at deploy time and writes it into the HTML. Lovable is now doing this automatically.

These are two different things. Worth naming them separately.

What pre-rendering for existing apps actually means

The pre-rendering path for existing apps is a patch on CSR, not a structural fix. The React bundle still ships. The browser still downloads it, parses it, executes it, and hydrates. The pre-rendered HTML is injected at build time — so it's only as fresh as the last deploy.

What it fixes: Googlebot's first-wave crawl now gets real content instead of an empty shell. That's the thing that was causing pages to drop out of the index.

What it doesn't fix: the client-side hydration overhead. The performance characteristics are still those of a React CSR app — full JS bundle, hydration on every page load, PageSpeed scores that require active optimization to keep above 80.

The silent failure mode I documented — where the pre-render ran but the data fetch failed quietly and injected a placeholder — that risk goes away when Lovable controls the pipeline. They can test it. They can fail loudly. They can handle env vars correctly by default. The failure mode I hit was an implementation problem with a DIY script, not an inherent limit of pre-rendering. Lovable's version will be more reliable.

What SSR for new apps actually means

Server-side rendering is a real architectural change, not a patch. Every request hits a server, which generates HTML with current data and sends it. Googlebot sees real content. Users see real content on the first byte.

This puts Lovable new apps in the same rendering category as Next.js with getStaticProps or a hybrid SSR setup — crawlable, indexable, real HTML on first request.

The tradeoff SSR carries that SSG doesn't: every request has server latency. A static site serves from a CDN edge node — the file is already built, it just needs to travel from the nearest edge to the user. An SSR app has to compute the response first. For content that doesn't change per-user, that compute step is unnecessary overhead.

Static site (SSG/Astro)          SSR (Lovable new apps)
──────────────────────           ──────────────────────
Request → CDN edge               Request → server
           ↓                                ↓
         file served             render HTML (with live data)
         immediately                        ↓
                                      send to browser

TTFB: ~30–80ms (edge)            TTFB: ~200–500ms+ (server)

For an app — a tool, a dashboard, something with real interactivity or user-specific data — SSR is the right call. The server compute is justified because the content is actually dynamic.

For a content blog where every page is the same for every visitor, SSG is still faster. The HTML is already there. No server needed.

When the Astro argument still holds

For pure content sites — blogs, documentation, resource hubs — the case for SSG hasn't changed. Astro ships zero JavaScript by default. Every page is a file on disk served from the CDN edge. There's no server to maintain, no per-request compute cost, and no JS bundle penalty on performance metrics.

My Astro blog consistently scores 95+ on mobile PageSpeed. A Lovable SSR app will score lower without active optimization — not because SSR is bad, but because it ships a full React bundle on every page and adds server latency to every request.

For content sites that need real interactivity — some dynamic widgets, user-facing forms, live data sections alongside static content — Lovable SSR is now a legitimate option where it wasn't before. The crawlability problem is solved. You're trading some performance headroom for faster development.

For existing Lovable sites with the CSR problem: the automatic pre-rendering means the indexability issue gets handled without a DIY script. The performance characteristics don't change, but the SEO floor is now reliable.

The actual update to Part 1

Part 1 said: "Lovable is built for apps, not blogs. But plenty of people use it for content sites anyway — that's the mistake this post is about."

The update is: Lovable is now credible for content sites that need interactivity. New apps are SSR — crawlable, indexable, real HTML on first request. The mistake that post was about (using a CSR framework for a content site and watching pages disappear from the index) is no longer baked into the platform by default.

The performance gap between SSR and SSG still exists. For a content site where every millisecond of LCP matters and every page is the same for every visitor, SSG is still the faster path. But the hard wall that made Lovable the wrong choice for organic search is gone for new projects.

That's a significant shift. The choice is now between a fast-to-ship SSR app with React's full ecosystem versus a leaner SSG site with lower performance overhead. That's a real tradeoff, not a clear wrong answer.

Part 1: Astro vs Lovable for SEO — Why Static Sites Win

Part 2: Building an Astro Blog with Claude Code

Building an Astro Blog with Claude Code

Ted — Tue, 19 May 2026 15:42:09 +0000

In part 1 I explained why I moved from Lovable.dev to Astro for SEO. Lovable builds React apps that serve empty HTML to Googlebot — Astro builds static HTML that Google can read instantly, no JavaScript required.

This post is part 2: actually building the blog. But instead of walking you through every command manually, I handed it to Claude.

The Prompt

One prompt. That's it.

Build me an SEO-ready Astro blog from scratch with Tailwind, MDX, RSS feed, sitemap, and fonts

From that, Claude installed everything, built the full project structure, and had a working blog ready to deploy. Here's exactly what happened — including the decisions it made that I didn't ask for, and where it hit problems.

What Claude Installed

Claude ran the following commands in sequence:

npm create astro@latest astro-demo

When prompted:

Template: Empty
TypeScript: Yes, strict
Install dependencies: Yes
Initialize git repo: Yes

Then added the integrations:

npx astro add tailwind
npx astro add mdx

Then fonts and RSS:

npm install @fontsource-variable/inter @fontsource/jetbrains-mono
npm install @astrojs/rss

One thing it caught that I didn't ask about: it skipped @astrojs/sitemap entirely. That integration crashes on Astro 4.16+ with a Cannot read properties of undefined (reading 'reduce') error. Claude knew this and built a manual sitemap endpoint at src/pages/sitemap.xml.ts instead. That's the kind of thing you only know if you've hit the bug — or in this case, if your agent has enough context to anticipate it.

What Claude Built

The full project structure:

src/
├── components/
│   ├── Header.astro
│   ├── PostList.astro
│   └── SeriesNav.astro
├── content/
│   └── posts/        # .md/.mdx files go here
├── layouts/
│   └── BaseLayout.astro
├── pages/
│   ├── index.astro
│   ├── about.astro
│   ├── archive.astro
│   ├── posts/[slug].astro
│   ├── tags/[tag].astro
│   ├── categories/[category].astro
│   ├── series/[series].astro
│   ├── rss.xml.ts
│   └── sitemap.xml.ts
└── styles/
    └── globals.css

The scope here is worth noting. I asked for a blog. Claude built a full content taxonomy — tags, categories, series navigation, archive page, RSS feed, sitemap. Every route it created serves a purpose for either discoverability or SEO. Tag and category pages in particular matter for topic clustering: they give Google a signal that this site covers a coherent subject area, not just a loose collection of posts, which helps individual posts inherit topical authority over time.

The SEO Decisions Baked Into BaseLayout

This is the part most tutorials skip. The layout file is where most of your SEO either works or doesn't.

Claude built BaseLayout.astro with the following automatically wired up for every page:

Canonical URL — generated from the site URL and current path. Every page declares its own canonical, which prevents duplicate content issues if Vercel's preview URLs ever get indexed.

Open Graph tags — og:title, og:description, og:image, og:url, og:type. These control how the page appears when shared on Twitter, LinkedIn, or Slack. Claude wired them to the same frontmatter fields as the page meta, so there's no separate OG configuration needed per post.

Twitter Card — summary_large_image by default, so post shares show a full image preview rather than a small thumbnail.

JSON-LD structured data — three schemas per post page: Article, WebSite, and BreadcrumbList. These are what Google uses to understand the page type, authorship, and navigation hierarchy. On a CSR site this has to load via JavaScript and might not be seen by crawlers. On Astro it's in the HTML before any JavaScript runs.

All of this is automatic. Drop a new post file in src/content/posts/, push, and every one of those meta tags is generated correctly with no manual input.

The Content Schema

Claude defined the content schema in src/content/config.ts:

title: string
description: string
publishDate: string
updatedDate?: string
tags: string[]
category: 'guides' | 'notes' | 'builds'
draft: boolean
image?: string
imageAlt?: string
series?: string
part?: number

The series and part fields were something I asked for specifically — I knew I'd want to group related posts. Claude built SeriesNav.astro to handle the series UI automatically: previous/next links within a series, plus a link back to the series index page. Posts without series in their frontmatter render as standalone, no extra configuration needed.

Where It Hit Problems

It wasn't perfect. Two things needed manual fixes.

The Vercel deploy config. The first deploy failed because Vercel defaulted to the wrong output directory. Claude had to add a vercel.json file to the root:

{
  "buildCommand": "npm run build",
  "outputDirectory": "dist",
  "framework": "astro"
}

After that it deployed cleanly.

The GitHub push from the server. Claude Code runs on my homeserver, not my local machine. To push to GitHub from the server, the git remote needs a personal access token embedded in the URL — standard HTTPS auth doesn't work in a headless environment. Claude flagged this and set the remote correctly:

git remote set-url origin https://TOKEN@github.com/username/repo

One security note: treat this token like a password. Don't commit it, don't leave it in shell history. Either use a fine-grained GitHub token scoped to the single repo, or switch to SSH keys if you're on a machine you control long-term.

Not a Claude Code limitation — just a server environment reality. Worth knowing if you're running agents on a remote machine.

Push to GitHub and Deploy

Once the remote was configured:

git add .
git commit -m "Initial blog build"
git push origin master

Then on Vercel: Add New Project → import the repo → Deploy. Vercel detects Astro automatically but needs one config file to correctly set the output directory — that's the vercel.json above. Once it's there, no further build configuration is needed.

Within two minutes the blog was live at a Vercel URL.

The Result

A fully working, SEO-ready Astro blog — deployed on Vercel, with tags, categories, series navigation, RSS, sitemap, JSON-LD schema, Open Graph, and canonical URLs — built from a single prompt in one session. The full build ran in just over 7 minutes.

(Demo video coming soon.)

Live demo: astro-demo-theta-tawny.vercel.app

What This Actually Demonstrates

The point isn't that Claude wrote the code. It's that agentic workflows collapse the gap between a decision and a working system.

The traditional path for this project: read the Astro docs, pick a template, configure Tailwind, wire up MDX, figure out why @astrojs/sitemap crashes, build the content schema, write the base layout, set up JSON-LD manually, troubleshoot the Vercel config, push. Half a day minimum, probably longer.

The agentic path: one prompt, review the output, fix two issues, ship.

The output is the same. The time investment is not.

That's what this blog documents — not AI as a novelty, but AI as operational infrastructure. The blog itself was built the same way the systems it writes about are built: give the agent a clear goal, stay in the loop on decisions that matter, and let it handle the implementation.

Why the SEO Foundation Matters More Than the Framework

A lot of people building blogs with AI tools focus on the wrong thing. They want the blog to look good, deploy fast, and be easy to write in. Those matter. But the SEO foundation — the stuff that determines whether Google can read and understand your content — is decided before you write a single post.

Here's what this build gets right by default:

Every page is crawlable on the first request. No JavaScript rendering required. Googlebot hits the URL, gets complete HTML, indexes it. That's it.

Structured data is present and correct on every post. The JSON-LD schema Claude wired into BaseLayout.astro tells Google this is an Article, who authored it, when it was published, and where it sits in the site hierarchy. This is what enables rich results in SERPs — date stamps, breadcrumbs, author attribution. On a manually-built blog these are easy to get wrong or forget entirely. Here they're generated automatically from frontmatter.

The sitemap updates on every deploy. The custom sitemap.xml.ts endpoint queries the content collection and generates a fresh sitemap at build time. Every new post is automatically included with its correct URL and publish date. You never manually update a sitemap or worry about a new post being missed.

RSS keeps returning readers engaged. The RSS feed at /rss.xml is a low-effort retention mechanism. Readers who subscribe get notified of new posts without you needing to send an email or post on social. For a technical blog, a meaningful chunk of the audience prefers RSS — it's worth having from day one.

None of this required separate configuration. It was all handled in the initial build.

Write Your First Post

Drop a .md file in src/content/posts/:

---
title: "My First Post"
description: "A short description for Google."
publishDate: "2026-04-27"
tags: ["astro", "seo"]
category: "guides"
draft: false
---

Your content here.

Push to GitHub. Vercel redeploys automatically. Done.

The build is the easy part. The harder question is what you do next — how you monitor whether Google is actually finding and indexing your posts, and what to do when something goes wrong. That's what the rest of this series covers. Browse all posts in the Astro SEO Blog series.

Astro vs Lovable for SEO: Why Static Sites Win

Ted — Tue, 19 May 2026 15:18:29 +0000

My monitoring script fired at 3am. A content site I manage — the top-ranking page on that domain, the one its entire internal linking structure pointed to — had dropped out of the Google index entirely.

Not penalized. Not a manual action. Just gone — as if it never existed.

The diagnosis was quick. The site ran on a CSR stack — React, client-side rendered. Googlebot had visited, got a near-empty HTML shell, and moved on before JavaScript had a chance to build the DOM. At some point Google stopped waiting and dropped the page entirely.

The fix took less than an hour. Within a day or two it was back — and when it reappeared, it had moved from position 3 to position 2. Fixing the rendering issue properly actually moved it up.

That's the thing about CSR: it doesn't just risk a penalty. It quietly suppresses pages that should be ranking, and you won't know until they disappear.

The fix was a custom prerender layer — a static HTML snippet injected directly into the React root div under the id ssr-prerender. Googlebot sees real content immediately. Real users get the React app as normal, which replaces it on load. It works. But it's a patch, not a solution — something you bolt on after the fact, maintain separately, and have to remember every time you add a new page or change content.

Client-side rendering means the server returns an empty HTML shell. The browser runs JavaScript to build the page. That works for users. It's unreliable for crawlers — and the cost doesn't show up immediately. It shows up weeks later when pages quietly stop ranking.

Lovable is built for apps, not blogs. But plenty of people use it for content sites anyway — that's the mistake this post is about.

When I decided to build this blog — a place to document agentic AI workflows that I actually want people to find — I wasn't going to patch my way through it again.

The Tools I Looked At

Before landing on a stack, I mapped out the real options. Not just "what's popular" but what the actual tradeoffs are for a content site in 2026.

Lovable

Lovable is a prompt-to-app builder. You describe what you want, it generates a React codebase, you deploy. The UX is genuinely impressive for web apps — forms, dashboards, interactive tools.

Update (May 2026): Lovable shipped SSR as a first-class feature. New apps are now server-side rendered — Googlebot gets real HTML on the first request, the crawlability problem is gone for new projects. Existing apps get automatic pre-rendering at build time, which fixes the indexability issue without a DIY script.

The performance gap with SSG still exists. New Lovable apps ship a full React bundle and add server latency to every request — a static site serves pre-built HTML from a CDN edge node with no per-request compute. For a pure content blog where every page is the same for every visitor and LCP matters, SSG is still the faster path. But the hard wall that made Lovable the wrong choice for organic search is no longer there for new projects.

I still use it for clients who need web apps or interactive content. For a pure content site with no dynamic requirements, the SSG argument below still holds.

Cursor

Cursor is a VSCode fork with an embedded AI assistant — excellent for developers who want faster coding without giving up control. It doesn't pick a framework or manage deployments, so the SEO tradeoffs are entirely yours to manage.

What I Actually Use

My setup is deliberately boring:

ThinkCentre PC, bare metal Ubuntu, no cloud VM
Claude Code over SSH as the agent
Astro 4 — SSG, zero client JS by default
Vercel for deploy, auto-deploys on every push to master

Claude Code handles file editing, refactoring, and multi-step builds. I review diffs, approve writes, and push. The agent runs in my terminal — no subscription to a hosted IDE, no vendor controlling my environment.

Astro was the obvious framework choice once I ruled out React-based options. Every page is static HTML at build time. No JavaScript ships to the browser unless you explicitly add it. Googlebot sees exactly what a user sees, because there's no rendering step to skip.

The content schema is straightforward MDX files in src/content/posts/. Writing a new post is dropping a Markdown file and pushing. No CMS, no API calls, no paid tier. The overhead is real but front-loaded — you configure image optimization, redirects, and the content schema once. After that it doesn't move. That's a different kind of maintenance than patching a prerender layer every time you add a page.

Astro vs Lovable for SEO: The Real Comparison

This is the question that matters if you're using AI-assisted tools to build content sites.

Lovable is built for speed — you describe a UI, it ships React. That's genuinely useful for products, dashboards, anything interactive. But for a content site where organic search is the point, React's default rendering model is the wrong starting point.

Googlebot has a two-wave crawl model. First wave: fetch the raw HTML. Second wave: render JavaScript. The second wave happens on a delay — sometimes hours, sometimes days — and isn't guaranteed for every page on every crawl. For a new site or a page with low crawl budget, Google may only ever see the first wave. On a CSR site, that first wave is an empty shell.

Astro doesn't have this problem. The HTML is complete at build time — every page is just a file on disk, served directly. Googlebot gets the same document a user gets, on the first request, every time. An Astro page can be indexed the same day it's published. A Lovable page might take two weeks and a manual fetch request in Search Console to force the second render wave.

For a blog where every post is a potential traffic source, that's not a minor difference.

The SEO Tradeoff That Actually Matters

Here's the thing nobody says clearly: your platform choice is an SEO decision.

Every framework has a default rendering strategy. If that default is client-side, you're opting into a crawl risk. You can mitigate it, but you can't fully eliminate it — and every mitigation adds operational overhead.

To be precise: the risk is probabilistic, not guaranteed. High-authority domains with strong crawl frequency and deep internal linking can rank fine on CSR — Google's renderer has improved significantly, and a well-established site gives Googlebot reason to come back for the second wave. The risk is highest where the stakes are also highest: new sites, low crawl budget pages, and content that needs to index fast to catch a trend or a seasonal window. That's exactly where most content blogs live.

Static site generators like Astro, Eleventy, and Hugo don't have this problem. The HTML is there at request time, before any crawler or user arrives. There's nothing to render, nothing to wait for, nothing to patch around.

Beyond crawlability, static sites have compounding SEO advantages:

Speed. Astro ships zero JavaScript by default — the browser gets a finished HTML file and paints immediately. On a React CSR site, the browser downloads a JS bundle, parses it, executes it, then renders. That sequence adds hundreds of milliseconds to LCP on a cold load, and LCP is a Core Web Vitals signal Google uses as a ranking factor. My Astro blog consistently scores 95+ on PageSpeed Insights mobile. My client sites on CSR stacks rarely break 70 without active optimization.

Structured data. In Astro, JSON-LD schema lives in the base layout — defined once, present on every page at build time, no runtime dependency. On a CSR site, your structured data is injected by JavaScript. If the script errors, is blocked, or executes after Googlebot's render window closes, your schema is invisible. You won't see this failure in GSC until it's already cost you rich results.

Here's what that looks like in practice — the relevant slice of an Astro base layout:

---
const { title, description, canonicalURL } = Astro.props;
const schema = {
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": title,
  "description": description,
  "url": canonicalURL,
};
---
<head>
  <link rel="canonical" href={canonicalURL} />
  <script type="application/ld+json" set:html={JSON.stringify(schema)} />
</head>

The canonical and structured data are rendered into the HTML at build time — no hydration, no runtime dependency, no silent failure.

Canonical URLs. Static generation makes canonicals deterministic. Every page has one URL, set at build time, baked into the HTML. CSR frameworks with dynamic routing can silently generate duplicate URLs under different query parameters — /posts/my-article and /posts/my-article?ref=homepage both return 200s, both get crawled, and both dilute the canonical signal unless you've explicitly handled it. With Astro, this class of problem doesn't exist.

For a content blog that needs to rank, none of this is optional. It's the baseline.

The Middle Path

Astro isn't the only way out of CSR. It's worth naming the alternatives so this doesn't read as "Astro or nothing."

Next.js gives you two paths to HTML-first rendering. output: 'export' is a full static export — no server features, no API routes, no ISR, just HTML files on disk with the same crawlability as Astro. getStaticProps is SSG inside a hybrid Next.js app that still has server routes, API endpoints, and ISR — more flexible, but you're choosing the rendering strategy per page deliberately rather than accepting a default. If you're already comfortable in Next.js, either path works. Astro islands (partial hydration) let you drop interactive React or Svelte components into otherwise static pages without shipping a full JS bundle. For a content site that needs one or two dynamic widgets, that's a clean solution.

The principle is the same regardless of which tool you pick: HTML-first by default, JavaScript added deliberately. Astro makes that the default. Next.js makes it possible but requires you to choose it. Lovable doesn't give you the option.

What I'd Tell Someone Starting Now

If you're building a web app — a tool, a dashboard, something with real interactivity — Lovable is a legitimate choice. Ship fast, iterate, worry about SEO when the product is solid.

If you're building a content site — a blog, a documentation site, a resource hub where organic traffic is the point — don't use a CSR framework as your foundation. The crawl risk is real, the fixes are patches, and you'll spend time maintaining workarounds that a static site simply doesn't need.

One honest limit worth naming: pure SSG pre-builds every page identically at deploy time. That works perfectly for content. It gets awkward when every page needs to render differently per user — a fully personalised feed, for example. For that you switch Astro to output: 'hybrid' or output: 'server' mode, which enables server-side rendering on specific routes while keeping everything else static. Auth and Supabase integration work fine in Astro either way — login flows, protected routes via middleware, user dashboards as islands. The constraint isn't "you can't do auth," it's "fully personalised page-level content at scale wants SSR, not SSG."

Astro is free, deploys to Vercel in one click, and handles all the SEO fundamentals out of the box. The learning curve is light if you know HTML and basic JavaScript. It's not the only answer — but for a new content site where every page needs to index fast, it's the lowest-friction path to getting that right.

Read part 2 to see how I built this blog in a single Claude Code session.

Part 3 covers the Lovable SSR update in detail — what pre-rendering for existing apps actually fixes, what it doesn't, and when the Astro argument still holds: Lovable Shipped SSR. Here's What That Actually Changes.