Technical SEO Audit: The 15-Point Checklist for SaaS

Most SaaS sites bleed rankings not because the content is bad, but because the technical foundation quietly rots. A landing page ships, a marketing team A/B tests a hero section, an engineer merges a route change, and six weeks later organic traffic is flat while competitors climb. A technical SEO audit is the boring, high-return work that fixes this. Done properly, it exposes crawl waste, indexing conflicts, render-blocking scripts, and schema mistakes that block Google from understanding what your product actually does. This 15-point checklist is the exact sequence we run on every SaaS site during a QwiklyLaunch 45-day sprint before we touch a single keyword. Follow it in order. Do not skip. Each item takes 15 to 60 minutes and compounds into the kind of rank movement your CEO will notice inside a quarter.

1. Verify Crawlability Before Anything Else

The first job of any audit is confirming Googlebot can actually reach your pages. Pull your robots.txt and read it line by line. A single stray Disallow: / in a staging config that leaked to production has killed more launches than bad copy ever will. Then run a full crawl using Screaming Frog or Sitebulb with a user agent set to Googlebot Smartphone. Compare the total URLs crawled against your sitemap. If the crawler returns 8,000 URLs and your sitemap lists 400, you have orphan pages and parameter bloat. Both waste crawl budget.

What to fix in the first pass

• Remove Disallow rules that block CSS, JS, or product pages
• Fix redirect chains longer than two hops
• Kill soft 404s that return 200 status codes
• Consolidate parameter URLs with canonical tags

For SaaS apps with authenticated dashboards, explicitly block /app/, /dashboard/, and API routes in robots.txt. Do not rely on noindex alone. Googlebot still burns crawl budget fetching pages it cannot render.

2. Audit Your XML Sitemap Like a Database Migration

Your sitemap is a promise to Google about what matters. Break the promise and trust drops. Every URL in the sitemap must return a 200 status, be indexable, be canonical, and be linked internally. Any URL failing those four conditions is a lie. Split sitemaps by content type: marketing pages, blog posts, programmatic pages, and glossary. Keep each under 10,000 URLs even though the spec allows 50,000. Smaller sitemaps make Search Console diagnostics far more precise. Submit the index sitemap, not the individual files. Then verify submission status weekly for the first month after launch.

3. Check Rendering, Not Just HTML

Modern SaaS sites are built on Next.js, Remix, or SvelteKit. If your pages hydrate client-side, Google may index a shell with no content. Use the URL Inspection tool in Search Console on ten critical pages, request the rendered HTML, and search for your actual product copy. If the rendered version is missing headings, prices, or feature descriptions, you have a rendering problem that no keyword work can fix. Move to server-side rendering, static generation, or streaming SSR immediately. This single fix has recovered six-figure organic pipelines for teams we work with in SaaS development engagements.

4. Core Web Vitals Field Data Beats Lab Data

Lighthouse scores lie. They run on a simulated network from your laptop. What matters is Chrome User Experience Report field data, which reflects what real users on real devices experience. Pull the CrUX report from PageSpeed Insights for your top 20 pages. Look at the 75th percentile for LCP, INP, and CLS. If LCP is above 2.5 seconds or INP is above 200 milliseconds on any high-value page, you are losing rankings you would otherwise win. Fix hero image sizing, defer non-critical JavaScript, and preload your primary font. Do not chase the 100 Lighthouse badge. Chase green field data.

5. Indexation Coverage Report Deep Dive

Open Search Console, go to Pages, and read every excluded reason like a bug report. Discovered - currently not indexed means Google found the URL but decided it was not worth crawling. This is a quality signal problem. Crawled - currently not indexed means Google fetched the page and rejected it. That is a content quality problem. Duplicate without user-selected canonical means your internal linking is confusing Google about which version wins. Each bucket needs a different fix, and lumping them together is why most audits fail to produce results.

6. Internal Linking Structure and Depth

Every important page should sit within three clicks of the homepage. Run a crawl depth report and identify any revenue page deeper than four clicks. These are pages Google visits monthly instead of weekly. Add contextual links from high-authority pages. Build hub pages that link to related content clusters. If your product has an integrations directory, make sure every integration page links back to the parent category and to two sibling integrations. This is the same pattern that powers growth and marketing flywheels on established SaaS sites.

7. Schema Markup Validation

Structured data is not optional for SaaS in 2026. At minimum implement Organization, WebSite with SearchAction, BreadcrumbList on every non-homepage URL, and SoftwareApplication or Product on your pricing and feature pages. FAQPage schema on support and blog articles still triggers rich results in many verticals. Validate every template with the Rich Results Test, not the deprecated Structured Data Testing Tool. Fix warnings, not just errors. A missing aggregateRating on Product schema will not block indexing but will cost you the star display in results.

Schema priorities for a new SaaS

1. Organization on the homepage with logo and sameAs links
2. Product with offers on pricing pages
3. FAQPage on blog posts and help articles
4. Article with author on all blog content
5. BreadcrumbList on every deep page

8. HTTPS, HSTS, and Mixed Content

Every URL on your site must serve over HTTPS with a valid certificate that renews automatically. Enable HSTS with a max-age of at least one year and submit to the preload list. Scan for mixed content warnings using the browser dev console on your ten most-visited pages. A single HTTP image reference on a checkout page will trigger a browser warning that tanks conversion and signals low quality to Google.

9. Mobile Usability and Viewport Configuration

Google indexes the mobile version first. If your mobile layout hides content behind tabs or accordions that require JavaScript to expand, Google may still see it but weights it lower. Font size below 16 pixels on body text, tap targets smaller than 48 pixels, and horizontal scroll are the three killers. Test on a real Android device, not just Chrome dev tools. Emulators lie about touch behavior and font rendering.

10. Duplicate Content and Canonicalization

Every URL must have exactly one canonical version. Www versus non-www, HTTP versus HTTPS, trailing slash versus none, uppercase versus lowercase, and query parameters all create duplication. Pick one convention and enforce it with 301 redirects. Then add self-referencing canonical tags to every page. For paginated content use rel next and rel prev signals in HTML, and let Google decide. Do not canonical page two to page one. That hides content from the index.

11. JavaScript SEO for App-Like Sites

If your marketing site is a single-page app, you are fighting an unnecessary battle. Move to a framework that renders HTML on the server. If migration is impossible in the short term, implement dynamic rendering as a stopgap using Prerender or Rendertron. Serve prerendered HTML to bots and the SPA to users. This is not cloaking when done correctly because the content is identical. This is exactly the kind of decision our web development team makes on day two of a 45-day sprint.

12. Log File Analysis

Server logs tell you what Googlebot actually does, not what Search Console reports. Pull 30 days of access logs, filter for verified Googlebot IPs, and analyze crawl frequency by URL pattern. If Googlebot spends 40 percent of its crawl budget on filter parameter URLs that return the same product list, you have a crawl waste problem worth fixing before you publish another blog post. Tools like Screaming Frog Log File Analyser make this a 30-minute job.

13. International and hreflang Setup

Skip this if you serve one language in one market. If you operate globally, hreflang mistakes will hide your pages from users in the wrong locale. Every language version must reference every other version, including a self-reference. Use x-default for your fallback. Validate with a dedicated hreflang testing tool. A single asymmetric tag on a language cluster will invalidate the entire annotation.

14. Image SEO and Media Optimization

Every image needs a descriptive filename, alt text that describes the image not stuffs keywords, width and height attributes to prevent layout shift, and lazy loading below the fold. Serve modern formats like WebP or AVIF with fallbacks. Compress every image. A homepage hero image should never exceed 200 kilobytes at any device size. This is a solved problem in 2026, so any team that ships uncompressed PNGs is signaling amateur hour.

15. Monitoring, Alerting, and Regression Prevention

An audit that is not repeated is a snapshot with a short shelf life. Set up automated monitoring for indexation drops, Core Web Vitals regressions, robots.txt changes, and canonical tag flips. Tools like ContentKing, Little Warden, or a simple GitHub Action that pings your sitemap weekly will catch regressions before they cost you revenue. Include SEO checks in your deploy pipeline the same way you include unit tests. The alert threshold matters. Do not fire on every tiny movement. Set alerts on 10 percent or more change in indexed URL count, robots.txt file diff, sitemap URL count diff, and Core Web Vitals passing rate drop. Anything more sensitive produces alert fatigue and gets muted. Anything less sensitive misses real regressions.

Alert channels that get action

• Slack channel dedicated to SEO alerts with real ownership
• Email digest weekly for lower priority anomalies
• PagerDuty rotation for indexation drops over 25 percent
• GitHub issue auto-created for structural changes to robots or sitemap

Prioritization After the Audit

A 15-item audit produces 30 to 90 findings on most sites. You cannot fix all of them at once. Prioritize by impact and effort. Impact means expected traffic recovery if fixed. Effort means engineering hours to ship the fix. Multiply the two into a score. The highest-scoring findings get fixed in the next sprint. Everything else queues. This forcing function prevents teams from spending three weeks on a cosmetic schema warning while a rendering issue hides 30 percent of pages from Google. Publish the priority list to the whole team so everyone understands the sequence and reasoning. Transparency prevents rework and misaligned expectations.

The impact-versus-effort matrix

1. Impact 5, effort 1: fix this week no matter what
2. Impact 5, effort 5: schedule for next quarter with dedicated engineering
3. Impact 2, effort 1: batch with other small fixes into a maintenance sprint
4. Impact 2, effort 5: usually kill it or defer indefinitely

Common Objections From Engineering Teams

SEO audits often surface findings engineering teams push back on. Common objections include we cannot change canonical patterns because they break the app, we cannot server-render because our stack does not support it, and we cannot fix Core Web Vitals because the design team owns hero images. These objections are usually solvable with a joint conversation between SEO, engineering, and design. Frame the fix as revenue recovery rather than cosmetic improvement and most objections evaporate. When they do not, escalate to the founder. The founder decides which revenue recovery projects get engineering time. SEO practitioners who fail to communicate impact clearly lose these battles even when the findings are correct.

Documenting Findings for Non-Technical Stakeholders

Most audit findings are highly technical. Founders and marketing leads often struggle to understand them. Document each finding in three layers. Layer one is a one-sentence business impact statement. Layer two is a plain-language explanation of the problem. Layer three is the technical detail for the engineer implementing the fix. This layered documentation prevents miscommunication and speeds up sign-off. Founders approve fixes faster when they understand the revenue impact. Engineers implement fixes faster when the technical detail is precise. Skipping the business layer produces audit reports that sit in Notion for months without action. Adding a rough dollar estimate for each finding is the single trick that frees engineering time from busy founders. Even a rough estimate like fifty to two hundred qualified visits per month is better than no estimate at all.

Rerun the Audit Every 90 Days

Sites drift. Features ship, developers rotate, dependencies update, and technical debt accumulates. Rerun the full audit every 90 days. Compare findings quarter over quarter. Track improvement metrics like indexation percentage, Core Web Vitals passing rate, and schema error count. Sites that audit quarterly stay in ranking shape. Sites that audit annually or never accumulate technical debt that eventually blocks growth. The 90-day cadence takes one to two working days per quarter for a mature site and pays for itself many times over. If you have never done a full audit, budget three days for the first one and one day for subsequent ones.

The pattern is always the same. Founders assume SEO is a content problem. It is almost always an engineering problem first. Fix the foundation, then publish. If you want a team that treats your technical SEO like a production system, talk to us about a 45-day launch sprint that includes a full audit and remediation. You can also see how we ship these fixes in real launches on the projects page.