More than one website

A SaaS company runs several web properties that serve different people with different needs.

PropertyAudienceGoals
Marketing siteProspectsExplain value, build trust, convert to trial or demo
Blog and resourcesProspects and customersAttract search traffic, educate
Documentation and help centerUsers and developersReduce support, speed up adoption
Web applicationCustomersDeliver the product
Status pageCustomersCommunicate incidents
Customer portal or communityCustomersSupport, feedback
Partner or developer portalIntegratorsAPI access, listings

The marketing site and app often have different teams, release cycles and technology. Architecture decisions should reflect that.

Domain and URL structure

A common debate is subdomain versus subfolder.

  • Marketing at the root domain, app at a subdomain such as app.example.com, keeps authentication and product traffic separate.
  • Docs and blog as subfolders of the main domain generally keep their search authority together with the marketing site, while subdomains can be treated more separately by search engines. Many teams choose subfolders for content that should build marketing authority, though a subdomain can work when the platform requires it.
  • Reverse proxies or edge routing can present separately hosted systems under one domain, at the cost of extra configuration.

Whatever you choose, plan canonical URLs, cookies that work across subdomains where needed and consistent branding.

Marketing site approach

The marketing site needs speed, flexibility and editorial control. Options:

  • A CMS with themes, such as WordPress or a hosted builder. Fast to launch, editor friendly.
  • A headless CMS with a modern front-end framework, offering performance and design control with more engineering.
  • A static or hybrid build, with pages generated ahead of time and served through a CDN.

Choose based on who updates the site, how often and what interactivity you need. Marketers should be able to launch landing pages without developer tickets.

Keep the app separate

The application has different requirements: authentication, state, security and real-time behavior. Do not let marketing scripts load inside the app unless needed. Avoid putting the app in the same codebase as the content site unless there is a strong reason, as deployments become entangled. Public app pages, such as sign-in and sign-up, should be fast, simple and accessible.

SEO foundations

  • Server-render or pre-render public pages so content is available to crawlers.
  • Give each page unique titles, descriptions and headings.
  • Build clean URL structures for features, solutions, integrations and comparison pages.
  • Create programmatic pages, such as integration pages, only with genuine unique value for each.
  • Use XML sitemaps and structured data such as organization, software application and FAQ where appropriate.
  • Keep the app out of the index, except for intentional public pages.
  • Maintain redirects when you restructure.
  • Write documentation that is crawlable, well organized and searchable.

Performance

Marketing pages often become heavy with scripts for analytics, chat, A/B testing and ads. Audit third-party scripts regularly, defer non-essential ones and test Core Web Vitals on real devices. A slow pricing page costs signups.

Authentication and the signup flow

Plan the transition from site to app: sign-up forms, single sign-on options, email verification and onboarding. Track the funnel from visit to activation, and consider how to pass campaign information into the product for attribution. Keep forms accessible, and minimize fields.

Use consistent tracking across marketing site and app, with a consent approach that respects US and Canadian privacy rules. Define events for key steps: pricing page views, trial starts, activation milestones. Keep personal data out of analytics URLs and parameters.

Documentation

Good docs are part of the product. Use a documentation platform or static site generator with search, versioning and feedback links. Keep API references in sync with the product through automation. Link docs to the app and vice versa.

Security and reliability

Use HTTPS everywhere, strong security headers, DDoS protection and a web application firewall. Separate environments for staging and production. Keep marketing site plugins and dependencies updated. Publish a security page, and a status page for transparency.

Governance

Document who owns each property, how changes are released and how design stays consistent. A shared design system helps the marketing site and app feel like one product.

FAQ

Should the blog be on a subdomain or subfolder?

A subfolder usually consolidates search authority with your main site, though technical constraints sometimes require a subdomain.

Should my marketing site and app share a codebase?

Usually not. They have different needs and release cycles, and separation keeps deployments safer.

What CMS is best for a SaaS marketing site?

It depends on your team. WordPress and hosted builders suit fast, editor-led work, while a headless setup suits teams that want custom front ends and have developers.

How do I keep my app out of search results?

Use noindex directives or authentication for private pages and block crawling selectively, while allowing indexable public pages such as sign-up.

TURN INSIGHT INTO ACTION

Let’s talk about your next step.

Share your workflow, your current systems and what you want to improve. We’ll help shape a practical way forward.

Discuss your project ↗