B*tchwork my AI Did for Me - Part 9: Got My Brand-New SaaS Ranking in Google, ChatGPT, and AI Search Overnight
One morning. Five prompts. Forty-one new ways for PRISM to get found.
Most new brands have one real search entry point.
Usually it is the homepage. Or one generic service page. Or one link-in-bio site.
That is fine if someone already knows the brand name. It is bad if they do not.
If a person searches best AI social media scheduler, Buffer alternative, or how to schedule Instagram posts with AI, your homepage usually is not …
enough. Search engines want a page that matches the question. AI search tools want a page they can quote clearly. If you do not have that page, you do not really exist for that search.
That was the problem I was looking at with PRISM.
PRISM is a new SaaS. The product is real. The offer is real. But the search surface was still thin. So instead of treating SEO like a giant six-month side quest, I had AI build the first real layer of search pages for me overnight.
This article uses PRISM because that is the live example. But the playbook is bigger than SaaS.
If you have a new creator brand, agency, media brand, course business, newsletter, or local service business, the same core problem shows up fast. People cannot find you unless you already have pages built for the questions they are asking.
That layer was 41 pages:
25 comparison pages
6 use-case pages
5 free-tool pages
5 AI-workflow pages
Then I had it add the boring but important stuff too: metadata, schema, internal linking, sitemap support, and the AEO and GEO layer that helps AI search systems actually understand what the pages are.
This did not make PRISM instantly win search.
It did something more basic and more important first. It gave the product more doors into the internet.
If your brand only has a homepage and one generic offer page, you do not have much of a search strategy. You just have a website.
What I actually mean by SEO, AEO, and GEO
These labels sound more dramatic than they are.
SEO is regular search optimization. You make pages that Google can crawl, understand, and rank.
AEO is answer engine optimization. That is the version built for systems that try to answer the question directly, like ChatGPT, Perplexity, or Google AI Overviews.
GEO is generative engine optimization. Same neighborhood. Slightly newer language. Same basic idea. You want your site to be the source AI systems pull from when they summarize a space, compare tools, or answer a question.
I do not think founders need to obsess over the vocabulary here. The practical point is simpler than the acronyms.
You need pages that work for both kinds of search now:
the person typing into Google
the person asking an AI tool
If your site only has generic marketing pages, neither system has much to work with.
This gets sharper when the brand is new
An established company can get away with weak search pages for a while because the brand already carries traffic.
A new brand usually cannot.
If the brand is new, then search has to do more work. It has to introduce the offer to people who have never heard of it. It has to show up when somebody is comparing options. It has to answer specific use-case questions. It has to give AI systems enough structured context to mention the brand in the first place.
That is why I like this as AI work.
It is not glamorous work. It is repetitive. It is easy to delay. It is very useful. It also follows patterns really well, which makes it a strong fit for an AI coding agent as long as you define the structure clearly and check the outputs before they ship.
The search intent buckets I wanted PRISM to cover
Before I touched prompts or code, I got clear on the kinds of searches PRISM should be able to answer.
There were four buckets.
Comparison pages. These are the PRISM vs X or X alternative searches. Somebody is already shopping. This is high intent traffic. If you do not have the page, the competitor or an affiliate site gets that visit instead.
Use-case pages. These are searches from people who care more about the job than the tool. They want to solve a problem like planning content faster, scheduling posts consistently, or turning one idea into a week of content.
Free-tool pages. These are simple utility pages that solve one narrow problem. They can rank, get shared, and introduce people to the bigger product.
AI-workflow pages. These are searches from people trying to do a specific thing with AI. They are often early in the funnel, but they are also very good fits for a product like PRISM because the product sits right next to that workflow.
Once I had those four buckets, the build got much easier because I was not asking AI to magically invent a strategy. I was giving it a map.
Search pages work best when each page has one clear job. Compare. Explain. Solve. Or teach.
How this maps to other kinds of brands
The page types change a little by business model, but the logic stays the same.
For a SaaS, the obvious buckets are comparison pages, use-case pages, free tools, and workflow pages.
For a creator brand, the equivalent might be topic pages, prompt libraries, tool roundups, and step-by-step guides.
For an agency or service business, it might be service pages, industry pages, city pages, comparison pages, and case-study pages.
For a media or newsletter brand, it might be explainers, glossary pages, roundups, prediction pages, and resource hubs.
So do not get stuck on my exact 41-page mix.
What you want is a spread of pages that answers the main questions a stranger would type before they know your brand exists.
What I built for PRISM
For PRISM, I had AI create:
25 comparison pages at
prism-app.com/compare/[competitor-name]6 use-case pages at
prism-app.com/use-cases/[case]5 free-tool pages at
prism-app.com/free-tools/[tool]5 AI-workflow pages at
prism-app.com/ai-workflows/[workflow]hub pages that link each cluster together
My job was not to type every sentence myself. My job was to decide the page types, define the structure, give the competitor and use-case lists, and then review what came back.
That distinction is the whole game.
Founders get stuck because they think doing this means becoming a full-time content writer and SEO manager at the same time. It does not. The founder job is mostly direction and review. AI can do a large chunk of the production work if you are specific.
The stack I used
This was not some giant enterprise stack.
I used:
a domain
GitHub
Vercel
an AI coding tool that could work inside the repo
PRISM's existing app
PRISM is currently on Vite plus React Router. That is not my dream stack for search-heavy content pages. If I were starting this part from zero, I would rather use Next.js or Astro because the search side is cleaner there.
But that was not the real question in front of me.
The real question was: should I wait for a future perfect rebuild, or should I create a real search surface now inside the app I already have?
I chose now.
That is another lesson here. A good-enough search layer that exists is worth more than the perfect architecture you keep promising yourself you will build later.
What the workflow actually looked like
The work itself was simple.
First, I made the lists. I picked the competitors PRISM should compare against. I picked the use cases worth explaining. I picked the small free tools that made sense next to the product. And I picked the AI workflows that matched the way people already think about the problem.
Then I handed those lists to AI one prompt at a time.
That part is important too. I did not dump ten jobs into one giant messy prompt and hope for the best. I separated the page systems by type. Comparison pages got their own prompt. Use cases got their own prompt. Free tools got their own prompt. AI workflows got their own prompt. Then the AEO and GEO layer came after the content structure existed.
That gave the agent a cleaner job each time, which usually means better output and less cleanup.
After each pass, I reviewed the structure, made sure the pages fit the existing site, and checked the technical stuff that is easy to forget when you are moving fast.
The five prompts
These are the five prompts I would use again.
I like this setup because each prompt gives the AI one clear kind of work. It keeps the system from getting sloppy, and it gives you natural checkpoints to review before you move on.
Prompt 1: Build the comparison page system
This one handles the high-intent comparison traffic. I wanted honest pages, not fake puff pieces, because thin our tool is better than theirs pages are obvious and useless.
Build a comparison-page system inside my existing site. The route pattern is /compare/[competitor]. I will give you a list of competitors below. For each one, generate a page that does the following:
- Names the competitor and my product side by side in the H1
- Has a one-paragraph honest summary of when someone should pick the competitor and when someone should pick my product
- Has a 6-row feature comparison table covering price, key features, integrations, ease of use, target user, and ideal use case
- Has a "When to pick [competitor]" section with 3-5 bullets
- Has a "When to pick [my product]" section with 3-5 bullets
- Has a CTA at the bottom inviting the reader to try my product
- Has per-route meta tags for title, description, and canonical URL
- Has a footer date showing when the page was last updated
Match the existing site's brand colors and typography. Use the routing pattern already in this codebase. Do not make these pages thin or keyword-stuffed. They need real comparison depth.
Build a hub page at /compare that links to all of them.
Competitors:
[paste your list of 25 competitors here]Prompt 2: Build the use-case page system
Use-case pages are good because they meet the reader at the problem level. The person searching does not always know what tool they want yet. They just know what is annoying.
Build a use-case page system inside my existing site. The route pattern is /use-cases/[case]. For each use case below, generate a page that:
- Names the specific user problem in the H1
- Has a one-paragraph framing of who has this problem and what it costs them
- Has a step-by-step walkthrough of how my product solves it
- Has a screenshot placeholder that I can replace later
- Has a "What this saves you" section covering time, money, or sanity
- Has a CTA at the bottom inviting the reader to try the relevant feature
- Has per-route meta tags
Build a hub page at /use-cases that links to all of them.
Use cases:
[paste your 6 use cases here]Prompt 3: Build the free-tool page system
This is one of the easiest buckets to ignore, but I think it is underrated. A tiny useful tool can rank, get backlinks, and introduce people to the paid product without asking them for much upfront.
Build a free-tool page system inside my existing site. The route pattern is /free-tools/[tool]. For each tool below, generate a page that:
- Has the tool itself functional on the page with an input box, button, and output area
- Names what the tool does in plain language at the top
- Has a one-paragraph explanation of why someone needs it
- Has a CTA below the tool inviting the reader to upgrade to my product for the deeper version
- Has per-route meta tags
Build a hub page at /free-tools that links to all of them.
Free tools:
[paste your 5 free tool ideas here]Prompt 4: Build the AI-workflow page system
These pages help with the new kind of search behavior. People are constantly looking for prompts, workflows, and step-by-step AI help. If your product sits inside that job, you should have pages for it.
Build an AI-workflow page system inside my existing site. The route pattern is /ai-workflows/[workflow]. For each workflow below, generate a page that:
- Names the specific task the reader wants to accomplish in the H1
- Has the prompt the reader should use in a copy-button code block
- Has a step-by-step walkthrough of how to run the prompt and what to expect
- Names the AI tool the workflow uses
- Has a CTA inviting the reader to try my product, which automates more of this
- Has per-route meta tags
Build a hub page at /ai-workflows that links to all of them.
Workflows:
[paste your 5 workflow ideas here]Prompt 5: Add the AEO and GEO layer
This is the part a lot of founders still skip. They may build the pages, but they do not add the structure that helps search engines and AI systems read those pages cleanly.
Add the AEO and GEO layer to every page built in Prompts 1-4. Specifically:
1. Add JSON-LD schema.org markup to every page.
- Comparison pages: use Product plus Review schema with both products listed
- Use-case pages: use HowTo schema
- Free-tool pages: use WebApplication schema
- AI-workflow pages: use HowTo schema
2. Create an llms.txt file at the root of the domain. Format it to spec and list every page with a one-line description.
3. Make sure every page has:
- a descriptive H1
- a meta description under 160 characters
- a canonical URL tag
- Open Graph tags for title, description, and image
4. Generate or stub Open Graph images for every page. Size: 1200 by 630. Use my existing brand colors. The card should show the page title in a clean serif font on the brand background.
Do all four for every page that already exists. Do not break existing routing or styles.That prompt is what turns the pages from plain site content into pages that machines can parse more confidently.
One more prompt: the boring site-wide SEO plumbing
I also had it handle the site-wide pieces that make the whole system more usable for crawlers.
Generate or update the following site-wide files:
- sitemap.xml at the root, listing every page with a lastmod date
- robots.txt at the root, allowing all crawlers and pointing to the sitemap
- a 404 page that links back to the homepage
- an automated weekly script that re-generates the sitemap when new pages are added
Push to main when done. Confirm Vercel deploys successfully.This is exactly the kind of work I do not want to be the bottleneck on. It is not hard. It is just the sort of task that falls to the bottom of the pile for months if a founder has to do every piece manually.
What this actually buys you
The easiest way to explain the value is this: it gives your product more chances to be found.
Before this build, PRISM mostly had one obvious front door in search. After it, PRISM had dozens more.
That same shift is available to almost any new brand. You go from one generic entry point to a set of pages built around real questions, real comparisons, and real jobs people are trying to get done.
Now there are pages for comparison searches. Pages for use-case searches. Pages for AI workflow searches. Pages that can show up in regular search. Pages that can feed AI systems cleaner source material.
None of that guarantees traffic overnight.
Search still takes time. Pages still need to be indexed. Some pages will do better than others. Some will need edits. Some ideas will be wrong. That is normal.
But a new SaaS with a real search surface is in a much stronger position than a new SaaS with a homepage, a pricing page, and wishful thinking.
Three things I would be careful about
Check the facts on every comparison page.
This is the biggest risk. AI can write a clean-looking comparison page that is still wrong about pricing, features, or integrations. That is how you lose trust fast. Review every page before it goes live, and set yourself a reminder to re-check them later.
Do not confuse page volume with quality.
Forty-one weak pages are not better than ten strong ones. The reason this worked as a first pass is that each page had a clear structure and a clear search job. Keep that standard.
Use the better framework if you still have the choice.
I made this work inside PRISM's current Vite setup because the product is already there and speed was the priority. If I were building a fresh marketing or content layer from scratch, I would rather choose a stack that makes search-heavy content simpler from day one.
Why I like this as founder leverage
This is one of my favorite categories of AI work because it changes the founder's job in a very useful way.
The founder does not have to be the person grinding through 41 similar builds by hand.
The founder still does the high-value part:
choosing the angles
deciding which searches are worth going after
setting the quality bar
reviewing the claims
approving what goes live
AI does the bitchwork.
That is the whole point of this series.
I do not want AI replacing judgment. I want it replacing repetitive production work that still needs to get done.
Tools used
Codex
GitHub
Vercel
a domain registrar
PRISM's existing Vite + React Router app
My extra cost on top of what I was already paying for was about $20.
That is a ridiculous trade if the result is turning a brand-new SaaS from one search door into forty-one more.
Next Friday's Bitchwork is the visual layer: how I generate OG card images for these pages automatically.
More links