The Complete Custom Website Checklist: SaaS & Web Applications (SEO + Security)

A SaaS website is really two sites in one: a marketing site that needs to rank and convert, and an application that needs to be secure, reliable, and completely walled off from search engines. Most of what gets missed on custom-built SaaS sites happens at exactly that boundary — marketing pages that leak app behavior, or app pages that leak into search results. This checklist covers both halves in full.

Marketing Site vs. App: Structural Separation

[ ] The public marketing site and the authenticated application are clearly separated, whether by subdomain or subdirectory
[ ] Every authenticated app page, dashboard, and user-account URL is set to noindex
[ ] Robots.txt explicitly disallows crawling of app, dashboard, and account paths
[ ] Marketing pages don't accidentally expose internal app routes or parameters in their links
[ ] A consistent choice has been made between subdomain (app.yoursite.com) and subdirectory (yoursite.com/app) structure, with authentication and DNS configured to match

> Tool tip: Use Find DNS Records to confirm your subdomain and DNS setup actually matches your intended marketing-versus-app structure before you rely on it.

Pre-Launch Technical SEO Foundations

[ ] XML sitemap includes only genuine marketing and content pages, not app or account URLs
[ ] Canonical tags are correctly set on every public marketing page
[ ] HTTPS is enforced everywhere, including every subdomain in use
[ ] URL structure for marketing pages (features, pricing, use cases, comparisons) is clean and descriptive
[ ] 404 handling returns genuine 404 status codes, not a soft 200 error page
[ ] Redirects from any previous URL structure are mapped as permanent 301s, not left as 302s

> Tool tip: Run the SEO Audit tool specifically against your marketing site's URL set to catch foundational issues before scaling content further.

On-Page SEO for Marketing Pages

[ ] Every marketing page has a unique, benefit-led title tag and meta description
[ ] Pricing page is genuinely indexable and optimized, not accidentally excluded
[ ] Comparison pages ("X vs. Y," "alternative to X") are built out deliberately, not left to competitors
[ ] Use-case and integration pages target specific, real search demand rather than generic feature descriptions
[ ] Feature pages avoid excessive overlap and internal cannibalization with each other

> Tool tip: Run your key page-to-keyword mapping through the Keyword Cannibalization Checker to catch overlapping feature or comparison pages competing for the same terms.

Documentation & Changelog SEO

[ ] Public documentation is indexable and structured with clear, crawlable navigation
[ ] Documentation pages have unique titles and descriptions, not a single templated default
[ ] A public changelog or release notes page exists and is kept current
[ ] API reference documentation, if public, is structured for both human readability and search visibility

Security: Authentication & Session Management

[ ] Passwords are hashed with a strong, modern algorithm, never stored in plain text or reversible encryption
[ ] Two-factor authentication is available, and ideally encouraged or required for admin-level accounts
[ ] Session tokens expire appropriately and are invalidated on logout and password change
[ ] Login endpoints are rate-limited against brute-force and credential-stuffing attempts
[ ] Password reset flows don't leak whether an email address exists in the system
[ ] OAuth and SSO integrations follow current best practices for token handling and scope limitation

Security: Multi-Tenancy & Data Isolation

[ ] Customer data is properly isolated between tenants, with no possibility of cross-account data leakage
[ ] API endpoints verify authorization on every request, not just authentication
[ ] Object-level access checks are enforced (a user can't access another account's data by simply changing an ID in a URL)
[ ] Admin and support tooling used to access customer accounts is itself access-controlled and logged

Security: API & Infrastructure

[ ] All API endpoints require proper authentication, with no unintentionally public routes
[ ] Rate limiting is applied to API endpoints to prevent abuse and resource exhaustion
[ ] Webhooks are signed and verified, not accepted from any source without validation
[ ] Dependencies and libraries are scanned regularly for known vulnerabilities
[ ] Environment variables and secrets are never committed to source control or exposed client-side
[ ] Security headers are configured: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options

> Tool tip: Check your domain's current DNS and mail authentication setup with Find DNS Records as part of a broader infrastructure security review, especially if transactional email is involved.

Payment & Billing Security

[ ] Payment processing is handled through a PCI-compliant provider, without raw card data touching your own servers
[ ] Billing pages and checkout flows are served exclusively over HTTPS
[ ] Subscription and billing webhook endpoints are authenticated and validated
[ ] Invoices and billing data are accessible only to the account owner and properly authorized users

Uptime, Status & Reliability

[ ] A public status page exists, separate from the main application, so outages can be communicated even when the app itself is down
[ ] Uptime monitoring is in place with alerting that reaches the right people immediately
[ ] A documented incident response process exists for outages and security issues
[ ] Database and infrastructure backups are automated, tested, and stored securely off-primary-infrastructure

> Tool tip: Use the Server Status Checker to independently verify your infrastructure's current response status as part of your broader uptime monitoring.

Trust & Compliance Signals

[ ] Security and compliance certifications (SOC 2, ISO 27001, GDPR compliance, etc.), if held, are clearly and accurately represented
[ ] A data processing agreement (DPA) is available for customers who require one
[ ] Privacy policy accurately reflects what customer and user data is actually collected and how it's used
[ ] Terms of service clearly define data ownership, especially for customer-generated content within the app
[ ] A clear, findable security contact or responsible disclosure process exists for reported vulnerabilities

Signup & Trial Funnel Tracking

[ ] Signup and trial-start events are tracked as defined conversions in analytics
[ ] Funnel tracking captures each meaningful step: visit, signup, activation, and conversion to paid
[ ] UTM parameters and campaign tracking are consistently applied across marketing channels
[ ] Analytics excludes internal team traffic from skewing conversion data

Performance

[ ] Marketing pages are tested for Core Web Vitals separately from the authenticated app experience
[ ] The application itself is tested for load performance under realistic, logged-in usage conditions
[ ] Third-party scripts on marketing pages (chat widgets, tracking pixels) are audited for their performance cost

> Tool tip: Run the Pagespeed Insights Checker against your top marketing landing pages specifically, since these are what most directly affects trial signup conversion.

Post-Launch Monitoring

[ ] Search Console is monitored regularly for indexing issues or a manual action
[ ] Dependency and vulnerability scanning runs on an ongoing, automated schedule
[ ] A recurring review confirms app/account pages haven't accidentally become indexed over time
[ ] Documentation and changelog pages are kept current as the product evolves

Next step: Run the SEO Audit tool against your marketing site as a final check — and revisit it after any significant infrastructure or URL structure change, since SaaS sites tend to accumulate technical debt quickly as the product evolves.