Ship · SEO

SEO services for apps and SaaS: be the page that answers your buyer's question

We do SEO for web apps, SaaS products and mobile app websites from the engineering side up. We make sure search engines and AI answer engines can read every page, map each question your buyers search for to one page that answers it properly, and measure the result in Search Console, from impressions through to sign-ups.

Most products have an SEO problem that no content plan can fix: pages rendered only in the browser, five URLs competing for the same query, or a sitemap that lists pages that no longer exist. Developers fix those. Then the content has something solid to stand on.

Updated

The search funnel, from crawl to customer
  1. CrawledSearch engines can reach the page
  2. RenderedThe content is in the HTML they receive
  3. IndexedThe page is stored and eligible to appear
  4. ShownIt appears for the questions buyers ask
  5. ClickedThe title and snippet earn the visit
  6. Signed upThe page leads somewhere that works

Where is it stuck?

Find the step where your search traffic stops

Search traffic is a funnel, and each step fails for different reasons. Search Console shows you which step yours stops at. Pick the one that sounds familiar.

Google isn't indexing our pages

Make the pages readable and worth storing

Usually technical: pages that render only after JavaScript runs, canonicals pointing at the wrong URL, redirect chains, a robots file blocking more than it should, or thin pages Google decides are not worth keeping. We check what the crawler actually receives, page type by page type, and fix the cause rather than resubmitting URLs.

What we look at first

  1. Fetch each page type as a crawler sees it
  2. Canonicals, redirects and robots rules
  3. The sitemap against the URLs that really exist
  4. The Search Console indexing report, reason by reason

First step: Send us your domain and, if you have it, view access to Search Console.

Send it to us

Indexed, but nobody sees us

Match pages to what buyers actually search

If pages are indexed but rarely shown, they are either answering questions nobody asks or competing with each other for the same one. We map real buyer queries to single pages, merge the duplicates, and plan the pages that are missing.

What we look at first

  1. The queries you already appear for, segmented by intent
  2. Pages competing for the same query
  3. Gaps: questions buyers ask that no page answers
  4. One primary query per page, written down

First step: Send us the three products or services you most want to be found for.

Send it to us

We get impressions but no clicks

Earn the click you are already being offered

Showing up on page one with a weak title is the cheapest problem to fix. We rewrite titles and descriptions page by page, add the structured data that is eligible for your content, and check whether you are ranking for queries you can never convert, such as another brand's name.

What we look at first

  1. Titles and descriptions on high-impression, low-click pages
  2. Eligible structured data: breadcrumbs, FAQs, products
  3. Queries that inflate impressions and never convert
  4. Pages stuck just off page one

First step: Send us an export of your top pages from Search Console.

Send it to us

Clicks, but no sign-ups

Fix the steps after the click

A visitor who lands and leaves is often hitting something broken: a sign-up button that only works on mobile, a form that fails silently, or a page that answers the question and offers nothing next. We walk the journey from search result to sign-up on real devices and fix what breaks.

What we look at first

  1. Every call to action tested on desktop and phone
  2. The landing page's next step for each query type
  3. Conversion events checked, so results can be counted
  4. Page speed on real devices, not just lab scores

First step: Send us the page that gets the most search visits and where it is supposed to lead.

Send it to us

AI answers never mention us

Be readable, citable and corroborated

Many AI crawlers do not run JavaScript, so a client-rendered site is an empty page to them. Beyond that, answer engines cite pages that answer directly, with named and dated facts, and brands that other sites mention too. We fix what is technical and plan the rest.

What we look at first

  1. Content, metadata and schema present in the raw HTML
  2. A deliberate policy for each AI crawler in robots.txt
  3. Answer-first openings with sourced, dated facts
  4. A short, true llms.txt

First step: Send us five questions you would like an AI assistant to answer with your name.

Send it to us

We're launching a new site or redesign

Keep the search traffic you already have

A new site or a new framework is the moment most products lose search traffic, because URLs change, pages are merged or dropped, and redirects are forgotten. We list every URL that earns impressions today, map each one to its new home, ship the redirects with the launch and watch Search Console closely for the weeks after.

What we look at first

  1. Every URL with impressions in the last months
  2. A one-to-one redirect map, with no chains
  3. Titles, schema and internal links carried over
  4. Indexing and errors watched daily after launch

First step: Send us the launch date and the old and new site maps, as far as they exist.

Send it to us

What you get

What an SEO engagement delivers

SEO done well leaves behind documents and code, not just a report. These are the pieces, and each one stays useful after we have gone.

your-site

  • Keyword-to-URL map

    Every query that matters to your business, assigned to exactly one page, with its intent and the pages it must not compete with. It is the document that stops your site arguing with itself.

  • Technical audit and fixes

    Rendering, canonicals, redirects, sitemap, robots rules, structured data, page speed and mobile parity, checked page type by page type. Because we are developers, the fixes come as code, not as a list for someone else.

  • Page plans

    For each new or rewritten page: the question it answers, the direct answer at the top, the sections, the facts it needs and where they come from, and the pages it links to and from.

  • Structured data

    JSON-LD for what is actually visible on each page: organisation, breadcrumbs, services, products, articles, FAQs. It is validated, and generated from the same data as the page, so the two cannot drift apart.

  • Search Console baseline

    The property verified, the sitemap submitted and a dated baseline of impressions, clicks, positions and indexing, so every change afterwards can be measured against something real.

  • Internal linking plan

    Which pages link to which, with what anchor text, so every important page is reachable in a few clicks and pages on one subject support each other. New pages ship with their inbound links in the same release.

  • Monthly decay watch

    Pages losing clicks at steady impressions, pages stuck just off page one, and queries with rising demand, reviewed every month, with the pages worth refreshing named.

  • AI answer checks

    Your most important queries run through the main AI assistants each month, with a record of whether you are cited and which page they used.

How we run it

The SEO programme, step by step

SEO is a loop, not a launch. These seven steps run once in full, then keep turning every month, with most of the effort going wherever the data says it is needed. The first full turn takes the longest, because it includes the technical fixes; after that, each month is mostly measuring, refreshing and adding the pages the data asks for.

  1. Baseline

    Search Console verified, the sitemap submitted, and today's impressions, clicks, positions and indexing recorded with a date. Without a baseline, nobody can tell whether anything worked.

  2. Map queries to pages

    One primary query, one page. Where two pages compete, one becomes the answer and the other links to it or redirects. Demand is confirmed before anything new is built, because a clever idea is not the same as a search people make.

  3. Make every page readable

    Content, titles, canonicals and structured data in the HTML the server sends. We check it the blunt way, by fetching the page without a browser and reading what comes back.

  4. Answer first

    Each page opens with a direct answer to its question, then gives the detail: tables, steps, dated facts and real screens. First-hand experience is the one thing generic competitors cannot copy, so we use it, and never invent it.

  5. Link the cluster

    Pages on one subject link to each other with descriptive anchors, and a new page ships with its inbound links in the same release. An orphaned page earns nothing.

  6. Measure the whole funnel

    Impressions, clicks, sign-ups and the steps between, checked on desktop and phone. A broken form after the click destroys more value than any ranking factor.

  7. Refresh what decays

    Monthly, from the data: pages losing clicks, titles that lost their click rate and pages one push from page one. Old pages that rank get refreshed before new pages get built.

Developer SEO

The SEO work only engineers can do

A marketing agency can write a brief. These fixes live in the code, the build and the server, and most products need them before content can help. We work in Next.js, React and Node every day, so this is our home ground.

rendering
Content, metadata and JSON-LD in the server HTMLMany AI crawlers do not run JavaScript; a client-only page is blank to them.
canonical
One self-referencing canonical per page, one URL per intentQuery strings, trailing slashes and www variants all collapse to one address.
redirects
Permanent 301s for moved pages, with no chainsEvery retired URL points straight at its replacement, never through a hop.
sitemap
Generated from the same data as the pagesA page that exists is listed; a page that was removed disappears from the list.
og:image
A real image per page, at least 1200×630, PNG or JPGShared links look like your page, not like a generic banner.
schema
Structured data only for what is visible on the pageMismatched schema breaks Google's rules; we generate both from one source.
robots
A deliberate decision for each AI crawlerAllow the crawlers that cite; decide separately on the ones that only train.
llms.txt
A short, true summary of the site for AI systemsCheap to build, and kept in step with the pages automatically.
html size
Initial HTML kept leanGoogle reads only the first 2 MB of a page's HTML.
breadcrumbs
Visible breadcrumbs with matching structured dataThey still show in search results and tell crawlers where a page sits.
404s
Real 404 status codes for missing pagesA 'not found' page that returns 200 is a soft 404; search engines treat it as thin content.
images
WebP or AVIF, sized, lazy below the fold, never lazy for the heroThe largest image on screen decides how fast the page feels.

Pages that earn search traffic

Which pages should a SaaS or app website have for SEO?

A home page and a pricing page answer almost no searches. The traffic that turns into customers usually lands on pages built for one specific question. These are the page types we plan for products, each shown the way it can appear in search, with what it has to contain to deserve the click.

  1. Feature pages

    One page per feature buyers search for by name. Each needs real screens and a plain answer to "can it do X?", including what it can't do yet.

  2. Integration pages

    People search for your product together with the tools they already use. Each page should explain the setup step by step and what data moves where.

  3. Comparison pages

    Buyers near a decision search for comparisons. These pages only work if they are fair, and they must be kept up to date when either product changes.

  4. Reference tables and data

    Pages people come back to and cite. They are the hardest for competitors to copy if the data is real and kept current.

  5. Free tools

    A useful tool answers a task-shaped search and earns links on its own. It should work instantly, without a sign-up, and lead naturally to the product.

  6. Docs and help pages

    Setup and troubleshooting searches come from people who are trying the product right now. Public, server-rendered docs catch them at the best moment.

  7. Glossary and explainer pages

    Early-stage searchers learn the vocabulary before they buy. A good glossary page answers in the first sentence and links to the feature that uses the idea.

  8. Alternative and switching pages

    People unhappy with a current tool search for a way out. These pages must be specific about the move itself, not just a list of reasons to leave.

  9. Use-case and industry pages

    Only where the product really serves that audience differently. A page that swaps the industry name into a template is exactly what search engines filter out.

The URLs, titles and snippets above are illustrations of each page type, not pages we have built for a client.

Where the method comes from

We run this programme on our own site first

We don't quote traffic numbers we can't stand behind. What we can show is the system we run on countrydevs.com and the search-ready products we have built.

  • Each page we plan gets one primary query, recorded with the pages it must not compete with
  • Titles and descriptions are checked for length before a page can be published
  • FAQ questions are checked for duplicates across every content file on the site
  • Every metric on a case study must name its source, or it is cut
  • The sitemap and llms.txt are generated from the same data as the pages
  • New pages are checked with JavaScript off, so we know their text is in the raw HTML
  • Search Console is verified, with the sitemap submitted and a dated baseline
  • Retired URLs redirect permanently to their replacement, from one list in the code, so no old link dead-ends
  • A pre-publish checklist covers metadata, schema, links, rendering and the funnel
Storafleet documentation page with a step-by-step guide for connecting a Cloudflare R2 bucket
Storafleet, our own product, publishes a step-by-step connection guide for each storage provider it supports. Each guide answers a real setup question, so each is a page someone can find in search. Read the Storafleet case study

What we will not do

SEO tactics we refuse to use

These are sold as SEO every day. They either break Google's rules or stop working the week they are noticed.

  • Buy links

    Paid link schemes risk a manual penalty. We earn mentions with useful pages, tools and data instead.

  • Mass-produce pages

    Hundreds of near-identical pages are what Google's spam policies target. Every page we plan has to add something its siblings don't.

  • Guarantee rankings

    Nobody controls Google's results. We commit to the work and to measuring it honestly.

  • Fake experience

    No invented reviews, testimonials or "we tested this" claims. A false experience claim is worth less than no claim at all.

  • Hide or stuff keywords

    No hidden text, no keyword lists in footers, no phrases repeated until they read like a robot wrote them. Pages are written for the person searching.

  • Chase vanity rankings

    Ranking for another brand's name or for searches that never convert makes charts look good and sells nothing. We optimise for your buyers' questions.

Decisions you will face

Which SEO choices actually matter for a SaaS or app?

ChoiceOption AOption BOur usual advice
How pages renderServer-rendered or static HTMLRendered in the browser onlyServer-render every public page; keep the app itself behind sign-in client-side if you like
What to writeReference pages, guides, tools and comparisonsA blog with news and opinion postsReference pages and tools earn repeat visits and citations; a blog is for occasional depth
How pages are madeHand-written, page by pageProgrammatic, from dataProgrammatic only where each page has its own real data; never as templated filler
Where the app livesSame domain as the marketing siteA separate domainThe same domain where possible, so the site's authority helps the docs and help pages
How to measureSearch Console, plus conversions by pageRank-tracker positions alonePositions without clicks and sign-ups don't tell you whether SEO is working
What to fix firstPages that already rank, but just off page oneBrand-new pages for new topicsRefresh what already ranks before building new; it is usually the faster win

What you see each month

The monthly SEO report, and what each part tells you

One page, written in plain language, with the numbers in Search Console as the source. It answers three questions: what changed, why we think it changed, and what we will do next.

  1. The funnel

    Impressions, clicks, click-through rate and sign-ups from search, against the baseline and last month, with brand searches split out so they don't flatter the numbers.

  2. Pages that moved

    The pages that gained or lost the most clicks, with the queries behind the change and whether it came from ranking, click rate or demand.

  3. Striking distance

    Pages ranking just off page one for queries worth having, and the specific change we propose for each: a better answer, a missing section, a stronger title or more internal links.

  4. Health

    Indexing errors, new 404s, redirect problems, Core Web Vitals from real-user data and anything a product release changed in the HTML search engines receive.

  5. AI answers

    Your key questions run through the main AI assistants: whether you were cited, which page was used and which competitor was cited instead.

  6. Next month

    The three to five pieces of work we will do next, in priority order, so the report always ends in decisions rather than charts.

Where SEO sits

SEO starts in Build and keeps going in Ship

The cheapest SEO decisions are made while a product is being built: how pages render, how URLs are shaped, what the sitemap is generated from. After launch, SEO becomes part of the monthly rhythm.

  1. From Build

    Server-rendered public pages, clean URLs and metadata generated from the same data as the page.

  2. SEO

    Baseline, keyword-to-URL map, technical fixes, page plans, structured data and the monthly decay watch.

  3. Every month

    Refreshes from the data, new pages where demand is proven, and checks that the funnel still works after each release.

Questions about SEO for apps and SaaS

What is technical SEO for a SaaS or web app?

It is the part of SEO that lives in the code: making sure public pages render on the server, have one canonical URL each, redirect cleanly when they move, appear in a sitemap generated from the same data, carry structured data for what is visible, and load fast on real phones. Content can only rank once these are right.

Can you do SEO for a site built with React or Next.js?

Yes; it is the stack we build websites and web apps in every day. With Next.js, public pages can be rendered on the server or built as static HTML, metadata and structured data can be generated per page, and the sitemap can come from the same source as the pages. A React app that renders only in the browser usually needs its public pages moved to server rendering first.

How long does SEO take to show results?

Technical fixes can change indexing within weeks, once search engines recrawl. Rankings for competitive queries take months, and depend on how strong the competing pages are and how much other sites mention you. We report monthly against a dated baseline, so you can see what moved and why.

Do you guarantee first-page rankings?

No. Nobody controls search results, and a guarantee is usually a sign of tactics that break Google's rules. We commit to the work, the fixes and honest measurement: impressions, clicks and sign-ups, page by page.

How do you get a product mentioned in AI answers?

First, make sure AI crawlers can read the pages at all, since many do not run JavaScript. Then write pages that answer directly, with named and dated facts that can be quoted, and earn mentions on other sites, because answer engines trust brands that independent sources also mention. We check your key queries in the main AI assistants each month and record whether you are cited.

Do you write the content as well as the technical fixes?

We plan every page and write the pages that need product and engineering knowledge: features, integrations, comparisons, guides and reference tables. For pages that need your own experience, such as case studies or expert opinions, we interview you and write from what you tell us, never from invented claims.

What do you need from us to start SEO work?

Access to the website's code or CMS, view access to Search Console (we can set it up if it doesn't exist), the products and audiences you most want to be found by, and someone who can answer product questions. If your developers are another team, we can work through pull requests in their repository.

Can SEO be part of a monthly maintenance plan?

Yes. After the first round of fixes and pages, the monthly work is the decay watch, refreshes, the AI answer checks and making sure each product release doesn't quietly break pages, redirects or the sign-up funnel.

Send us your domain. We'll show you where search stops.

Your site, the products you want to be found for and, if you have it, view access to Search Console. We reply with the first fixes we would make and why.