Liferay DXP 2026.Q3, Teil 3: Das SEO-Paket - Portalworks

Liferay DXP 2026.Q1 LTS ist da – Jakarta EE, neues CMS & MCP Server Mehr erfahren → Liferay 2026.Q1 LTS →

Liferay DXP 2026.Q3, Teil 3: Das SEO-Paket

Kürzere URLs, kontrollierbare Facetten, präzisere Sitemaps und eindeutige Domains: Die SEO-Neuerungen in Liferay DXP 2026.Q3 ergeben zusammen mehr als die Summe ihrer Teile. Besonders bei bestehenden Installationen entscheidet allerdings die Migrationsstrategie darüber, ob aus sauberen URLs auch saubere SEO-Signale werden.

Artikelbild

In den ersten beiden Teilen dieser Reihe haben wir den Überblick über Liferay DXP 2026.Q3 gegeben und das neue CMS eingeordnet. Heute geht es um ein Thema, das in der Feature-Liste auf mehrere Bereiche verteilt ist: URLs, Kategorien, Suche, Sitemaps und Virtual Hosts.

Zusammengenommen ergeben diese Neuerungen ein bemerkenswert geschlossenes SEO-Paket. Es setzt genau dort an, wo Liferay-Projekte bisher regelmäßig individuelle Konfigurationen oder Eigenentwicklungen benötigten.

Kürzere öffentliche URLs – ohne /web

Liferay unterscheidet historisch zwischen öffentlichen URLs mit /web und privaten Seiten mit /group:

example.com/web/produkte
example.com/group/intranet

Seit Liferay DXP 2026.Q2 lässt sich das /web für öffentliche Sites instanzweit deaktivieren. Aus

example.com/web/produkte

wird dann:

example.com/produkte

In 2026.Q3 ergänzt Liferay dafür einen Prüflauf in der Server Administration. Er erkennt unter anderem Kollisionen mit anderen Sites, Seiten und reservierten Pfaden wie /group oder /documents. Das ist wichtig, denn /web war nicht nur optischer Ballast, sondern trennte bislang unterschiedliche URL-Namensräume voneinander.

Für neue Installationen ist die verkürzte Struktur eine attraktive Option. Bei bestehenden Sites ist jedoch Vorsicht geboten: Das Abschalten von /web erzeugt keine automatischen Weiterleitungen. Die alten URLs bleiben zusätzlich erreichbar. Liferay setzt Canonicals, Sitemaps und Social-Media-Metadaten zwar auf die kurze Variante um, dennoch empfiehlt Liferay die Einstellung ausdrücklich zunächst für neue Sites.

Wer eine bereits indexierte Installation umstellt, benötigt deshalb ein geprüftes Migrations- und Weiterleitungskonzept. Dazu gehören mindestens:

  • vollständiges URL-Mapping,
  • permanente 301-Weiterleitungen,
  • Kontrolle interner Links,
  • Prüfung von Canonicals und hreflang-Angaben,
  • aktualisierte Sitemaps,
  • Tests auf URL-Kollisionen,
  • Monitoring in den Webmaster-Werkzeugen.

Aus SEO-Sicht ist die kürzere URL nicht automatisch ein Rankingfaktor. Ihr eigentlicher Wert liegt in besserer Lesbarkeit, konsistenteren Links und einer saubereren Informationsarchitektur. Der größere Effekt entsteht langfristig durch weniger Sonderlogik und eine eindeutig steuerbare kanonische URL.

Was passiert mit /group?

Der Pfad /group gehört zu den Private Pages. Diese waren über viele Jahre ein fester Bestandteil der Liferay-Seitenarchitektur, sind aber für neue Installationen bereits seit Liferay 7.4 U22 standardmäßig deaktiviert.

Seit Liferay DXP 2024.Q4 beziehungsweise Portal GA129 sind Private Pages offiziell deprecated und für eine spätere Entfernung vorgesehen. Neue Projekte sollten ihre Architektur deshalb nicht mehr auf Private Pages und /group-URLs aufbauen. Dass /group weiterhin als reservierter Pfad behandelt wird, ist in erster Linie für Bestandsinstallationen und die technische Abwärtskompatibilität relevant.

Für SEO spielen Private Pages ohnehin kaum eine direkte Rolle, da ihre Inhalte eine Anmeldung und Site-Mitgliedschaft voraussetzen. Strategisch ist die Abkehr trotzdem sinnvoll: Öffentliche, indexierbare Inhalte und geschützte Anwendungen lassen sich dadurch architektonisch klarer voneinander trennen.

Sprechende URLs für Kategorien und CMS-Inhalte

Kategorieseiten erhalten in 2026.Q3 lesbare, lokalisierbare Pfade anstelle rein numerischer IDs. Site-Kategorien folgen dabei beispielsweise diesem Muster:

/v/[vokabular]/[kategorie]/[unterkategorie]

Fehlt ein lokalisierter Pfad, verwendet Liferay den Pfad der Standardsprache; nur in Ausnahmefällen fällt die Plattform auf eine numerische ID zurück. Bestehende ID-basierte Adressen können auf die neue URL weiterleiten. Für produktive Systeme sollte dabei geprüft werden, ob der Redirect-Typ auf permanent, also 301, eingestellt ist.

Auch Spaces im neuen CMS lassen sich mit eigenen Friendly URLs versehen. Statt einer umgebungsabhängigen Adresse wie

/asset-library-38640

kann beispielsweise

/produktdokumentation

verwendet werden. Das verbessert nicht nur die Lesbarkeit. Stabile, selbst gewählte Pfade lassen sich auch zuverlässiger zwischen Entwicklungs-, Test- und Produktivumgebungen transportieren.

Wichtig bleibt: Änderungen an Struktur- oder Space-Pfaden können zahlreiche Content-URLs gleichzeitig verändern. Nicht für jede Änderung erzeugt Liferay automatisch Redirects. Die URL-Konzeption gehört daher früh in die CMS-Architektur und nicht erst in die Go-live-Checkliste.

Sitemaps mit weniger Ballast

XML-Sitemaps lassen sich nun nach Asset-Typ gruppieren. Seiten, Web Content, Kategorien und Object Entries können dadurch in getrennten Sitemap-Dateien erscheinen. Bei großen, inhaltsreichen Sites verbessert das die technische Handhabung und verhindert, dass URLs aufgrund der Größenbegrenzung einzelner Sitemap-Dateien verloren gehen.

Zusätzlich kann Liferay die Sitemaps geplant erzeugen und zwischenspeichern. Das reduziert bei umfangreichen Installationen die wiederholte Berechnung bei jedem Abruf.

URLs, auf die eine aktive Alias- oder Pattern-Weiterleitung passt, werden automatisch aus der Sitemap entfernt. Suchmaschinen erhalten damit direkt die tatsächlich gewünschten Zieladressen, statt Crawling-Ressourcen für zusätzliche Redirect-Hops aufzuwenden.

Das ist aus unserer Sicht eine der wirkungsvollsten Änderungen des Pakets: Eine Sitemap sollte nicht die historische URL-Landschaft dokumentieren, sondern den aktuellen, indexierbaren Bestand.

Mehr Kontrolle über Such- und Facetten-URLs

Facettierte Suchen sind eine klassische Quelle für sehr viele technisch unterschiedliche, inhaltlich aber nahezu identische URLs. Pagination, Sortierung und kombinierte Filter können schnell einen großen URL-Raum erzeugen.

Liferay verbessert deshalb die SEO-Steuerung von Suchseiten und bereinigt Navigationsparameter, die nicht Teil indexierbarer Links sein müssen. Administratoren können genauer festlegen, welche Facettenzustände für Suchmaschinen relevant sein sollen.

Das reduziert drei typische Risiken:

  • Duplicate und Near-Duplicate Content,
  • unnötigen Verbrauch des Crawl-Budgets,
  • Verteilung interner Linksignale auf zahlreiche URL-Varianten.

Die richtige Konfiguration bleibt projektspezifisch. Eine Kategorie wie „Produktbereich“ kann eine sinnvolle Landingpage ergeben; ein Filter wie „Sortierung: Preis absteigend“ in der Regel nicht.

Mehrsprachigkeit und eindeutige Domains

Lokalisierte Virtual Hosts werden in 2026.Q3 korrekt für Alternate URLs berücksichtigt. Nutzt eine deutschsprachige Site beispielsweise de.example.com, kann Liferay diese Domain auch in den hreflang-Verweisen verwenden. Existiert keine lokalisierte Domain, greift die Plattform auf den Standard-Virtual-Host zurück.

Für internationale Site-Landschaften beseitigt das eine häufige Fehlerquelle: Alternate Links müssen nicht nur auf die richtige Sprache, sondern auch auf die tatsächlich vorgesehene Domain zeigen.

Ergänzend führt Liferay den Strict Virtual Host Mode ein. Standardmäßig kann eine Site auch über andere Domains derselben Instanz erreichbar sein. Im strikten Modus liefert Liferay für Zugriffe über nicht zugeordnete Domains einen 404-Status.

SEO-seitig ist das wertvoll, weil dieselben Inhalte nicht versehentlich unter mehreren Hostnamen miteinander konkurrieren. Vor der Aktivierung sollten jedoch alle produktiv verwendeten Adressen erfasst werden – einschließlich Monitoring, Lasttests, Integrationen und intern verteilter Links.

Sichtbarkeit gegenüber KI-Systemen

Thematisch passend kommt die Beta-Unterstützung für llms.txt hinzu. Liferay kann damit auf Instanz- oder Site-Ebene eine Markdown-Datei im Wurzelverzeichnis bereitstellen, die wichtige Inhalte und autoritative Quellen für KI-Werkzeuge beschreibt.

llms.txt ist allerdings kein zweites robots.txt. Es definiert keine verbindlichen Zugriffsrechte und ersetzt weder technische Zugriffskontrollen noch rechtliche Nutzungsbedingungen. Der Nutzen liegt vielmehr darin, KI-Systemen eine kuratierte Orientierung durch die wichtigsten Inhalte einer Site anzubieten.

Das Format befindet sich noch in einer frühen Phase. Unternehmen gewinnen damit aber einen zentralen, kontrollierbaren Ort, an dem sie die für KI-Anwendungen relevanten Quellen strukturieren können.

Unsere SEO-Einschätzung

Das Paket wird nicht allein deshalb bessere Rankings erzeugen, weil URLs kürzer werden. Sein Wert liegt tiefer:

Liferay reduziert die Zahl potenzieller URL-Varianten, verbessert kanonische Signale, erleichtert die Crawl-Steuerung und macht internationale Domain-Strukturen konsistenter. Gleichzeitig wandert Logik, die bisher häufig projektspezifisch entwickelt wurde, in die Plattform.

Das senkt nicht nur Implementierungsaufwand. Es reduziert auch das Risiko, dass individuelle Rewrite-Regeln, Sitemap-Erweiterungen oder Suchfilter bei einem Upgrade unbemerkt falsche SEO-Signale erzeugen.

Bei Bestandsinstallationen gilt allerdings: Die neuen Optionen sind kein Selbstläufer. Insbesondere die Entfernung von /web, Änderungen an CMS-Pfaden und der Strict Virtual Host Mode gehören in einen kontrollierten technischen SEO-Rollout.

Wie sich Liferay damit gegenüber anderen CMS positioniert

Viele klassische CMS betrachten SEO vor allem als redaktionelle Aufgabe: Seitentitel, Beschreibungen, Canonicals und Sitemaps. Komplexe URL-Räume, mehrere Sites, geschützte Anwendungen, lokalisierte Domains und Headless-Inhalte werden dagegen häufig erst durch Plugins, Reverse-Proxy-Regeln oder individuelle Erweiterungen zusammengeführt.

Liferay geht mit 2026.Q3 einen für eine DXP konsequenteren Weg. SEO wird nicht als isolierte Redaktionsfunktion behandelt, sondern als Teil der Plattformarchitektur – von URL-Auflösung und Virtual Hosts über Suche und Taxonomien bis zur Headless-Auslieferung.

Gerade bei großen, mehrsprachigen und integrationsintensiven Plattformen ist das ein Vorteil gegenüber schlankeren CMS-Systemen: Die relevanten Mechanismen arbeiten innerhalb eines gemeinsamen Berechtigungs-, Site- und Content-Modells. Weniger zusätzliche Komponenten bedeuten weniger Schnittstellen, die bei Releases separat geprüft und gepflegt werden müssen.

Einzeln betrachtet wirken viele Änderungen klein. Zusammengenommen bilden sie jedoch den praktisch nutzbarsten Teil von Liferay DXP 2026.Q3.

Portalworks ist Liferay Service Partner für die DACH-Region und begleitet Portal- und Upgrade-Projekte von der Architektur bis in den Betrieb.

Fragen dazu?

Marc Hermann antwortet persönlich – kein Vertriebsteam, kein Formularautomatismus.

Liferay DXP 2026.Q3, Teil 3: Das SEO-Paket

Kürzere URLs, kontrollierbare Facetten, präzisere Sitemaps und eindeutige Domains: Die SEO-Neuerungen in Liferay DXP 2026.Q3 ergeben zusammen mehr als die Summe ihrer Teile. Besonders bei bestehenden Installationen entscheidet allerdings die Migrationsstrategie darüber, ob aus sauberen URLs auch saubere SEO-Signale werden.

Artikelbild

In den ersten beiden Teilen dieser Reihe haben wir den Überblick über Liferay DXP 2026.Q3 gegeben und das neue CMS eingeordnet. Heute geht es um ein Thema, das in der Feature-Liste auf mehrere Bereiche verteilt ist: URLs, Kategorien, Suche, Sitemaps und Virtual Hosts.

Zusammengenommen ergeben diese Neuerungen ein bemerkenswert geschlossenes SEO-Paket. Es setzt genau dort an, wo Liferay-Projekte bisher regelmäßig individuelle Konfigurationen oder Eigenentwicklungen benötigten.

Kürzere öffentliche URLs – ohne /web

Liferay unterscheidet historisch zwischen öffentlichen URLs mit /web und privaten Seiten mit /group:

example.com/web/produkte
example.com/group/intranet

Seit Liferay DXP 2026.Q2 lässt sich das /web für öffentliche Sites instanzweit deaktivieren. Aus

example.com/web/produkte

wird dann:

example.com/produkte

In 2026.Q3 ergänzt Liferay dafür einen Prüflauf in der Server Administration. Er erkennt unter anderem Kollisionen mit anderen Sites, Seiten und reservierten Pfaden wie /group oder /documents. Das ist wichtig, denn /web war nicht nur optischer Ballast, sondern trennte bislang unterschiedliche URL-Namensräume voneinander.

Für neue Installationen ist die verkürzte Struktur eine attraktive Option. Bei bestehenden Sites ist jedoch Vorsicht geboten: Das Abschalten von /web erzeugt keine automatischen Weiterleitungen. Die alten URLs bleiben zusätzlich erreichbar. Liferay setzt Canonicals, Sitemaps und Social-Media-Metadaten zwar auf die kurze Variante um, dennoch empfiehlt Liferay die Einstellung ausdrücklich zunächst für neue Sites.

Wer eine bereits indexierte Installation umstellt, benötigt deshalb ein geprüftes Migrations- und Weiterleitungskonzept. Dazu gehören mindestens:

  • vollständiges URL-Mapping,
  • permanente 301-Weiterleitungen,
  • Kontrolle interner Links,
  • Prüfung von Canonicals und hreflang-Angaben,
  • aktualisierte Sitemaps,
  • Tests auf URL-Kollisionen,
  • Monitoring in den Webmaster-Werkzeugen.

Aus SEO-Sicht ist die kürzere URL nicht automatisch ein Rankingfaktor. Ihr eigentlicher Wert liegt in besserer Lesbarkeit, konsistenteren Links und einer saubereren Informationsarchitektur. Der größere Effekt entsteht langfristig durch weniger Sonderlogik und eine eindeutig steuerbare kanonische URL.

Was passiert mit /group?

Der Pfad /group gehört zu den Private Pages. Diese waren über viele Jahre ein fester Bestandteil der Liferay-Seitenarchitektur, sind aber für neue Installationen bereits seit Liferay 7.4 U22 standardmäßig deaktiviert.

Seit Liferay DXP 2024.Q4 beziehungsweise Portal GA129 sind Private Pages offiziell deprecated und für eine spätere Entfernung vorgesehen. Neue Projekte sollten ihre Architektur deshalb nicht mehr auf Private Pages und /group-URLs aufbauen. Dass /group weiterhin als reservierter Pfad behandelt wird, ist in erster Linie für Bestandsinstallationen und die technische Abwärtskompatibilität relevant.

Für SEO spielen Private Pages ohnehin kaum eine direkte Rolle, da ihre Inhalte eine Anmeldung und Site-Mitgliedschaft voraussetzen. Strategisch ist die Abkehr trotzdem sinnvoll: Öffentliche, indexierbare Inhalte und geschützte Anwendungen lassen sich dadurch architektonisch klarer voneinander trennen.

Sprechende URLs für Kategorien und CMS-Inhalte

Kategorieseiten erhalten in 2026.Q3 lesbare, lokalisierbare Pfade anstelle rein numerischer IDs. Site-Kategorien folgen dabei beispielsweise diesem Muster:

/v/[vokabular]/[kategorie]/[unterkategorie]

Fehlt ein lokalisierter Pfad, verwendet Liferay den Pfad der Standardsprache; nur in Ausnahmefällen fällt die Plattform auf eine numerische ID zurück. Bestehende ID-basierte Adressen können auf die neue URL weiterleiten. Für produktive Systeme sollte dabei geprüft werden, ob der Redirect-Typ auf permanent, also 301, eingestellt ist.

Auch Spaces im neuen CMS lassen sich mit eigenen Friendly URLs versehen. Statt einer umgebungsabhängigen Adresse wie

/asset-library-38640

kann beispielsweise

/produktdokumentation

verwendet werden. Das verbessert nicht nur die Lesbarkeit. Stabile, selbst gewählte Pfade lassen sich auch zuverlässiger zwischen Entwicklungs-, Test- und Produktivumgebungen transportieren.

Wichtig bleibt: Änderungen an Struktur- oder Space-Pfaden können zahlreiche Content-URLs gleichzeitig verändern. Nicht für jede Änderung erzeugt Liferay automatisch Redirects. Die URL-Konzeption gehört daher früh in die CMS-Architektur und nicht erst in die Go-live-Checkliste.

Sitemaps mit weniger Ballast

XML-Sitemaps lassen sich nun nach Asset-Typ gruppieren. Seiten, Web Content, Kategorien und Object Entries können dadurch in getrennten Sitemap-Dateien erscheinen. Bei großen, inhaltsreichen Sites verbessert das die technische Handhabung und verhindert, dass URLs aufgrund der Größenbegrenzung einzelner Sitemap-Dateien verloren gehen.

Zusätzlich kann Liferay die Sitemaps geplant erzeugen und zwischenspeichern. Das reduziert bei umfangreichen Installationen die wiederholte Berechnung bei jedem Abruf.

URLs, auf die eine aktive Alias- oder Pattern-Weiterleitung passt, werden automatisch aus der Sitemap entfernt. Suchmaschinen erhalten damit direkt die tatsächlich gewünschten Zieladressen, statt Crawling-Ressourcen für zusätzliche Redirect-Hops aufzuwenden.

Das ist aus unserer Sicht eine der wirkungsvollsten Änderungen des Pakets: Eine Sitemap sollte nicht die historische URL-Landschaft dokumentieren, sondern den aktuellen, indexierbaren Bestand.

Mehr Kontrolle über Such- und Facetten-URLs

Facettierte Suchen sind eine klassische Quelle für sehr viele technisch unterschiedliche, inhaltlich aber nahezu identische URLs. Pagination, Sortierung und kombinierte Filter können schnell einen großen URL-Raum erzeugen.

Liferay verbessert deshalb die SEO-Steuerung von Suchseiten und bereinigt Navigationsparameter, die nicht Teil indexierbarer Links sein müssen. Administratoren können genauer festlegen, welche Facettenzustände für Suchmaschinen relevant sein sollen.

Das reduziert drei typische Risiken:

  • Duplicate und Near-Duplicate Content,
  • unnötigen Verbrauch des Crawl-Budgets,
  • Verteilung interner Linksignale auf zahlreiche URL-Varianten.

Die richtige Konfiguration bleibt projektspezifisch. Eine Kategorie wie „Produktbereich“ kann eine sinnvolle Landingpage ergeben; ein Filter wie „Sortierung: Preis absteigend“ in der Regel nicht.

Mehrsprachigkeit und eindeutige Domains

Lokalisierte Virtual Hosts werden in 2026.Q3 korrekt für Alternate URLs berücksichtigt. Nutzt eine deutschsprachige Site beispielsweise de.example.com, kann Liferay diese Domain auch in den hreflang-Verweisen verwenden. Existiert keine lokalisierte Domain, greift die Plattform auf den Standard-Virtual-Host zurück.

Für internationale Site-Landschaften beseitigt das eine häufige Fehlerquelle: Alternate Links müssen nicht nur auf die richtige Sprache, sondern auch auf die tatsächlich vorgesehene Domain zeigen.

Ergänzend führt Liferay den Strict Virtual Host Mode ein. Standardmäßig kann eine Site auch über andere Domains derselben Instanz erreichbar sein. Im strikten Modus liefert Liferay für Zugriffe über nicht zugeordnete Domains einen 404-Status.

SEO-seitig ist das wertvoll, weil dieselben Inhalte nicht versehentlich unter mehreren Hostnamen miteinander konkurrieren. Vor der Aktivierung sollten jedoch alle produktiv verwendeten Adressen erfasst werden – einschließlich Monitoring, Lasttests, Integrationen und intern verteilter Links.

Sichtbarkeit gegenüber KI-Systemen

Thematisch passend kommt die Beta-Unterstützung für llms.txt hinzu. Liferay kann damit auf Instanz- oder Site-Ebene eine Markdown-Datei im Wurzelverzeichnis bereitstellen, die wichtige Inhalte und autoritative Quellen für KI-Werkzeuge beschreibt.

llms.txt ist allerdings kein zweites robots.txt. Es definiert keine verbindlichen Zugriffsrechte und ersetzt weder technische Zugriffskontrollen noch rechtliche Nutzungsbedingungen. Der Nutzen liegt vielmehr darin, KI-Systemen eine kuratierte Orientierung durch die wichtigsten Inhalte einer Site anzubieten.

Das Format befindet sich noch in einer frühen Phase. Unternehmen gewinnen damit aber einen zentralen, kontrollierbaren Ort, an dem sie die für KI-Anwendungen relevanten Quellen strukturieren können.

Unsere SEO-Einschätzung

Das Paket wird nicht allein deshalb bessere Rankings erzeugen, weil URLs kürzer werden. Sein Wert liegt tiefer:

Liferay reduziert die Zahl potenzieller URL-Varianten, verbessert kanonische Signale, erleichtert die Crawl-Steuerung und macht internationale Domain-Strukturen konsistenter. Gleichzeitig wandert Logik, die bisher häufig projektspezifisch entwickelt wurde, in die Plattform.

Das senkt nicht nur Implementierungsaufwand. Es reduziert auch das Risiko, dass individuelle Rewrite-Regeln, Sitemap-Erweiterungen oder Suchfilter bei einem Upgrade unbemerkt falsche SEO-Signale erzeugen.

Bei Bestandsinstallationen gilt allerdings: Die neuen Optionen sind kein Selbstläufer. Insbesondere die Entfernung von /web, Änderungen an CMS-Pfaden und der Strict Virtual Host Mode gehören in einen kontrollierten technischen SEO-Rollout.

Wie sich Liferay damit gegenüber anderen CMS positioniert

Viele klassische CMS betrachten SEO vor allem als redaktionelle Aufgabe: Seitentitel, Beschreibungen, Canonicals und Sitemaps. Komplexe URL-Räume, mehrere Sites, geschützte Anwendungen, lokalisierte Domains und Headless-Inhalte werden dagegen häufig erst durch Plugins, Reverse-Proxy-Regeln oder individuelle Erweiterungen zusammengeführt.

Liferay geht mit 2026.Q3 einen für eine DXP konsequenteren Weg. SEO wird nicht als isolierte Redaktionsfunktion behandelt, sondern als Teil der Plattformarchitektur – von URL-Auflösung und Virtual Hosts über Suche und Taxonomien bis zur Headless-Auslieferung.

Gerade bei großen, mehrsprachigen und integrationsintensiven Plattformen ist das ein Vorteil gegenüber schlankeren CMS-Systemen: Die relevanten Mechanismen arbeiten innerhalb eines gemeinsamen Berechtigungs-, Site- und Content-Modells. Weniger zusätzliche Komponenten bedeuten weniger Schnittstellen, die bei Releases separat geprüft und gepflegt werden müssen.

Einzeln betrachtet wirken viele Änderungen klein. Zusammengenommen bilden sie jedoch den praktisch nutzbarsten Teil von Liferay DXP 2026.Q3.

Portalworks ist Liferay Service Partner für die DACH-Region und begleitet Portal- und Upgrade-Projekte von der Architektur bis in den Betrieb.

Fragen dazu?

Marc Hermann antwortet persönlich – kein Vertriebsteam, kein Formularautomatismus.