In the first two parts of this series, we provided an overview of Liferay DXP 2026.Q3 and put the new CMS into context. Today, we’ll focus on a topic that spans several areas in the feature list: URLs, categories, search, sitemaps, and virtual hosts.
Taken together, these new features form a remarkably comprehensive SEO package. It addresses precisely the areas where Liferay projects have traditionally required custom configurations or in-house developments.
Shorter public URLs—without /web
Historically, Liferay has distinguished between public URLs with /web and private pages with /group:
example.com/web/produkte
example.com/group/intranetStarting with Liferay DXP 2026.Q2, you can /web be disabled instance-wide for public sites.
example.com/web/produktethen becomes:
example.com/produkteIn 2026.Q3, Liferay added a validation check for this in Server Administration. Among other things, it detects conflicts with other sites, pages, and reserved paths such as /group or /documents. This is important because /web was not only visual clutter but also previously separated different URL namespaces from one another.
For new installations, the shortened structure is an attractive option. However, caution is advised for existing sites: Disabling /web does not create automatic redirects. The old URLs remain accessible as well. Although Liferay converts canonicals, sitemaps, and social media metadata to the short version, Liferay explicitly recommends using this setting only for new sites at first.
Anyone converting an already indexed installation therefore needs a proven migration and redirection strategy. This includes, at a minimum:
- complete URL mapping,
- permanent 301 redirects,
- checking internal links,
- verification of canonical tags and hreflang attributes,
- updated sitemaps,
- Tests for URL conflicts,
- monitoring in Webmaster Tools.
From an SEO perspective, a shorter URL isn’t automatically a ranking factor. Its real value lies in improved readability, more consistent links, and a cleaner information architecture. The greater benefit comes in the long term through less complex logic and a clearly controllable canonical URL.
What happens to /group?
The path /group belongs to the Private Pages. These were an integral part of the Liferay page architecture for many years, but have been disabled by default for new installations since Liferay 7.4 U22.
Since Liferay DXP 2024.Q4 and Portal GA129, respectively, Private Pages have been officially deprecated and are scheduled for removal in the future. New projects should therefore no longer base their architecture on Private Pages and /group-URLs. The fact that /group is still treated as a reserved path is primarily relevant for existing installations and technical backward compatibility.
Private Pages play hardly any direct role in SEO anyway, since their content requires a login and site membership. Strategically, however, moving away from them makes sense: it allows for a clearer architectural separation between public, indexable content and protected applications.
Descriptive URLs for Categories and CMS Content
In Q3 2026, category pages will receive readable, localizable paths instead of purely numeric IDs. Site categories, for example, will follow this pattern:
/v/[vokabular]/[kategorie]/[unterkategorie]If a localized path is missing, Liferay uses the path for the default language; the platform falls back to a numeric ID only in exceptional cases. Existing ID-based addresses can redirect to the new URL. For production systems, you should verify that the redirect type is set to permanent (301).
Spaces in the new CMS can also be assigned their own friendly URLs. Instead of an environment-dependent address such as
/asset-library-38640you can, for example,
/produktdokumentationbe used. This not only improves readability; stable, custom-chosen paths can also be transferred more reliably between development, test, and production environments.
It’s important to note: Changes to structure or space paths can affect numerous content URLs simultaneously. Liferay does not automatically generate redirects for every change. URL design should therefore be incorporated early in the CMS architecture—not just added to the go-live checklist.
Sitemaps with Less Clutter
XML sitemaps can now be grouped by asset type. This allows pages, web content, categories, and object entries to appear in separate sitemap files. For large, content-rich sites, this improves technical management and prevents URLs from being lost due to the size limits of individual sitemap files.
In addition, Liferay can generate and cache sitemaps on a scheduled basis. For large-scale installations, this reduces the need to recalculate them every time they are retrieved.
URLs that match an active alias or pattern redirect are automatically removed from the sitemap. This ensures that search engines receive the actual target addresses directly, rather than wasting crawling resources on additional redirect hops.
In our view, this is one of the most effective changes in the package: A sitemap should not document the historical URL landscape, but rather the current, indexable inventory.
More Control Over Search and Faceted URLs
Faceted searches are a classic source of a large number of URLs that are technically different but nearly identical in content. Pagination, sorting, and combined filters can quickly generate a vast URL space.
Liferay therefore improves SEO control over search pages and cleans up navigation parameters that do not need to be part of indexable links. Administrators can specify more precisely which facet states should be relevant to search engines.
This reduces three typical risks:
- duplicate and near-duplicate content,
- unnecessary consumption of the crawl budget,
- and the dispersion of internal link signals across numerous URL variants.
The correct configuration depends on the specific project. A category such as “Product Range” can make for a useful landing page; a filter such as “Sort by: Price Descending” generally does not.
Multilingualism and Unique Domains
Localized virtual hosts will be correctly accounted for as alternate URLs in Q3 2026. For example, if a German-language site uses de.example.com, Liferay can also use that domain in the hreflang references. If no localized domain exists, the platform falls back on the default virtual host.
For international site landscapes, this eliminates a common source of errors: alternate links must point not only to the correct language but also to the domain actually intended.
In addition, Liferay is introducing Strict Virtual Host Mode. By default, a site can also be accessed via other domains belonging to the same instance. In strict mode, Liferay returns a 404 status for requests made via unassigned domains.
From an SEO perspective, this is valuable because it prevents the same content from inadvertently competing with itself under multiple hostnames. Before enabling this feature, however, all addresses used in production should be documented—including those for monitoring, load testing, integrations, and internally distributed links.
Visibility to AI Systems
On a related note, beta support for llms.txt . With this, Liferay can provide a Markdown file in the root directory at the instance or site level that describes important content and authoritative sources for AI tools.
llms.txt However, this is not a second robots.txt. It does not define binding access rights and does not replace technical access controls or legal terms of use. Rather, its benefit lies in offering AI systems curated guidance through a site’s most important content.
The format is still in its early stages. However, it provides companies with a central, controllable location where they can structure the sources relevant to AI applications.
Our SEO Assessment
The package won’t generate better rankings simply because URLs become shorter. Its value runs deeper:
Liferay reduces the number of potential URL variations, improves canonical signals, simplifies crawl management, and makes international domain structures more consistent. At the same time, logic that was previously often developed on a project-by-project basis is now integrated into the platform.
This not only reduces implementation effort but also minimizes the risk that custom rewrite rules, sitemap extensions, or search filters might inadvertently generate incorrect SEO signals during an upgrade.
For existing installations, however, the new options are not a sure thing. In particular, the removal of /web, changes to CMS paths, and the Strict Virtual Host Mode should be part of a controlled technical SEO rollout.
How Liferay positions itself against other CMSs
Many traditional CMSs view SEO primarily as an editorial task: page titles, descriptions, canonicals, and sitemaps. Complex URL spaces, multiple sites, protected applications, localized domains, and headless content, on the other hand, are often only consolidated through plugins, reverse proxy rules, or custom extensions.
With 2026.Q3, Liferay is taking a more consistent approach for a DXP. SEO is not treated as an isolated editorial function, but as part of the platform architecture—from URL resolution and virtual hosts to search, taxonomies, and headless delivery.
This is a particular advantage over leaner CMS systems, especially for large, multilingual, and integration-intensive platforms: the relevant mechanisms operate within a common permissions, site, and content model. Fewer additional components mean fewer interfaces that need to be tested and maintained separately during releases.
Taken individually, many changes may seem minor. Taken together, however, they form the most practical and useful part of Liferay DXP 2026.Q3.
Portalworks is a Liferay Service Partner for the DACH region and supports portal and upgrade projects from architecture through to operation.
