How to Use One Domain for Multiple Websites?

Sooner or later most growing projects outgrow a single application. The marketing site runs on one platform, the blog on another, the help center on a SaaS tool, and the web app is a separate codebase entirely. Buying a new domain for each of them dilutes your brand and confuses visitors, so the natural question is: can one domain serve several completely different websites? It can, and there are three well-established ways to do it: subdomains, subdirectories served through a reverse proxy, and multisite platforms that host many sites from one installation. This article walks through how each approach works, the DNS records and server configuration involved, and the practical trade-offs. If your main concern is which structure ranks better, read the dedicated comparison of subdomains vs. subdirectories for SEO alongside this guide.

The Three Ways to Share One Domain

Before diving into configuration, it helps to see the options side by side. Each one answers the same question differently: at what layer does the request get routed to the right website?

Approach	Example URL	Where routing happens	Typical use
Subdomain	shop.example.com	DNS	Separate platforms, SaaS tools, apps, staging
Subdirectory (reverse proxy)	example.com/blog	Web server, CDN, or edge	Blogs, docs, or apps that should feel integrated
Multisite platform	example.com/fr or fr.example.com	Inside one application	Many similar sites managed together

A single domain can mix all three. A common real-world layout is example.com for the main site, example.com/blog proxied to a headless CMS front end, app.example.com for the product, and help.example.com pointing to a hosted support desk.

Option 1: Subdomains

A subdomain is any name to the left of your registered domain, such as blog.example.com or app.example.com. Because each subdomain gets its own DNS records, each one can point to a completely different server, hosting provider, or SaaS product. Nothing on your main server needs to know the other sites exist. For the step-by-step mechanics in various DNS dashboards, see how to set up subdomains in DNS settings.

DNS Records for a Multi-Site Subdomain Layout

Here is what a zone might look like for a domain hosting five different sites on five different platforms:

; Main site on your own server
example.com.          3600  IN  A      203.0.113.10
www.example.com.      3600  IN  CNAME  example.com.

; Store hosted on Shopify
shop.example.com.     3600  IN  CNAME  shops.myshopify.com.

; Documentation deployed on Vercel
docs.example.com.     3600  IN  CNAME  cname.vercel-dns.com.

; Web application on a separate VPS
app.example.com.      3600  IN  A      198.51.100.25

; Status page on a third-party service (value supplied by the provider)
status.example.com.   3600  IN  CNAME  example.statuspage.example.net.

Each platform tells you which record type and target to use, and most then verify the record and issue a TLS certificate automatically. The general pattern is:

1. Add the subdomain as a custom domain in the target platform's dashboard.
2. Create the CNAME (or A/AAAA) record it asks for in your DNS host.
3. Wait for the platform to verify the record and provision HTTPS.

You can check that each subdomain resolves to the right place with dig:

for host in example.com shop.example.com docs.example.com app.example.com; do
  printf '%-22s ' "$host"
  dig +short "$host" | tr '\n' ' '
  echo
done

Why Subdomains Are the Easiest Option

• Independent hosting: each site can live anywhere, on any stack, with no shared server configuration.
• Isolation: an outage or a bad deploy on shop. does not take down www..
• SaaS-friendly: almost every hosted tool (help desks, stores, landing page builders, status pages) supports custom subdomains but not custom subdirectories.
• Simple TLS: each platform issues its own certificate. If you terminate TLS yourself for many subdomains, a wildcard certificate for *.example.com covers them all, and it requires DNS validation, as explained in how the DNS-01 challenge works.

Subdomain Pitfalls to Watch

• Cookie scope: a cookie set with Domain=example.com is sent to every subdomain. If a third-party platform runs on one of your subdomains, it may receive session cookies from your main app. Scope sensitive cookies to the exact host (omit the Domain attribute) and use the __Host- cookie prefix where possible.
• Dangling records: when you stop using a SaaS product but leave its CNAME in place, someone else may be able to claim that hostname on the same platform and serve content on your domain. Remove records as part of decommissioning. See what a dangling DNS record is for how subdomain takeovers happen.
• Separate analytics and search properties: subdomains are tracked as different hostnames, so you may need cross-domain configuration in analytics and separate verification in search tools.

Option 2: Subdirectories Through a Reverse Proxy

Sometimes you want a separately built website to appear at a path, such as example.com/blog, rather than on its own hostname. DNS cannot do this, because DNS only maps hostnames to addresses and never sees the URL path. Instead, a reverse proxy receives every request for example.com, inspects the path, and forwards it to the right backend. The visitor's browser only ever talks to example.com.

Browser ──► example.com (reverse proxy)
              ├── /blog/*   ──► WordPress or Ghost server
              ├── /docs/*   ──► static docs site
              └── /*        ──► main Next.js app

The proxy can be Nginx, Apache, HAProxy, a CDN rule, an edge function, or a framework feature such as Next.js rewrites.

Nginx Reverse Proxy Example

The following server block serves the main app on /, proxies /blog/ to a WordPress server on the private network, and proxies /docs/ to a static documentation site hosted elsewhere:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Shared headers for all proxied locations
    proxy_set_header X-Real-IP         $remote_addr;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    # Redirect /blog to /blog/ so relative links work
    location = /blog {
        return 301 /blog/;
    }

    # Blog: WordPress on an internal server, installed at /blog
    location /blog/ {
        proxy_set_header Host $host;
        proxy_pass http://10.0.0.21;          # no URI part: path is passed unchanged
    }

    # Docs: external static host that serves content from its root
    location /docs/ {
        proxy_set_header Host docs-site.example.net;
        proxy_ssl_server_name on;
        proxy_pass https://docs-site.example.net/;   # trailing slash strips /docs/
    }

    # Everything else: main application
    location / {
        proxy_set_header Host $host;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_pass http://127.0.0.1:3000;
    }
}

The most important detail is the trailing slash rule in proxy_pass:

• proxy_pass http://10.0.0.21; (no path) forwards the original URI unchanged, so /blog/hello/ arrives at the backend as /blog/hello/. Use this when the backend is configured to live under /blog.
• proxy_pass https://docs-site.example.net/; (with a path) replaces the matched location prefix, so /docs/intro/ arrives as /intro/. Use this when the backend thinks it lives at the root.

Note also the Host header. An internal server usually expects your public hostname, while an external host (a platform that serves many customers) needs its own hostname, plus proxy_ssl_server_name on so the TLS handshake sends the right SNI.

After editing, always test before reloading:

sudo nginx -t && sudo systemctl reload nginx
curl -sI https://example.com/blog/ | head -n 5

Make the Backend Aware of Its Path

The proxy is only half of the job. The application behind it must generate links, assets, and redirects under the public path, otherwise pages load without CSS or links jump to the backend's own hostname. For WordPress, set both the WordPress Address and Site Address to https://example.com/blog, and tell WordPress that the original request was HTTPS, since the proxy talks to it over plain HTTP:

// wp-config.php, above the "That's all, stop editing!" line
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}
define('WP_HOME', 'https://example.com/blog');
define('WP_SITEURL', 'https://example.com/blog');

Most other platforms have an equivalent "base URL" or "public path" setting.

Next.js and Vercel Rewrites Example

If your main site is a Next.js app, you may not need a separate proxy at all. Next.js rewrites forward matching paths to another origin while keeping the URL in the browser unchanged. This is the foundation of what Next.js calls multi-zones: several independently deployed apps served under one domain.

In the main app:

// next.config.js (main site, serves everything except /blog)
/** @type {import('next').NextConfig} */
const nextConfig = {
  async rewrites() {
    return [
      {
        source: "/blog",
        destination: "https://blog-app.vercel.app/blog",
      },
      {
        source: "/blog/:path+",
        destination: "https://blog-app.vercel.app/blog/:path+",
      },
      {
        source: "/blog-static/:path+",
        destination: "https://blog-app.vercel.app/blog-static/:path+",
      },
    ];
  },
};

module.exports = nextConfig;

In the blog app, set a basePath so its routes live under /blog, and an assetPrefix so its JavaScript and CSS bundles do not collide with the main app's /_next files:

// next.config.js (blog app, deployed to blog-app.vercel.app)
/** @type {import('next').NextConfig} */
const nextConfig = {
  basePath: "/blog",
  assetPrefix: "/blog-static",
};

module.exports = nextConfig;

Two practical notes from the Next.js multi-zones guidance: links that cross from one zone to another should be plain a elements rather than the Link component, because client-side navigation cannot cross applications, and each path must belong to exactly one zone.

If the main site is not built with Next.js but is deployed on Vercel, you can achieve the same result with a vercel.json file in the main project:

{
  "rewrites": [
    { "source": "/blog", "destination": "https://blog-app.vercel.app/blog" },
    {
      "source": "/blog/:path*",
      "destination": "https://blog-app.vercel.app/blog/:path*"
    }
  ]
}

Netlify (_redirects with a 200 status), Cloudflare Workers, and most CDNs offer comparable path-based proxy rules.

Reverse Proxy Pitfalls

• Absolute URLs in the backend: canonical tags, sitemaps, Open Graph URLs, and RSS feeds must use https://example.com/blog/..., not the backend's internal hostname. Check the HTML source after setup.
• Duplicate content: if the backend is still publicly reachable on its own hostname (for example blog-app.vercel.app), make sure it sends canonical tags pointing to the public URL, or block direct access.
• Caching and headers: the proxy may strip or override cache headers, cookies, or CORS headers. Test logins, forms, and previews, not just page loads.
• Latency: every proxied request makes an extra hop. Keep the proxy and backend geographically close or cache aggressively at the edge.

Option 3: Multisite Platforms

The third approach does not combine different applications at all. Instead, a single installation manages many sites, each with its own content, settings, and sometimes its own design.

• WordPress Multisite turns one WordPress installation into a network. Sites can live in subdirectories (example.com/fr/) or subdomains (fr.example.com), chosen when the network is created. Subdomain networks usually need a wildcard DNS record so new sites resolve automatically; see what a wildcard DNS record is.
• Headless CMS plus one front end can render several "sites" from one codebase by switching content based on the path or hostname, often using middleware.
• Hosting control panels such as cPanel let one hosting account serve several sites, but those are usually separate domains rather than one shared domain.

A minimal wildcard record for a subdomain-based multisite network looks like this:

example.com.     3600  IN  A  203.0.113.10
*.example.com.   3600  IN  A  203.0.113.10

Multisite is a good fit when the sites are similar (regional versions, franchise locations, department sites) and you want shared users, plugins, and updates. It is a poor fit when the sites need different technology stacks or have different owners, because one plugin conflict or failed update can affect every site in the network.

How to Choose the Right Approach

Use these questions to narrow it down:

1. Is the second site a hosted SaaS product? Use a subdomain. Very few SaaS tools can be served correctly from a subdirectory.
2. Should the second site feel like part of the main site, sharing navigation and authority? A reverse-proxied subdirectory is usually the better choice, provided you control both applications.
3. Are the sites near-identical in structure and managed by the same team? A multisite platform reduces maintenance.
4. Does the site need strict security isolation (for example, user-generated content or a separate app with its own login)? Use a subdomain, and scope cookies carefully. Many companies host user content on an entirely separate domain for this reason.
5. How much operational complexity can you take on? Subdomains need only DNS changes. Reverse proxies need someone comfortable debugging headers, caching, and redirects.

Criterion	Subdomain	Reverse-proxied subdirectory	Multisite
Setup effort	Low	Medium to high	Medium
Works with SaaS tools	Almost always	Rarely	Not applicable
Different tech stacks	Yes	Yes	No
Failure isolation	Strong	Partial (shared proxy)	Weak
Feels like one website	Less so	Yes	Yes
Cookie and session sharing	Opt-in via Domain	Automatic (same host)	Platform-managed

Other Ways "One Domain" Gets Shared

A few related setups are worth knowing so you do not confuse them with the options above:

• Domain forwarding sends visitors from one domain to another with an HTTP redirect. It changes the URL in the browser, so it does not host multiple sites.
• Path-based redirects (for example, example.com/store redirecting to shop.example.com) can give you a memorable path while the store actually lives on a subdomain. This is a simple compromise when proxying is impossible.
• Separate domains per site, linked from one hub is still the right answer for unrelated businesses. Sharing a domain implies a shared brand and shared reputation.

Multiple Websites on One Domain FAQ

Conclusion

One domain can comfortably host many websites. Subdomains are the simplest and most flexible option, because DNS routes each hostname to whatever platform runs it, and nearly every hosted service supports them. Reverse-proxied subdirectories take more engineering, but they let separately built sites appear as a single, unified website at paths like /blog or /docs. Multisite platforms trade flexibility for easier management when the sites are similar.

Whatever you choose, the details make or break the setup: correct proxy_pass paths and Host headers, a backend that knows its public URL, carefully scoped cookies, canonical tags that point to the public address, and DNS records that are removed when a service is retired. Get those right and visitors will never know that one domain is quietly stitched together from several systems.

Here are some useful references for going deeper on serving multiple sites from one domain:

1. Nginx: Module ngx_http_proxy_module — official documentation for proxy_pass, proxy headers, and upstream TLS options.
2. Next.js: Multi-zones guide — how to serve several Next.js applications under a single domain.
3. Next.js: rewrites configuration — reference for path matching and external rewrite destinations.
4. MDN Web Docs: Set-Cookie header — how the Domain attribute and cookie prefixes control which hosts receive cookies.
5. RFC 1035: Domain Names, Implementation and Specification — the DNS specification, including label and name length limits.