Forem: Adam Grenier

The SEO Fix Your Vibe‑Coded Vite/React Site Needs (Without Next.js)

Adam Grenier — Fri, 27 Mar 2026 07:18:42 +0000

If you’ve ever vibe‑coded your way to a “pretty good” SaaS or landing page, shipped it, and then checked Google Search Console… you’ve probably seen it:

Discovered – currently not indexed

I was reminded of that wall with SmilePlease, an AI tool that generates professional school portraits from everyday photos. I built it the way a lot of modern apps get built:

Vite + React
Supabase on the backend
Deployed to Railway in an afternoon

The site was fast. The UX felt great. But Googlebot? Googlebot basically pretended it didn’t exist.

Out of 36 known URLs, exactly one page was indexed.

This post walks through how to fix that by adding build‑time prerendering to a Vite/React SPA—without rewriting everything in Next.js or Remix. If you’ve vibe‑coded a Vite app and are only now realizing SEO matters, this is for you.

Why Google Ghosted My SPA

A classic Vite/React SPA ships an almost‑empty index.html that looks something like this:

<body>
  <div id="root"></div>
  <script type="module" src="/src/main.tsx"></script>
</body>

All your real content only exists after the JavaScript bundle runs, mounts React, fetches data, and renders the app.

Google can render JavaScript, but it doesn’t do that up front for every URL:

First, it fetches the HTML and parses whatever it finds.
Then, if the page looks “worth it,” it gets scheduled for a second pass where Google executes your JS and sees the full DOM.

If your domain is brand new and has basically no authority (no backlinks, no history), those JS‑heavy pages sit in a low‑priority queue. Some of them never get rendered at all.

In my case, I made things worse with a robots.txt own‑goal:

User-agent: *
Disallow: /assets/

Vite was outputting all of my JS and CSS into /assets/. By disallowing that folder, I was literally telling Google:

“ Please don’t download the code you’d need to see what’s on my site.”

So I had:

HTML files with no meaningful content
JavaScript that Googlebot wasn’t allowed to fetch
A brand new domain with zero authority

Perfect recipe for “Discovered – currently not indexed.”

The Standard Advice (That I Didn’t Want to Take)

The common advice for “React SPA SEO” is straightforward:

“Just migrate to Next.js or Remix and use SSR.”

Which is good advice if:

You’re early in the project, or
You want the framework features and are ready to refactor routing, data fetching, and deployment.

I wasn’t there:

The app worked.
The stack has some baked complexity.
I didn’t want to rebuild the routing layer or re‑thread my Supabase client through SSR entry points.

I wanted something that:

Kept my Vite/React SPA as‑is
Required minimal code changes
Gave Google fully rendered HTML at crawl time

So instead of switching frameworks, I went with build‑time prerendering.

The Strategy: Build‑Time Prerendering

The idea is simple:

Build your SPA as usual with Vite (this is a go-to for most of the current vibe-coding tools like Lovable, Gemini Studio, Replit, Bolt, etc.).
Spin up a tiny web server that serves the built dist folder.
Use a headless browser (Puppeteer) to visit each important route.
Grab the fully rendered HTML from the page.
Save that HTML back into dist as static .html files.

When Googlebot (or any non‑JS client) requests /pricing, your host serves the static HTML we prerendered. The browser can still load your JS and hydrate the page into a full SPA once it’s loaded.

You get:

Static‑site behavior for crawlers and no‑JS users
SPA behavior for everyone else
No framework rewrite

Here’s how I wired it up.

Step 1: Make React Hydrate Instead of Re‑Render

If you dump fully rendered HTML into index.html but keep doing a normal createRoot().render(<App />), React will:

Throw away the HTML you prerendered
Rebuild the DOM from scratch on the client

We want React to hydrate the existing DOM instead.

In your Vite entry file (often main.tsx or main.jsx), swap the mount logic to preferred hydration when the root already has content:

import { createRoot, hydrateRoot } from 'react-dom/client';
import App from './App';

const rootElement = document.getElementById('root');

if (rootElement) {
  // If the root element has children, the page was prerendered
  if (rootElement.hasChildNodes()) {
    hydrateRoot(rootElement, <App />);
  } else {
    // Standard SPA mounting for non-prerendered pages
    createRoot(rootElement).render(<App />);
  }
}

This keeps the prerendered HTML intact and layers React’s event system on top of it.

Step 2: Write a Puppeteer Prerender Script

Next, we’ll write a Node script that:

Starts an Express server to serve dist
Uses Puppeteer to open each route
Waits for network requests to finish
Saves the final HTML to disk

Create something like scripts/prerender.ts:

import puppeteer from 'puppeteer';
import express from 'express';
import { mkdirSync, writeFileSync } from 'fs';
import { join, dirname } from 'path';

const DIST_DIR = join(process.cwd(), 'dist');
const PORT = 3005;

// The routes you care about for SEO.
// Keep this focused: home, pricing, features, blog posts, etc.
const ROUTES = ['/', '/pricing', '/about', '/blog'];

async function prerender() {
  // 1. Start a local server that serves the built assets
  const app = express();

  app.use(express.static(DIST_DIR));

  // SPA fallback: any unknown route serves index.html
  app.use((_, res) => {
    res.sendFile(join(DIST_DIR, 'index.html'));
  });

  const server = app.listen(PORT, () => {
    console.log(`[prerender] Server listening on http://localhost:${PORT}`);
  });

  try {
    // 2. Launch headless Chrome
    const browser = await puppeteer.launch({ headless: true });
    const page = await browser.newPage();

    // Optional: set a consistent viewport / user agent
    await page.setViewport({ width: 1280, height: 720 });

    // 3. Visit each route and save its HTML
    for (const route of ROUTES) {
      const url = `http://localhost:${PORT}${route}`;
      console.log(`[prerender] Visiting ${url}`);

      // Wait until network is idle to ensure data has loaded
      await page.goto(url, { waitUntil: 'networkidle0' });

      const html = await page.content();

      const isRoot = route === '/';
      const filePath = isRoot
        ? join(DIST_DIR, 'index.html')
        : join(DIST_DIR, route, 'index.html');

      mkdirSync(dirname(filePath), { recursive: true });
      writeFileSync(filePath, html);

      console.log(`[prerender] Wrote ${filePath}`);
    }

    await browser.close();
  } finally {
    server.close();
  }
}

prerender().catch((err) => {
  console.error('[prerender] Error during prerender:', err);
  process.exit(1);
});

A few practical notes:

Keep ROUTES small and focused on your SEO‑critical pages; every route adds build time.
If your app relies on auth, feature flags, or environment‑specific data, you can inject cookies or query params before calling page.goto.

Step 3: Wire It Into Your Build

Now we want this script to run automatically whenever we build for production.

In package.json:

{
  "scripts": {
    "build": "vite build && tsx scripts/prerender.ts",
    "dev": "vite",
    "preview": "vite preview"
  }
}

Key points:

vite build runs first and outputs your SPA into dist.
tsx scripts/prerender.ts runs next, starts the local server, prerenders routes, and overwrites/creates HTML files in dist.
On Railway, set your build command to \pnpm run build in the project settings.

If you’re deploying somewhere else (Vercel, Netlify, Render, plain CI + S3), the idea is the same: make sure this script runs in your build step, not at request time.

Step 4: Fix Your robots.txt (If You Messed It Up Like I Did)

Finally, make sure you’re not accidentally blocking the very assets Google needs to render your app.

A safe starting point is something like:

User-agent: *
Allow: /

Sitemap: https://your-domain.com/sitemap.xml

If you need to block specific URLs or paths, target those explicitly, but don’t broad‑brush disallow your JS/CSS folders.

What Changed After Prerendering

After:

Removing the /assets/ block from robots.txt
Adding the prerender step to the Vite build
Letting Google recrawl

I went from “one lonely indexed page” to seeing my key marketing URLs actually appear in the index. New URLs stopped getting stuck in “Discovered – currently not indexed” purgatory.

Just as importantly, this worked without:

Migrating to Next.js/Remix
Rewriting routing
Changing my hosting setup

For Google and non‑JS clients, SmilePlease behaves like a static site. For users with JS, it behaves like the vibe‑coded SPA I originally shipped.

When This Approach Makes Sense

Build‑time prerendering is a great fit if:

You already have a Vite/React SPA in production.
You’re seeing indexing issues or thin‑content warnings.
You can afford slightly slower builds in exchange for better SEO.
You don’t want to overhaul your stack just to get server‑rendered HTML.

It’s less ideal if:

You have a ton of highly dynamic, user‑specific pages.
Your content changes on every request.
You need real‑time personalized HTML.

In those cases, SSR or a hybrid framework may be the better long‑term path.

TL;DR for Vibe Coders

If you:

Clicked a few buttons in an AI builder
Ended up with a Vite/React app on Railway
Are now staring at “Discovered – currently not indexed” in Search Console

You don’t have to rewrite everything in Next.js to fix it.

You can:

Make React hydrate pre‑rendered HTML instead of re‑rendering.
Add a Puppeteer prerender step after vite build.
Focus that prerender on your key marketing routes.
Make sure robots.txt isn’t blocking your JS/CSS.

And suddenly, your vibe‑coded Vite site behaves like a real, crawlable website in the eyes of Google—without killing the vibes that got you shipping in the first place.

If you end up wiring this into your own Vite app, I’d love to hear which platform you built on (v0, Bolt, Lovable, hand‑rolled, etc.) and whether Google started indexing your pages after the change.

How I Built a Synthetic Goat Scream Pipeline (And the Tools Along the Way)

Adam Grenier — Wed, 18 Feb 2026 23:29:58 +0000

Goats?

I needed goat screams. Hundreds of them. High quality. Labeled with musical notes.

This is the story of the tools I built to get there.

The Origin: Build Something Weird Enough to Ship

I wanted to learn API development. Not another todo app. Something fun enough to keep me motivated.

In a hunt for silly APIs, I came across the Owen Wilson Whoa API, and it inspired me. Truly. I remembered the goat scream meme era from YouTube. Those viral compilations of goats screaming like humans. Perfect.

Phase 1: YouTube Scraping

First attempt: find videos, download them, and agents clip the screams.

This was slow. And the results were rough:

Background music (Taylor Swift goat remixes, anyone?)
People laughing over the screams
Cuts in weird places
Duplicate screams across videos

I needed automation.

Tool #1: The Extract-o-matic

I built a Streamlit app that:

Takes a list of YouTube URLs
Downloads the audio
Detects audio patterns that match goat screams (amplitude spikes, frequency ranges)
Auto-clips them into individual MP3s
Generates basic metadata (source video, timestamp, duration)

`python

Simplified detection logic

def detect_screams(audio_path):
y, sr = librosa.load(audio_path)
# Look for sudden amplitude spikes in goat frequency range
onset_frames = librosa.onset.onset_detect(y=y, sr=sr)
# Filter for goat-like frequency characteristics
# ... (frequency analysis)
return scream_timestamps`

This got me from hours of manual work to minutes. But the quality was still inconsistent.

Phase 2: Synthetic Screams

The YouTube clips had too much noise. I needed cleaner source material.

Stock audio sites had some goat sounds, but not enough variety. So I turned to AI.

The ElevenLabs Discovery

I tried several platforms:

OpenAI voice generation
Various sound effect models (Adobe SFX Generator, Kling’s AI SFX Generator, PopPop, My Edit, Elevenlabs AI SFX Generator, etc.

ElevenLabs won. Their sound effects tool generates clips that actually sounded indistinguishable from real goats from youtube. It also worked best with hilarious prompts...

The Prompting Insight

"Goat scream" as a prompt was inconsistent.

What worked better: describing screamable experiences with a goat at the center.

Successful prompts:

"Goat yells in horror at a spider because it hates spiders"
"A dramatic goat yelling protest while being ridiculed"
"A goat stubs its toe and screams like crazy"

Less successful:

"Goat scream"
"Goat noise"
"Goat sound effect"

The context gave the model something to work with. Emotional state + situation = better variety.

Phase 3: The Sora Hack

Then Sora came out.

I was playing with video generation when I had an idea: what if I could get 15 seconds of goat screams in one generation?

The prompt that worked: "Montage of goats screaming"

Sora would generate a compilation-style video with multiple goats, multiple screams, natural variety. I'd feed the audio through my Extract-o-matic and get 5-10 clean clips per video.

I tried other video platforms (Veo, Wan, etc.) but Sora's audio quality was best for this use case.

Soon, I had as many (if not more) synthetic screams than real ones. And when I played them back-to-back, I couldn't reliably tell which were which—unless I had a specific memory attached to a real one.

The Quality Problem

I now had hundreds of clips. But many were still rough:

Weird cutoffs
Non-goat sounds that slipped through
Duplicates
Clips that needed manual trimming

I needed to audit them. Fast.

Tool #2: The Goat Screams Auditor

I needed a faster review workflow, so I built a swipe-style QA interface for audio clips, inspired by a hiring app we built in growth at Uber.

The Goat Screams Auditor:

Shows one clip at a time with a media player
Keyboard shortcuts: → next, G good, B bad, N not a scream
Auto-hides after rating
Optional notes field
Exports clean lists: good files, bad files, needs-editing

I breezed through the entire library. The good ones went to the API. The bad ones got deleted. The "needs editing" pile went to Audacity for manual cleanup when I had time (which I haven't yet, and doesn't matter).

The Music Problem

I wanted to build a beatbox (bleatbox, if you will) where you could make beats with goat screams.

First attempt: random screams on a grid.

Result: absolute chaos. Not fun. Just noise.

The screams needed musical structure. I needed to know what note each goat was hitting.

Tool #3: Wannableat

(If you wannableat my lover...)

Wannableat is a pitch analyzer that:

Takes an audio file
Runs pitch detection (using librosa and crepe)
Identifies the primary musical note
Maps the tone sequence throughout the scream
Outputs metadata for the API

python def analyze_pitch(audio_path): y, sr = librosa.load(audio_path) # Using CREPE for more accurate pitch detection time, frequency, confidence, activation = crepe.predict(y, sr) # Convert frequencies to musical notes notes = [frequency_to_note(f) for f in frequency if confidence > 0.5] primary_note = most_common(notes) return { "primary_note": primary_note, "tones_in_order": notes, "confidence": avg(confidence) }

Fun finding: Goat screams cluster around G#5 and A5. Something about goat vocal cords, I guess.

With pitch data, I could:

Query screams by musical note
Build an actual playable instrument
Pitch-shift screams to hit specific notes
Create melodies

The Goat Screams went from chaos to... slightly musical chaos.

The Flywheel

Here's where it gets interesting.

One of the apps I built is Goat I-Scream—it takes a photo of you and generates a video of you transforming into a screaming goat (using Veo).

The audio from those generations? It's a goat scream.

So now:

User makes a personal Goat Screams video
Audio gets extracted and stored
Runs through Wannableat for pitch analysis
Gets added to the API
Feeds more beats in Goat Screams
Attracts more users
Who make more Goat Screams videos
Repeat

The API feeds itself. Network effects, but for goat screams. Which probably doesn't need network effects, but it's kinda my jam.

What I Learned

Silly projects > serious projects for learning. I actually finished this one, and had a blast building the features and tools along the way. I didn't have a revenue idea for API (yet), so while this annoyed my family, it delighted me.
Synthetic data is underrated. The AI screams are indistinguishable from real ones. And I could generate variety on demand. This is a hot topic, and I'm fully on board.
Context Engineering > Prompt Engineering = Gold. "Goat scream" vs "goat screaming when it accidentally touches a cactus" comes from two completely unrelated contexts I had (goats + things that make me scream). Combining the contexts produces more creative results. Think beyond the context in front of you to raise the bar.
Build tools for your tools. The Extract-o-matic, Auditor, and Wannableat each saved hours. The meta-work was worth it. And I never really thought about music analysis and now I have three additional ideas I could fork off of it, just because I built it for goats.
Steal workflows from other domains. The Tinder-style auditor came from a hiring tool we built at Uber. The pitch analyzer came from music production. Cross-pollination works.

What's Next

I'm cleaning up and will open source the side tools:

Extract-o-matic (Streamlit audio clipper)
Goat Screams Auditor (rapid QA interface)
Wannableat (pitch analyzer)

They're goat-themed, but the patterns work for any audio classification/processing pipeline.

And I'll be launching a more consumer facing app with lots of fun AI micro-apps I built on top of GoatScreams API.

Hold your butts...

I Built a VSCode Extension to Learn How VSCode Extensions Work

Adam Grenier — Tue, 13 Jan 2026 20:24:11 +0000

I learn by building. Always have.

I also think VSCode is an under-the-radar environment ripe for innovation in coding and beyond.

I'd been wanting to understand how VSCode extensions work for years, but the docs felt scattered. So instead of just reading, I built one and documented everything along the way.

The extension itself is a bit fun: it generates 5-7-5 haiku commit messages from your staged git changes.

Stage your code, press Cmd+Shift+H, and get something like:

Config paths diverge
Settings flow through typed channels
Defaults guide the lost

But the haiku thing isn't really the point.

Why I Built This

I wanted to learn:

How VSCode commands work
How to integrate with the Source Control panel
How settings and configuration are handled
How to work with multiple AI providers (Claude, GPT-5, Gemini)
How to publish to the VS Code Marketplace

Reading docs only gets you so far. Building something real forces you to solve actual problems.

What I Learned

A few things that surprised me:

1. Commands are simpler than expected

Registering a command is just:

const disposable = vscode.commands.registerCommand('575.haikuCommit', async () => {
  // your logic here
});
context.subscriptions.push(disposable);

The complexity is in what happens inside.

2. SCM integration has quirks

Getting the staged diff requires working with VSCode's git extension API. It's not hard, but it's not obvious either. The repo has examples of how to do this cleanly.

3. Settings are powerful but verbose

VSCode's configuration system is robust, but defining settings in package.json gets lengthy fast. I ended up with settings for API keys, provider selection, model overrides, retry limits, and more.

4. Error handling matters more than you'd think

AI APIs fail. Rate limits hit. Networks timeout. The extension retries with corrective guidance if the haiku syllable count is wrong. This retry logic was more interesting to build than I expected.

The Repo as a Learning Resource

I structured the codebase so others can learn from it too.

In docs/GUIDES.md, there are step-by-step guides covering:

How to template this repo into your own extension
How commands and keyboard shortcuts work
How to integrate with Source Control
How settings and configuration management works
How to abstract multiple API providers
How to prep for release and publish

If you've wanted to build a VSCode extension but didn't know where to start, clone the repo and poke around.

This Is the First of Many

I believe the best way to understand AI (and most things in life) isn't reading about it — it's getting your hands dirty, and building.

This is the first "build to learn" project I'm sharing publicly. More coming.

Try It / Learn From It

Marketplace: 575 Haiku Commit
GitHub: AIMateyApps/575-haiku-commit

MIT licensed. Clone it, break it, build your own thing.

What's something you've been wanting to build and learn from, but haven't started yet?

Forem: Adam Grenier

The SEO Fix Your Vibe‑Coded Vite/React Site Needs (Without Next.js)

Why Google Ghosted My SPA

The Standard Advice (That I Didn’t Want to Take)

The Strategy: Build‑Time Prerendering

Step 1: Make React Hydrate Instead of Re‑Render

Step 2: Write a Puppeteer Prerender Script

Step 3: Wire It Into Your Build

Step 4: Fix Your robots.txt (If You Messed It Up Like I Did)

What Changed After Prerendering

When This Approach Makes Sense

TL;DR for Vibe Coders

How I Built a Synthetic Goat Scream Pipeline (And the Tools Along the Way)

Goats?

The Origin: Build Something Weird Enough to Ship

Phase 1: YouTube Scraping

Tool #1: The Extract-o-matic

Simplified detection logic

Phase 2: Synthetic Screams

The ElevenLabs Discovery

The Prompting Insight

Phase 3: The Sora Hack

The Quality Problem

Tool #2: The Goat Screams Auditor

The Music Problem

Tool #3: Wannableat

The Flywheel

What I Learned

What's Next

Links

I Built a VSCode Extension to Learn How VSCode Extensions Work

But the haiku thing isn't really the point.

Why I Built This

What I Learned

The Repo as a Learning Resource

This Is the First of Many

Try It / Learn From It