Bad writing is rarely why a SaaS or app website goes missing from search. The failures we find on product sites are usually in the build, while the advice they were given was all about copy. A rendering choice, a renamed folder or a template that stamps out three hundred near-identical pages can undo a year of careful content in one release, and nobody on the marketing side will see it happen.
That is our whole argument, and the rest of this post is the evidence for it. We run the programme described here on our own site, countrydevs.com, with the checks wired into the code. We are not going to quote traffic numbers. This is a method, not a results claim, and we would rather you judged it on whether it makes sense.
Search engines read what the server sends
Start with the boring test that catches the most expensive problem. Fetch one of your important pages without a browser, with curl or with JavaScript turned off, and read what comes back. Is the main text there? The title, the description, the structured data?
If your site renders its text in the browser, the first HTML a crawler receives can be an empty shell with a script tag. Google does render JavaScript, later and less reliably than plain HTML. Plenty of other crawlers, including several behind AI answer engines, generally don't run it at all. Google's own JavaScript SEO basics are polite about this. We'd be less polite: a public page that needs JavaScript to show its words is a page you have chosen to hide.
Every content page on our site renders on the server, so the text arrives in the first response. That decision was made in the framework setup, not in a content meeting, which is rather the point.
One small trap while you are testing. A 200 status does not prove a page exists. Single-page apps often answer 200 for any address and show "not found" in the browser. Check important routes in a real browser, not only by status code.
A page per question, and a list that says so
The second build-shaped problem is pages competing with each other. A features page and a solution page both chase "X software". A pricing page and a plans page split the same searches. A blog post repeats a service page's main phrase word for word. When two pages fight for one query, search engines often pick neither consistently, and you get two half-ranked pages instead of one good one.
The fix is unglamorous: a written map, one search intent to one address, and a rule that a new page records which existing pages it must not compete with. Ours lives in planning documents. It is the least exciting file we keep and one of the most useful.
Automate whatever a tired person forgets
Release days are busy. Anything that depends on someone remembering will eventually be forgotten, so we moved the remembering into the build. On our site:
- An audit measures every title in pixels against roughly 600, because Google cuts titles by width rather than character count, and the build fails if one is too wide. Our SERP snippet preview does the same check by hand.
- The content seed refuses any description outside 120 to 160 characters.
- The same seed refuses a FAQ question that already appears on another page, since two pages answering one question compete with themselves.
- Every page needs a valid share image. The audit caught pages missing one during our own services rebuild.
- A crawler counts inbound links and lists any new page with fewer than three.
- The audit flags pages whose first HTML grows too heavy.
- The sitemap and the
llms.txtsummary are generated from the same registries that build the pages, so a page can't exist without appearing in the sitemap, and a removed page can't linger there.
None of this is clever. Its value is that it runs every single time.
Deploys are where rankings die
The most expensive SEO bug we know of is a redirect that isn't there. A page earns links and rankings over years, someone renames a folder in a refactor, and the old address starts returning "not found". The content is fine. The page is simply gone as far as search is concerned.
So before a production deploy we list every URL in the sitemap, and after it we check that every one still answers. On our last frontend deploy that was 301 of 301. Any route that changes on purpose gets a permanent redirect, written into the framework's redirect configuration so the server answers it, not a script in the browser. If you are planning a redesign or a move, that before-and-after list is the one document you can't skip, and it belongs in the same plan as any website rebuild.
Markup should describe the page, not decorate it
Structured data, the JSON-LD block in a page's head, helps a good page be understood. It doesn't rescue a weak one. The types that earn a place on most product sites are Organization and WebSite everywhere, BreadcrumbList matching the visible breadcrumb, SoftwareApplication for the product, BlogPosting for articles, Offer where prices are actually shown, and FAQPage only where the questions are visible on the page.
The rule that matters is that the markup says what a visitor sees. Google's structured data guidelines are explicit about it. We generate ours from the same data that renders the page, so the two can't drift. If you are writing it by hand, a schema markup generator saves typos but not judgement.
Content still matters. Templates don't count as content
We are not saying writing is irrelevant. Once crawlers can read the page, the words decide how far it goes. But the words that work on product sites are specific: a page that answers one real question better than anything else, with experience behind it.
Storafleet, our multi-cloud storage product, has a public step-by-step connection guide for each storage provider, 52 of them, because people search for exactly that task when they are evaluating a tool. They are public, not behind a login, which is the whole reason they can be found. The Storafleet case study shows them. Our own integrations, guides and comparisons follow the same rule: one question per page.
What doesn't work is the opposite: one page per city or industry with the name swapped in, auto-generated posts, thin pages stamped from a template. Google's spam policies treat scaled low-value content as a problem whatever made it. A new product site won't outrank established names for its category's biggest phrase in year one. It can answer the narrow questions buyers type on the way to a decision, which are closer to a purchase anyway.
Speed, briefly
Fast for real visitors on ordinary phones, not on the developer's laptop. The culprits on product sites are dull and repeatable: hero images uploaded at full size, the whole app's JavaScript loaded on a marketing page, chat widgets and tags that block the first paint. A CDN and sensible caching do much of the rest. Speed work helps every page at once, which makes it the best-value technical fix after rendering.
AI assistants want the same thing
There is a lot of new vocabulary around being cited by AI assistants. Underneath it, they need what Google needs, only more so: text in plain HTML, a direct answer near the top, named facts and dates. Decide deliberately which AI crawlers you allow in robots.txt (a robots.txt generator helps with the syntax). There is no report for AI citations, so the only check is to ask the assistants your buyers use the questions your buyers ask, and see whether you turn up.
Where we'd put the first hour
Fetch your three most important pages with JavaScript off and read the response. If the text is there, write the one-intent-per-page map next. If it isn't, fix rendering before anyone writes another word, because nothing else counts until crawlers can read it.
Then give search an owner. The pattern we see most often isn't a technical mistake at all; it's that nobody is responsible after launch, so nothing gets measured and nothing improves. That ongoing work is what our SEO for apps and SaaS programme does each month, and the SaaS launch checklist lists the search items to settle before a product site goes live. If the terms here are new, the SEO glossary entry is a gentler start.