In the first two parts of this series, we gave an overview of Liferay DXP 2026.Q3 and put the new CMS into context. Today we turn to a topic that is spread across several areas in the feature list: URLs, categories, search, sitemaps and virtual hosts.
Taken together, these innovations form a remarkably coherent SEO package. It addresses exactly the areas where Liferay projects have so far regularly required individual configurations or custom development.
Shorter public URLs – without /web
Historically, Liferay distinguishes between public URLs with /web and private pages with /group:
example.com/web/produkte
example.com/group/intranetSince Liferay DXP 2026.Q2, the /web for public sites can be disabled instance-wide. Then
example.com/web/produktebecomes:
example.com/produkteIn 2026.Q3, Liferay adds a validation run for this in Server Administration. Among other things, it detects collisions with other sites, pages and reserved paths such as /group or /documents. This is important, because /web was not just visual clutter; until now it also separated different URL namespaces from one another.
For new installations, the shortened structure is an attractive option. For existing sites, however, caution is advised: disabling /web does not create automatic redirects. The old URLs also remain accessible. Although Liferay switches canonicals, sitemaps and social media metadata to the short variant, Liferay explicitly recommends the setting initially for new sites.
If you are switching an installation that has already been indexed, you therefore need a validated migration and redirect concept. At a minimum, this includes:
- complete URL mapping,
- permanent 301 redirects,
- review of internal links,
- verification of canonicals and hreflang annotations,
- updated sitemaps,
- tests for URL collisions,
- monitoring in the webmaster tools.
From an SEO perspective, the shorter URL is not automatically a ranking factor. Its actual value lies in better readability, more consistent links and a cleaner information architecture. The greater effect comes in the long term from less special-case logic and a clearly controllable canonical URL.
What happens to /group?
The /group path belongs to Private Pages. For many years, these were an integral part of the Liferay page architecture, but they 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 later removal. 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 hardly play a direct role in SEO anyway, since their content requires a login and site membership. Strategically, moving away from them still makes sense: it allows public, indexable content and protected applications to be separated more clearly at the architectural level.
Human-readable URLs for categories and CMS content
In 2026.Q3, category pages receive readable, localizable paths instead of purely numeric IDs. Site categories, for example, follow this pattern:
/v/[vokabular]/[kategorie]/[unterkategorie]If a localized path is missing, Liferay uses the path of the default language; only in exceptional cases does the platform fall back to a numeric ID. Existing ID-based addresses can redirect to the new URL. For production systems, you should check whether the redirect type is set to permanent, i.e. 301.
Spaces in the new CMS can also be given their own friendly URLs. Instead of an environment-dependent address such as
/asset-library-38640you can use, for example,
/produktdokumentationThis not only improves readability. Stable, self-chosen paths can also be transported more reliably between development, test and production environments.
It remains important to note: changes to structure or space paths can change numerous content URLs at once. Liferay does not automatically create redirects for every change. URL design therefore belongs early in the CMS architecture and not just on the go-live checklist.
Sitemaps with less clutter
XML sitemaps can now be grouped by asset type. Pages, Web Content, categories and Object Entries can thus appear in separate sitemap files. For large, content-rich sites, this improves technical handling and prevents URLs from being lost due to the size limit of individual sitemap files.
In addition, Liferay can generate and cache sitemaps on a schedule. For extensive installations, this reduces repeated computation on every request.
URLs matched by an active alias or pattern redirect are automatically removed from the sitemap. Search engines thus receive the actually intended target addresses directly, instead of spending 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 the current, indexable inventory.
More control over search and facet URLs
Faceted searches are a classic source of a very large number of URLs that are technically different but nearly identical in content. Pagination, sorting and combined filters can quickly create a large URL space.
Liferay therefore improves the SEO control of 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 for search engines.
This reduces three typical risks:
- duplicate and near-duplicate content,
- unnecessary consumption of crawl budget,
- dilution of internal link signals across numerous URL variants.
The right configuration remains project-specific. A category such as “product area” can make a meaningful landing page; a filter such as “sort: price descending” usually cannot.
Multilingualism and unique domains
In 2026.Q3, localized virtual hosts are correctly taken into account for alternate URLs. If a German-language site uses de.example.com, for example, Liferay can also use this domain in the hreflang references. If no localized domain exists, the platform falls back to the default virtual host.
For international site landscapes, this eliminates a common source of errors: alternate links must point not only to the right language but also to the domain actually intended.
In addition, Liferay introduces Strict Virtual Host Mode. By default, a site can also be reached via other domains of the same instance. In strict mode, Liferay returns a 404 status for requests via unassigned domains.
From an SEO standpoint, this is valuable because the same content does not inadvertently compete with itself under multiple host names. Before activating it, however, all addresses used in production should be recorded – including monitoring, load tests, integrations and internally distributed links.
Visibility to AI systems
Fittingly, beta support for llms.txt is also being added. This allows Liferay to provide a Markdown file in the root directory at instance or site level that describes important content and authoritative sources for AI tools.
llms.txt is not a second robots.txt, however. It does not define binding access rights and replaces neither technical access controls nor legal terms of use. Rather, its benefit lies in offering AI systems curated guidance through the most important content of a site.
The format is still at an early stage. However, it gives companies a central, controllable place where they can structure the sources relevant to AI applications.
Our SEO assessment
The package will not produce better rankings simply because URLs become shorter. Its value lies deeper:
Liferay reduces the number of potential URL variants, improves canonical signals, makes crawl control easier and makes international domain structures more consistent. At the same time, logic that was previously often developed on a project-specific basis moves into the platform.
This not only lowers implementation effort. It also reduces the risk that individual rewrite rules, sitemap extensions or search filters unnoticeably produce incorrect SEO signals during an upgrade.
For existing installations, however, the following applies: the new options do not take care of themselves. In particular, removing /web, changes to CMS paths and Strict Virtual Host Mode belong in a controlled technical SEO rollout.
How Liferay positions itself against other CMSs
Many classic CMSs regard 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 brought together through plugins, reverse proxy rules or individual extensions.
With 2026.Q3, Liferay takes a path that is more consistent 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 through search and taxonomies to headless delivery.
Especially for large, multilingual and integration-intensive platforms, this is an advantage over leaner CMS systems: the relevant mechanisms work within a shared permission, site and content model. Fewer additional components mean fewer interfaces that have to be tested and maintained separately with each release.
Viewed individually, many of the changes seem small. Taken together, however, they form the most practically 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 operations.
