Technical SEO for SaaS Startups
We don't write your blog posts. We fix the technical reasons your pages aren't ranking: prerender, schema, Core Web Vitals, sitemap, internal linking, indexability. The engineering work most SEO agencies hand back to your dev team and hope they get to it.
What we fix
- Prerender, SSG and SSR per route
- JSON-LD structured data
- Core Web Vitals (LCP, CLS, INP)
- Sitemap, robots and canonicals
- Internal linking architecture
- Search Console and log monitoring
Who this is for
Who our technical SEO service is for
- SaaS founders whose pages don't get indexed despite shipping content
- Product teams that built on a SPA and now realise Google can't see half of it
- Companies with a content team writing well, but rankings flat or sliding
- Founders who got an SEO audit back and have no idea who can actually fix it
- Teams migrating to Next.js, Astro, or another framework who want SEO done right the first time
Probably not a fit
We'll be honest if a different team is the right call
- Pure content marketing engagements: we don't write your blog posts
- Link building or PBN-style campaigns: not what we do
- Local SEO or Google Business Profile optimisation
- Sites with under 50 pages where the issue is simply not having content yet
Case study · This site
Stack
Vite · React Router · Helmet · Prerender SSG
Technical SEO implementation for SaaS marketing sites
appycodes.dev had the same problem most SaaS sites have: too many thin pages competing for the wrong terms, almost none indexed by Google, generic templated content with mismatched FAQs, no structured data in the prerendered HTML, and a sitemap full of URLs that Google had quietly ignored.
The rebuild was straight engineering. We pruned the sitemap from 37 URLs down to 9 high-quality pages, then deliberately added new pages targeting winnable, intent-driven keywords, each with full JSON-LD schema (Service, BreadcrumbList, FAQPage, Article) baked into the prerendered HTML so crawlers see it on the first request, not after JavaScript executes.
We fixed the prerender pipeline itself. The previous version was silently dropping every script tag that React Helmet emitted, which meant zero structured data was reaching Google despite being in the React tree. We added 301 redirects for the legacy URLs Google had indexed but no longer existed, rebuilt the internal linking from nav, footer, and the /services/ index, and shipped each new page at 2,000+ words with embedded case studies and opinionated technical content.
This page is one of those new pages. The work it describes is the same work we ran on this site. You can inspect the source to verify.
How we approach technical SEO
What's included in our technical SEO service
These are the technical choices that actually change what Google sees and how it ranks your pages. We have strong opinions on each, formed from shipping SaaS sites that needed to compete in real SERPs.
Rendering: SSG by default, SSR for dynamic, SPA for app
Marketing pages should be static (SSG or prerender). Pages that depend on logged-in state should render server-side or remain SPA. The mistake most SaaS sites make is choosing one rendering strategy for the whole site. We split per route. Crawlers should see complete HTML on first byte for everything they need to rank.
Structured data: JSON-LD in the prerendered HTML
Service, Product, Article, FAQPage, BreadcrumbList, Organization, Person, chosen per page type, not blanket-applied. We verify with Google's Rich Results Test before considering it shipped. Critically, the schema must land in the static HTML, not be inserted later by JavaScript. We have seen many sites where the schema exists but Google never sees it.
Core Web Vitals: LCP, CLS, INP
We profile real user metrics from CrUX or your own RUM data, not synthetic Lighthouse scores. The fixes are usually the same handful of patterns: defer or remove heavy third-party scripts, preconnect to font hosts, set explicit dimensions on images, lazy-load below the fold, swap heavy fonts, replace images with modern formats. Lighthouse 100 is not the goal, passing field data is.
Indexability: robots, sitemap, canonicals, internal links
A page is not indexed unless Google can crawl it, render it, and conclude it deserves to be indexed. We check robots.txt, sitemap freshness, canonical correctness, hreflang if international, and the internal link graph that signals page importance. Orphaned pages with no internal links almost never rank.
Site architecture: flat depth, intentional clusters
Two clicks from the homepage to any important page. Topic clusters where pillar pages link to detail pages and vice versa. Avoid deep folder nesting unless the URL hierarchy adds genuine value. We restructure URL trees when needed but always with 301s and the patience to wait for Google to recrawl.
Monitoring: Search Console, log files, RUM
After the work ships, we set up Search Console properly, run weekly checks on indexation and Core Web Vitals, and monitor server log files to see what Googlebot actually crawls vs ignores. Without monitoring, you don't know whether the work paid off, you're guessing from rank trackers, which lag and lie.
Technical SEO for programmatic and calculator pages
Easyship is a global shipping platform now valued over $40M. More than 100 calculator engines power their site: quote tools that compare carriers, rules, surcharges, and customs across 200+ countries. Each one is a high-intent commercial query (think "USPS to UK shipping calculator") that should rank.
The technical SEO challenge with calculator pages is that they're fundamentally interactive: users pick options and the result computes client-side. That makes them dangerous for crawlers if rendered the wrong way. Google sees an empty form; the page looks thin and gets demoted or skipped entirely.
The right pattern is to ship a meaningful default state in the static HTML, populated with realistic values, real explanatory copy, an example calculation, and proper schema for the service being offered. The interactive calculator layers on top once JavaScript runs. Crawlers get a full page; users get a working tool. That principle is the difference between calculator pages that rank and calculator pages that don't.
Case study · Shipping SaaS
Stack
React · TypeScript · Node.js · Vue.js
First-pass diagnostics
The technical SEO signals we check first on every audit
Before we recommend anything, we measure. These are the seven signals we hit in the first hour of every technical SEO audit: what "healthy" looks like, and what we usually see when the page isn't ranking. If your site fails three of them, this is what's blocking your SEO ceiling, not your content.
Indexable HTML on first response
What good looks like
Server returns rendered HTML with content, headings and links, no JS execution required.
What we see when it's broken
Empty root div, content only appears after JS hydration. Googlebot defers and may never come back.
Canonical URL points to itself
What good looks like
Self-referencing canonical with an absolute URL, matching the page that was actually served.
What we see when it's broken
Canonical points to /, to a parameter-stripped variant, or to a different language version Google doesn't expect.
Sitemap is fresh and accurate
What good looks like
sitemap.xml lists exactly the URLs you want indexed; lastmod dates reflect real change dates.
What we see when it's broken
Static sitemap that hasn't updated in 6 months, contains 404s, missing the new pages, or noindex pages still listed.
Core Web Vitals on real devices
What good looks like
LCP under 2.5s, INP under 200ms, CLS under 0.1 on a Moto G4 / iPhone SE, not on your dev machine.
What we see when it's broken
Heavy unused JS on landing pages, layout-shifting hero images, INP blocked by analytics on first interaction.
JSON-LD structured data validates
What good looks like
Organization, Breadcrumb, FAQPage, Article and Service schemas pass the Rich Results test cleanly.
What we see when it's broken
Stray HTML in JSON-LD strings, missing required properties, conflicting types on the same page.
Internal links from indexed pages
What good looks like
Every important page has at least three in-prose links from other indexed pages on the same domain.
What we see when it's broken
Orphan pages reachable only from the nav or footer. Google treats them as low-priority and may not index.
Server response time and 5xx rate
What good looks like
TTFB under 200ms from major regions, 5xx rate under 0.1%, no random timeouts during peak crawl windows.
What we see when it's broken
Cold-start serverless functions giving 800ms+ TTFB, intermittent 5xx during crawl, no monitoring in place.
How we work
Our technical SEO process
Technical audit
Crawlability, indexability, rendering, structured data, Core Web Vitals, site architecture, on-page signals. You get a written audit with a prioritised fix list, not a generic PDF, not a sales document.
Quick wins first
Robots, sitemap, canonical, broken redirects, indexation issues, missing meta: the changes that ship in the first sprint and start moving Search Console signals immediately. We do these before touching anything that takes longer.
Rendering and prerender
Move marketing pages to SSG or prerender. Verify the rendered HTML matches what users see. Check that JavaScript-injected content (titles, schema, internal links) actually lands in the static output. This is where most SaaS SEO work breaks silently.
Structured data
Add JSON-LD per page type. Verify with Google's Rich Results Test. Check that the schema is in the prerendered HTML, not inserted later. Add Organization, BreadcrumbList, and Article or Service schemas across the site as appropriate.
Core Web Vitals
Profile real user metrics. Fix LCP (defer scripts, preconnect fonts, optimise hero images), CLS (set image dimensions, reserve space), INP (split long tasks, defer non-critical JS). Re-measure with field data, not Lighthouse.
Internal linking and monitoring
Rebuild navigation, footer, and contextual internal links to signal page importance properly. Set up Search Console correctly, configure indexation monitoring, and check server logs for Googlebot crawl patterns. Hand over a written runbook of what to watch and when to act.
Honest comparison
Why choose Appycodes for technical SEO
| Capability | SEO agency | Solo SEO consultant | In-house dev | Appycodes |
|---|---|---|---|---|
| Technical engineering depth | Limited | Limited | High | High |
| Ships fixes in production | Hands off to your dev team | Hands off to your dev team | Yes | Yes |
| Ranking strategy and intent | Yes | Yes | Rarely | Yes |
| Schema, prerender, CWV done right | Sometimes | Sometimes | If they prioritise it | Yes |
| Time to ship first fixes | 4-8 weeks | 4-6 weeks | Whenever it gets prioritised | 1-2 weeks |
| Owns code that lands | No | No | Yes | Yes |
| Writes content | Often | Sometimes | No | No |
None of these is universally right. A traditional SEO agency is the best call when your bottleneck is strategy, not engineering. We are the best call when an audit has already told you what's wrong and the problem is that nobody on your team has the time, context, or engineering depth to actually ship the fixes.
Content SEO is what you write: keyword targeting, intent matching, depth, freshness. Technical SEO is whether Google can crawl, render, and trust what you've written. We do the second. Most SaaS sites underperform because the technical layer is broken: pages that don't get indexed, structured data that's missing or wrong, JavaScript that crawlers can't execute. Fix that first and your existing content starts working.
It's not a problem if it's set up correctly. It is a problem if your pages render entirely client-side and Googlebot only sees an empty shell. We move SPA sites to prerender, SSG, or SSR depending on the route: paid-content pages get SSR, marketing pages get SSG, the dashboard stays a SPA. Most SaaS sites get this wrong by being fully one or the other.
Crawlability (robots, sitemap, internal links), indexability (canonical, noindex, hreflang), rendering (does Google see what users see), structured data (Service, Product, FAQ, Article schemas), Core Web Vitals (LCP, CLS, INP), site architecture (depth, internal linking, orphaned pages), and on-page signals (titles, descriptions, headings). You get a written audit with a prioritised fix list, not a generic PDF.
Yes. Real Core Web Vitals work is engineering work, not configuration. We profile real user metrics, find the actual bottlenecks (usually a third-party script, an unoptimised image, or a render-blocking font), and ship fixes in your codebase. We don't just install a 'speed plugin' and call it done.
Indexation issues fix in days. Core Web Vitals improvements show in Search Console within two to four weeks. Ranking shifts from technical fixes typically show over six to twelve weeks as Google recrawls and reweights the site. We do not promise rankings, we promise that the technical reasons holding you back will be removed.
Yes. JSON-LD for Service, Product, Article, FAQ, BreadcrumbList, Organization, and Person schemas. We add what's appropriate and verify it with Google's Rich Results Test. Schema isn't a magic ranking signal, but it is an eligibility requirement for rich results and a clear quality signal to crawlers.
We build programmatic SEO systems where the data model genuinely supports it: comparison pages, location pages, integration pages, calculator pages. We are honest when programmatic SEO is the wrong call: thin pages that exist only to rank are an active risk under Google's helpful-content systems. The bar for programmatic SEO is higher than it was three years ago.
Yes, and most engagements are structured this way. Your SEO team identifies opportunities and writes the briefs. Your content team writes the pages. We make sure the technical foundation supports both. We are happy to be the engineering side of an existing SEO function rather than replacing it.
We work across modern stacks (Next.js, Astro, Remix, plain React) and traditional CMSes (WordPress, Webflow, Shopify). The principles are the same; the implementation details differ. We will tell you honestly when a platform's limitations mean you've hit a ceiling that no amount of technical SEO will move past.
Most SEO agencies are strong on strategy and content, weaker on engineering. They send you a deck of recommendations that your dev team then has to implement, and often doesn't. We are the dev team. Recommendations land in production, not in a backlog. If your bottleneck is execution rather than strategy, that's the difference.

Ritesh · Founding Partner, Appycodes
Ritesh leads engineering at Appycodes and has spent the last decade shipping SaaS products for funded startups across the UK, US, India and Australia. His focus is on production engineering, including the technical SEO work that quietly determines whether a SaaS product's content compounds or stalls.
Technical SEO
Got an audit you can't get shipped? Let's fix the technical reasons you aren't ranking.
More in SEO, Cloud & Support
Web & SaaS
Mobile Apps
E-commerce & Payments
WordPress
CMS & Platforms
SEO, Cloud & Support
37 services across 7 practice areas.