Multi-Experience Operations
Using path-based domains
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).
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.
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.
To add a path-based domain to a site instance:
Enter the domain in the domain.tld/path format, such as [example.com/uk](https://example.com/uk).
Click Save.
The domain is associated with the site instance. Routing becomes active after you properly configure the Domain Name System (DNS).
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.
: Adding path-based domains does not interfere with traffic to the root domain. Requests to without a path continue to route to the primary site.
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.
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.
Multi-Experience Operations[domainA.com/path](https://domainA.com/path)domainB.com, requests to [domainB.com/path](https://domainB.com/path)| 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. |
[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.
To add a path-based domain to a site instance:
Enter the domain in the domain.tld/path format, such as [example.com/uk](https://example.com/uk).
Click Save.
The domain is associated with the site instance. Routing becomes active after you properly configure the Domain Name System (DNS).
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.
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.
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.
[domainA.com/path](https://domainA.com/path)domainB.com, requests to [domainB.com/path](https://domainB.com/path)[domainB.com/](https://domainB.com/).htaccess rules to prevent this behavior| 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. |
example.comEnsure 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.
[domainB.com/](https://domainB.com/).htaccessIf this content did not answer your questions, try searching or contacting our support team for further assistance.
If this content did not answer your questions, try searching or contacting our support team for further assistance.