SEO for SaaS: A Weekend-Built App Checklist

· 6 min read · Guides

SEO for SaaS: A Weekend-Built App Checklist

SEO for a SaaS you built in a weekend comes down to four things. Google has to be able to read your pages as plain HTML. Each page needs its own title and description. You need a sitemap, and you need Search Console watching the result. Do those and you're set up for the slower work of writing pages people actually search for.

None of this takes long, and your AI editor can do most of the typing. The catch is that it won't check its own work, so you have to.

Why weekend apps are often invisible

AI app builders are good at making things that look finished. Search engines don't care how it looks. They care about what's in the HTML and whether each URL says something different from the others.

The usual problems are the same few. The whole app renders in the browser, so the server sends an empty shell. Every page has the same title, because the editor wrote one in the root layout and never touched it again. There's no sitemap, and nobody has opened Search Console.

Google's own SEO Starter Guide is about making it easier for search engines to crawl, index and understand your content. That's a decent frame. Everything below is about removing friction at one of those three steps.

Step 1: Check what a crawler actually sees

Open your landing page, right-click, and pick "View page source". Don't use Inspect, which shows the page after JavaScript has run. View source shows what the server sent.

Search for a sentence from your hero section. If it's there, good. If you only see an empty <div id="root"> and some script tags, your content depends on JavaScript running.

You can also test it from the terminal:

curl -s https://yourapp.com | grep -i "your headline text"

Client-side rendering isn't automatically fatal. As one overview of JavaScript SEO puts it, it makes SEO depend on JavaScript executing successfully, plus API responses, routing and the rendered output. That's a lot of things that can quietly break. For public pages (landing, pricing, docs, blog), render on the server or at build time. Keep the client-only approach for the logged-in dashboard, which nobody needs to find through Google.

If you're on a Vite + React SPA, this is the one place where it may be worth switching to a framework with server rendering, like Next.js, Remix or Astro. You'd do that before you start on content, not after.

Step 2: Give every page its own title and description

The title tag is the biggest on-page lever you have, and it costs nothing. Each public page should get a unique title that says what the page is, plus a short description written for a human deciding whether to click.

In Next.js App Router, you can set a static metadata object or use generateMetadata for pages that depend on data. The Next.js docs note these exports only work in Server Components. If your editor stuck "use client" at the top of a page file, the metadata won't work there. That's a common AI-generated mistake.

A simple pattern for titles:

  • Home: what it is + who it's for ("Invoice reminders for freelancers")
  • Feature pages: the job it does ("Automatic payment reminders")
  • Pricing: the word "pricing" plus your product name

Also check headings. Each page should have one <h1> that matches the page's topic, with <h2>s under it. Generated landing pages sometimes have five h1s or none.

Step 3: Add robots.txt and a sitemap

A robots file tells crawlers what they may visit. A sitemap lists the URLs you want found. In Next.js you can generate both from code: the robots.txt docs show a robots.ts file in the app root, and a sitemap.ts works the same way.

A minimal robots setup keeps private areas out and points at the sitemap:

User-Agent: *
Allow: /
Disallow: /app/
Disallow: /api/

Sitemap: https://yourapp.com/sitemap.xml

Careful with Disallow. The most common way to wreck your own SEO is a leftover Disallow: / from staging. Visit /robots.txt on your live domain and read it.

Google's sitemap documentation says you can submit a sitemap through Search Console, through its API, or by referencing it in robots.txt. Doing the robots.txt line plus Search Console covers you.

Step 4: Set up Search Console

  1. Add your domain in Google Search Console and verify it (DNS verification is the cleanest if your registrar supports it).
  2. Open Sitemaps, enter sitemap.xml, and submit.
  3. Use URL Inspection on your homepage and pricing page to confirm Google can fetch and see them.
  4. Come back in a week or two and look at the Pages report for anything marked as not indexed, along with the reason.

Indexing can take a while, and nobody can promise you a date. Don't panic on day three. Do panic a little if a page says "noindex" and you didn't put it there.

Step 5: Build pages that match searches

Technical setup gets you into the index. It doesn't get you traffic. For that, you need pages that match what your buyer types into Google. Your homepage can only target one idea, so most SaaS sites need a few more pages.

Page typeExample searchOne job
Use-case page"invoice reminders for freelancers"Show the exact problem and how your app solves it
Alternative page"[competitor] alternative"Be honest about who you fit and who you don't
How-to post"how to chase a late invoice"Answer the question, then mention your tool
Pricing page"[your product] pricing"Make the cost obvious, so people don't leave to find it

Keep it to one topic per URL. If two pages both try to rank for the same phrase, they compete with each other. Write each page for a person first, and put the target phrase in the title, the h1 and the first paragraph, without stuffing it in everywhere.

A prompt you can paste into your editor

This works in Cursor, Claude Code, Windsurf or similar. Adjust the paths to your stack, and read the diff before you accept it.

Audit this app for basic SEO. Don't change the design.

1. List every public route (landing, pricing, docs, blog). Ignore routes behind login.
2. For each, check that the main content is in server-rendered or statically generated HTML, not only built in the browser. Flag any page with "use client" at the top that exports metadata.
3. Give each public page a unique title and meta description via the framework's metadata API. Ask me for the product name and audience if you're missing them.
4. Make sure each page has exactly one h1.
5. Add app/robots.ts (disallow /app and /api, link to the sitemap) and app/sitemap.ts (public routes only).
6. Add Open Graph title, description and image for the homepage.
7. Output a short list of what you changed and anything you weren't sure about.

After it runs, repeat Step 1 yourself with view source. Don't take the summary on trust.

What to skip for now

Don't buy an SEO tool subscription before you have a sitemap. Don't chase backlinks before your pages are indexed. Don't rewrite meta descriptions for the third time. A site that's crawlable, has distinct titles, and has three or four pages aimed at real searches is ahead of most weekend projects.

FAQ

How long until my SaaS shows up on Google?

It varies, and I couldn't find a reliable number to give you. Submit your sitemap, check URL Inspection to confirm the page can be fetched, and then check the Pages report in Search Console over the next couple of weeks. Appearing in the index and ranking well for a competitive phrase are two different things.

Do I need a blog for SEO for SaaS?

Not on day one. Get the homepage, pricing and one or two use-case pages right first. A blog helps when you have specific questions your buyers ask and you can answer them better than what's already ranking, so start with a few posts like that instead of a content calendar.

Is a React SPA bad for SEO?

It adds risk, because your visibility depends on rendering working every time. For marketing pages, server rendering or static generation is easier to verify with view source or curl. A client-rendered dashboard behind a login is fine, since search engines shouldn't see it anyway.

Cover photo: Jefferson Santos on Unsplash

// the weekly drop

5 app ideas nobody built yet. Every week.

Real problems people complain about, who would pay, how hard it is to build, and the prompt to start with. Free.

One email a week. Unsubscribe in one click.