AEM SEO Technische Suchmaschinenoptimierung in Adobe Experience Manager: URLs, Canonicals, Weiterleitungen, Sitemaps und Indexsteuerung
Technische SEO-Fehler entstehen in Adobe Experience Manager selten im Redaktionssystem, sondern in der Konfiguration dazwischen: im Resource Resolver, im Externalizer, im Dispatcher und im CDN. Diese Seite ordnet die SEO-Aufgaben den Schichten zu, in denen sie in AEM gelöst werden.
AEM SEO je Schicht: die meisten Aufgaben liegen auf Publish, im Dispatcher und im CDN
| Aufgabe | Schicht | Typischer Fehler |
|---|---|---|
| Kurze Adressen | Resource Resolver auf Publish | Komponenten geben ungemappte Pfade mit /content aus |
| Canonical | Seitenkomponente und Externalizer | falsche Domain oder http statt https |
| Weiterleitungen | Dispatcher oder CDN | Ketten über mehrere Schichten |
| Sitemap | Apache Sling Sitemap auf Publish | Adressen ohne Mapping oder mit Autorendomain |
| Indexsperre | Dispatcher oder CDN per Header | Vorschau- und Testumgebungen im Index |
| Statuscodes | Publish und Dispatcher | Fehlerseite mit Statuscode 200 |
Saubere URLs in AEM: Resource-Resolver-Mapping kürzt /content/<site> und muss in den Komponenten greifen
Ohne Mapping liefert AEM Seiten unter dem Repository-Pfad aus, etwa /content/marke/de/produkte.html. Adobe empfiehlt in den SEO and URL Management Best Practices, das Präfix über die OSGi-Eigenschaft resource.resolver.mapping der Resource Resolver Factory zu kürzen statt über /etc/map, weil dort die Unterstützung regulärer Ausdrücke eingeschränkter ist und Probleme bei der Invalidierung im Dispatcher entstehen können.
- Ausgabe: Das Mapping wirkt nur, wenn Komponenten Links über die
map-Funktion des Resource Resolvers erzeugen. Eigene Komponenten, die Pfade als Text zusammensetzen, geben weiter die langen Adressen aus. - Selektoren statt Parameter: Wo keine Verzeichnisstruktur passt, empfiehlt Adobe Sling-Selektoren statt Query-Strings, weil der Dispatcher Selektor-Adressen zwischenspeichern kann.
- Übersetzte Segmente: Mit
sling:aliaserhält eine Seite einen sprachspezifischen Namen, ohne die Struktur des Repositorys zu ändern. - Endung .html: Sie bleibt in klassischen AEM-Projekten meist erhalten, weil Dispatcher-Cache und Invalidierung auf Dateien mit Endung beruhen. Wer sie entfernt, braucht Rewrite-Regeln und ein Mapping, die zueinander passen und gemeinsam getestet werden.
Canonicals und Vanity URLs: Externalizer und Seiteneigenschaften bestimmen die kanonische Adresse
In den Seiteneigenschaften lässt sich die kanonische Adresse einer Seite überschreiben; bleibt das Feld leer, gilt die eigene Adresse. Falsche Domains, falsches Protokoll oder relative Adressen in Canonical und Sitemap führt Adobe im Artikel KA-34775 auf vier Ursachen zurück: eine fehlende Domain im Externalizer, einen fehlenden Header X-Forwarded-Proto, unpassende clientheaders-Regeln im Dispatcher oder einen zweiten Canonical aus eigener Template-Logik.
Vanity URLs sind kurze Zusatzadressen, etwa für Kampagnen. Ohne Weiterleitung ist dieselbe Seite unter zwei Adressen erreichbar. Für die Suche ist eine Weiterleitung auf die kanonische Adresse die eindeutigere Lösung; wo das nicht gewünscht ist, trägt der Canonical die Last.
Weiterleitungen in AEM: Rewrite Maps im Dispatcher und Regeln im CDN statt Weiterleitungsseiten
Für Weiterleitungen, die Redaktion oder SEO-Team selbst pflegen, beschreibt Adobe Pipeline-free URL Redirects: Der Dispatcher lädt Apache-Rewrite-Maps aus dem Publish-Repository und lädt sie bei Änderungen neu, konfiguriert einmalig über eine Datei managed-rewrite-maps.yaml. Gepflegt werden die Maps zum Beispiel mit dem Redirect Map Manager oder dem Redirect Manager aus ACS AEM Commons, einem Open-Source-Projekt der Community ohne Support von Adobe. Statische Regeln lassen sich in AEM as a Cloud Service zusätzlich im CDN ausführen, über die CDN-Konfiguration und die Config Pipeline.
Für die Ladezeit zählt die Zahl der Sprünge: Jede Weiterleitung kostet einen Umlauf vor der Time to First Byte. Ketten aus CDN-Regel, Dispatcher-Rewrite und Weiterleitungsseite fallen im Crawl auf, in der Redaktion nicht.
Sitemaps in AEM as a Cloud Service: Apache Sling Sitemap auf Publish erzeugen
AEM erzeugt Sitemaps über das Modul Apache Sling Sitemap. Eine Seite wird in den Seiteneigenschaften als Sitemap-Root markiert, AEM legt dafür sitemap.xml und bei Bedarf sitemap-index.xml an. Der mitgelieferte Generator gibt laut Adobe nur kanonische Adressen und vorhandene Sprachalternativen aus. Die Erzeugung im Hintergrund steuert eine OSGi-Konfiguration für org.apache.sling.sitemap.impl.SitemapScheduler, und der Dispatcher braucht eine Filterregel für die Sitemap-Dateien (Adobe Tutorial Sitemaps).
Erzeugt werden sollten Sitemaps auf Publish, weil die Mapping-Regeln, aus denen korrekte kanonische Adressen entstehen, meist nur dort vorliegen. Für AEM as a Cloud Service nennt Adobe den eingebauten Generator mit sling:sitemapRoot als Weg für mehrsprachige und MSM-Strukturen; der Sitemap-Generator aus ACS AEM Commons wird dort nicht unterstützt.
Mehrsprachige Auftritte: Language Copies, MSM Live Copies und hreflang aus derselben Struktur
AEM kennt zwei Wege zu Sprach- und Marktversionen: Sprachkopien, die das Übersetzungs-Framework standardmäßig nutzt, und Live Copies des Multi Site Managers. Adobe empfiehlt, MSM auf Inhalte innerhalb einer Sprache zu beschränken (MSM and Translation). Für SEO ergibt sich daraus ein häufiger Fall: deutschsprachige Live Copies für Deutschland, Österreich und die Schweiz mit nahezu gleichem Inhalt. Sie brauchen hreflang-Angaben mit Region und je Version einen Canonical auf sich selbst; ein Canonical auf die Mastersprache entwertet die hreflang-Angaben.
hreflang in Sitemap und Seitenkopf muss dieselbe Zuordnung zeigen. Beide entstehen aus der Sprachstruktur unter den Sprachwurzeln, deren Namen ISO-Codes wie de oder de_CH folgen.
Indexsteuerung: Vorschau und Testumgebungen per Header sperren, robots.txt aus dem DAM ausliefern
Die Vorschau-Ebene von AEM as a Cloud Service dient der Qualitätssicherung vor der Veröffentlichung (Architektur). Damit sie und Entwicklungsumgebungen nicht im Index landen, empfiehlt Adobe eine Kombination aus robots.txt und dem Header X-Robots-Tag, gesetzt im Dispatcher oder im CDN (KA-36839). Die robots.txt der Produktion liegt in vielen Projekten im DAM und wird per Rewrite-Regel unter /robots.txt ausgeliefert; der DAM-Pfad muss dafür in den Dispatcher-Filtern freigegeben sein. Bei Edge Delivery Services liefern die Adressen unter aem.page und aem.live immer eine robots.txt aus, die alle Crawler ausschließt (aem.live).
Ein Disallow verhindert das Crawlen, nicht die Aufnahme in den Index. Für Seiten, die aus dem Index verschwinden sollen, ist noindex bei erlaubtem Crawling der richtige Weg.
Strukturierte Daten in AEM: JSON-LD serverseitig aus Seiteneigenschaften und Content Fragments
Seit Version 2.31.0 der Core Components unterstützt die Seitenkomponente strukturierte Daten als JSON-LD im Seitenkopf, serverseitig gerendert. Mit Release 2026.6.0 von AEM as a Cloud Service können Autoren in den Seiteneigenschaften eigene JSON-LD-Blöcke anlegen. Für wiederkehrende Typen wie Organisation, Person oder FAQ eignet sich eine Komponente, die das Markup aus Content Fragments erzeugt, damit die Daten nur einmal gepflegt werden. Adobe empfiehlt in einem Praxisleitfaden serverseitiges Rendern, weil per JavaScript eingefügtes JSON-LD für KI-Crawler unsichtbar bleibt.
Dispatcher-Cache und SEO: Statuscodes, Query-Parameter und Core Web Vitals
Der Dispatcher speichert Antworten mit Statuscode 200, Fehlerantworten wie 404 dagegen nicht (KA-17497). Wer Fehlerseiten mit Statuscode 200 ausliefert, damit sie gespeichert werden, erzeugt Soft-404 in großer Zahl. Richtig ist ein echter 404 mit eigener Fehlerseite.
Anfragen mit Query-Parametern speichert der Dispatcher nur, wenn die Parameter als ignoriert konfiguriert sind. Adobe empfiehlt für ignoreUrlParams eine Positivliste: alle Parameter ignorieren, außer denen, die den Inhalt ändern (Dispatcher Caching). Für die Suche ist dieselbe Liste die Grundlage der Canonicals auf Parameter-Adressen. Details stehen unter AEM Dispatcher Cache.
Die Core Web Vitals gehören zu den Signalen, die Google unter Page Experience zusammenfasst, und wirken schwächer als Relevanz und Inhalt. Wie Releases gegen Felddaten abgenommen werden, beschreibt AEM DevOps.
Im AEM Core Web Vitals Benchmark 2026 bestehen 49,4 Prozent der AEM-Auftritte im DACH-Raum die Grenzwerte auf Mobilgeräten.
Kostenfreie Performance-Erstanalyse buchen
30 Minuten per Video. Sie sehen die Google-Nutzerdaten Ihrer Plattform und ob Antwortzeit, Weiterleitungen oder Frontend die Werte bestimmen.
Häufige Fragen zu AEM SEO
Warum erscheinen in AEM Adressen mit /content im Quelltext?
Weil Komponenten Links nicht über die map-Funktion des Resource Resolvers erzeugen oder das Mapping nur auf einer Umgebung konfiguriert ist. Das Mapping gehört auf alle Publish-Instanzen, und eigene Komponenten müssen es bei jeder Linkausgabe verwenden. Ein Crawl nach Adressen mit /content zeigt die betroffenen Komponenten.
Wo sollte die Sitemap in AEM erzeugt werden?
Auf Publish. In der Regel liegen nur dort die Mapping-Regeln vor, mit denen kanonische Adressen korrekt entstehen. In AEM as a Cloud Service ist dafür der eingebaute Generator auf Basis von Apache Sling Sitemap vorgesehen, gesteuert über die Markierung als Sitemap-Root und einen Zeitplan in der OSGi-Konfiguration.
Wie werden Weiterleitungen in AEM as a Cloud Service ohne Deployment gepflegt?
Über Rewrite Maps, die der Dispatcher aus dem Publish-Repository lädt. Adobe beschreibt das als Pipeline-free URL Redirects; gepflegt werden die Maps etwa mit dem Redirect Map Manager aus ACS AEM Commons. Statische Regeln lassen sich zusätzlich im CDN ausführen.
Wirkt der Dispatcher-Cache auf die Suchmaschinenoptimierung?
Ja, auf zwei Wegen. Er bestimmt die Antwortzeit und damit einen Teil des Largest Contentful Paint, und seine Regeln für Query-Parameter und Statuscodes entscheiden über doppelte Adressen und Soft-404. Beides gehört in dieselbe Prüfung.