--- title: "Using path-based domains" date: "2026-07-21T12:30:00+00:00" summary: "Map multiple sites under one apex domain using path-based domains—boost SEO, unify branding, and simplify migrations without changing URLs." image: type: "page" url: "/acquia-cloud-platform/add-ons/multi-experience-operations/using-path-based-domains" id: "aa69935e-4e31-4638-b628-777e65bf9a48" --- Path-based domains enable you to map a specific URL path under a single apex domain to an independent site instance. Instead of using separate subdomains, such as `uk.example.com` or `france.example.com`, you can consolidate sites under one root domain by using path segments, such as `[example.com/uk](https://example.com/uk)` or `[example.com/``france``](https://example.com/``france``)`. ### Benefits * ****SEO consolidation****: Concentrate domain authority into a single root domain rather than distributing authority across multiple subdomains. * ****Brand consistency****: Maintain a unified URL structure that reinforces brand identity across regional or departmental sites. * ****Simplified migration****: Transition from legacy Acquia Cloud Site Factory (ACSF) stacks that use path-based routing to Multi-Experience Operations (MEO) without changing external URL structures. How path-based domains work --------------------------- When you add a path-based domain to a site instance, the platform routes incoming requests to the correct site based on the URL path: * `[example.com/uk](https://example.com/uk)` routes to the UK site instance. * `[example.com/france](https://example.com/france)` routes to the France site instance. * `example.com` continues to route to the primary site instance. The platform handles routing at the infrastructure level. You do not need to make code changes or add application-level configuration to enable path-based routing. Add a path-based domain ----------------------- To add a path-based domain to a site instance: 1. [Sign in to the Cloud Platform user interface](https://cloud.acquia.com/). 2. Go to **Codebases** and select a codebase. 3. Go to **Sites** and select a site. 4. Go to **Domain Management** and click **Add Domain**. 5. Enter the domain in the `domain.tld/path` format, such as `[example.com/uk](https://example.com/uk)`. 6. Click ****Save****. The domain is associated with the site instance. Routing becomes active after you properly configure the Domain Name System (DNS). Requirements and considerations ------------------------------- * ****Domain format****: Enter path-based domains in the `domain.tld/path` format, such as `[example.com/blog](https://example.com/blog)` or `[brand.com/uk](https://brand.com/uk)`. The platform supports only a single path segment. * ****SSL certificates****: The platform does not supply Secure Sockets Layer (SSL) certificates for path-based domains. You do not need a separate certificate for the path segment, but you must do these steps: * Make sure that the current SSL certificate for the apex domain applies to all traffic. This traffic must include requests to path-based URLs. * Make sure that a valid SSL certificate is installed in each environment that shares the domain. * ****DNS configuration****: Configure DNS to point the apex domain to Acquia. The platform handles path-based routing after the request reaches the edge. * ****Multi-environment support****: Path-based routing configurations work independently across Dev, Stage, and Production environments. You can configure different path mappings for each environment. * ****Unmapped paths****: Requests to paths that are not explicitly mapped to a site instance, such as `[example.com/undefined-path](https://example.com/undefined-path)`, return a 404 response from the primary site. If a path is assigned to an environment in example.com, the system routes to that environment instead. * ****Root domain integrity****: Adding path-based domains does not interfere with traffic to the root domain. Requests to `example.com` without a path continue to route to the primary site. * Ensure that the domain path does not match an existing Drupal content path. If the domain path, such as `/page1`, matches an existing node path on the website, path resolution conflicts occur. Important **Do not use a domain path that is the same as a current Drupal content path.** Errors occur if the symlink name for the path-based domain is the same as a Drupal node path. For example, a conflict occurs if the domain path is `/page1` and a Drupal page is available at `/page1`. If you do this, you will see these problems: * Immediately after you create the domain, the path-based domain shows the Drupal content at that path. It does not show the website home page. * When the domain setup is complete, URLs (for example, `/page1/page1/`) open the website home page. This result occurs because of recursive symlink resolution. * You cannot get access to the initial Drupal content at that path from the path-based domain. This recursive resolution also occurs for deeper paths, for example, `/page1/page1/page1/`. To prevent these problems, make sure that the domain path is not the same as a current Drupal content path on the website. Do this check before you create the symlink. ### Symlink behavior across multiple root domains  If a site instance shares multiple root domains and is on same environment, such as `[domain2.com/](https://domain2.com/)` and `[domain3.com/sg](https://domain3.com/sg)`, requests to a path configured under one domain through another domain (such as \[domain2.com/sg/\]`(https://domain2.com/sg/))` return an HTTP 200 status code instead of an expected 404 error.  Path-based domain routing creates a filesystem symlink, such as sg, that points to docroot. Because all root domains on the site instance share the same codebase and docroot, requests to \[domain2.com/sg/\](https://domain2.com/sg/) resolve through the sg symlink directly to `[domain2.com/](https://domain2.com/)`. Cloud Platform cannot address this behavior at the platform level. To restrict paths configured under one domain from being accessed under another root domain on the same site instance, configure custom .htaccess rewrite rules to explicitly block or reject those requests under unauthorized domains. Limitations ----------- * ****No wildcard paths****: The platform does not support wildcard path mappings, such as `[example.com/](https://example.com/)*`. You must explicitly define each path and map the path to a specific site instance. * ****No platform-level redirects****: Path-based domains handle routing only. To use 301 or 302 redirects between paths, configure the redirects in the Drupal application or use existing redirect tools. * ****Single path segment****: The platform supports only one level of path. For example, `[example.com/uk](https://example.com/uk)` is valid, but nested paths such as `[example.com/region/uk](https://example.com/region/uk)` are not supported. * **No cross-domain path isolation for shared codebases**: Cloud Platform does not isolate filesystem symlinks across multiple root domains mapped to the same codebase. If `[domainA.com/path](https://domainA.com/path)`[domainA.com/path](https://www.google.com/search?q=https%3A%2F%2FdomainA.com%2Fpath) is configured on a site instance that also serves `domainB.com`, requests to `[domainB.com/path](https://domainB.com/path)`[domainB.com/path](https://www.google.com/search?q=https%3A%2F%2FdomainB.com%2Fpath) resolve to `[domainB.com/](https://domainB.com/)`[domainB.com/](https://www.google.com/search?q=https%3A%2F%2FdomainB.com%2F) through the symlink. You must explicitly restrict access with `.htaccess` rules to prevent this behavior. Use cases --------- **Scenario** **Example** ****Global market localization**** Map `[brand.com/uk](https://brand.com/uk)` and `[brand.com/fr](https://brand.com/fr)` to separate country-specific site instances. ****Consolidated brand architecture**** Migrate `blog.company.com` to `[company.com/blog](https://company.com/blog)` to consolidate SEO authority. ****Departmental independence**** Assign `university.edu/engineering` to an autonomous site managed by a separate team. ****Legacy platform migration**** Transition ACSF stacks using path-based routing to MEO without changing external URLs.