Eine URL wirkt unscheinbar.
Sie steht oben im Browser, wird kopiert, verlinkt und meistens kaum beachtet.
Trotzdem gehört sie zu den dauerhaftesten Bestandteilen einer Website.
Ein Seitentitel kann morgen geändert werden.
Ein Absatz kann überarbeitet werden.
Das Design kann komplett verschwinden.
WordPress kann durch ein anderes CMS ersetzt werden.
Die Adresse eines etablierten Inhalts sollte dagegen möglichst bestehen bleiben.
Genau deshalb nennt WordPress solche Adressen Permalinks: permanente Links. Die offizielle WordPress-Dokumentation beschreibt sie ausdrücklich als dauerhafte URLs für Beiträge, Seiten und Archive und empfiehlt, sie nach Möglichkeit nicht nachträglich zu ändern. (WordPress.org)
Eine gute URL-Struktur soll deshalb nicht in erster Linie besonders „SEO-optimiert“ aussehen.
Sie soll vor allem drei Eigenschaften besitzen:
verständlich
stabil
technisch eindeutig
Wenn diese drei Punkte stimmen, sind bereits viele Probleme vermieden, die wir in den vorherigen Artikeln über Canonicals, Weiterleitungen und Indexierung behandelt haben.
Was ist eine URL?
URL steht für Uniform Resource Locator.
Vereinfacht ist sie die Adresse einer Ressource im Web.
Eine vollständige URL kann beispielsweise so aussehen:
https://example.de/wissen/url-struktur/?quelle=newsletter#parameter
Darin stecken mehrere Bestandteile:
https://
│
├── Protokoll
│
example.de
│
├── Host
│
/wissen/url-struktur/
│
├── Pfad
│
?quelle=newsletter
│
├── Query-Parameter
│
#parameter
│
└── Fragment
Nicht jede URL besitzt sämtliche Bestandteile.
Eine einfache Wissensseite kann beispielsweise nur bestehen aus:
https://example.de/wissen/url-struktur/
Gerade für redaktionelle Inhalte ist diese Einfachheit oft ausgesprochen wertvoll.
Die Domain und der URL-Pfad sind unterschiedliche Ebenen
Nehmen wir:
https://example.de/wissen/caching/
Die Domain beziehungsweise der Host lautet:
example.de
Der Pfad lautet:
/wissen/caching/
Die Domain beantwortet also:
Auf welcher Website befindet sich die Ressource?
Der Pfad beantwortet:
Unter welcher Adresse innerhalb dieser Website befindet sie sich?
Unsere bisherigen Grundlagen zu Domains und DNS behandeln die erste Ebene.
Bei der URL-Struktur konzentrieren wir uns nun hauptsächlich auf die zweite.
Eine URL ist nicht dasselbe wie die Website-Hierarchie
Das ist für die Planung eines Wissensportals besonders wichtig.
Eine Seite kann unter:
/wissen/caching/
liegen und logisch trotzdem Teil folgender Struktur sein:
Wissen
↓
Web & WordPress
↓
Performance
↓
Caching
Die komplette Informationshierarchie muss also nicht zwangsläufig als:
/wissen/web-wordpress/performance/caching/
in die URL geschrieben werden.
Hierarchie kann zusätzlich durch:
Navigation,
Hub-Seiten,
Breadcrumbs,
interne Links
und redaktionelle Zusammenhänge
entstehen.
URL-Struktur und Informationsarchitektur hängen zusammen – sie sind aber nicht identisch.
Google empfiehlt verständliche und logische URLs
Google empfiehlt aktuell ausdrücklich eine einfache URL-Struktur mit für Menschen verständlichen Wörtern. Lange unlesbare IDs sind weniger hilfreich als beschreibende Pfade. Außerdem empfiehlt Google, Begriffe in der Sprache der Zielgruppe zu verwenden. (Google for Developers)
Vergleichen wir:
https://example.de/index.php?id=7281593&cat=42
mit:
https://example.de/wissen/caching/
Schon ohne die Seite zu öffnen, vermittelt die zweite Adresse einen ungefähren Inhalt.
Das ist nützlich für Menschen.
Und es macht die URL-Struktur technisch und redaktionell leichter nachvollziehbar.
Eine URL sollte beschreiben, nicht den kompletten Titel wiederholen
Angenommen, ein Artikel trägt den Titel:
WordPress-Performance optimieren: So wird deine Website schneller
Der Slug muss daraus nicht zwangsläufig werden:
/wordpress-performance-optimieren-so-wird-deine-website-schneller/
Eine wesentlich stabilere Adresse wäre:
/wordpress-performance/
Der Seitentitel darf sich später verändern.
Vielleicht lautet er in zwei Jahren:
WordPress schneller machen: Der komplette Performance-Leitfaden
Die URL kann trotzdem unverändert bleiben.
Das ist einer der größten Vorteile eines guten Slugs:
Er beschreibt das Thema, nicht die aktuelle Formulierung der Überschrift.
Was ist ein Slug?
Bei WordPress bezeichnet der Slug den URL-relevanten Namen eines Beitrags oder einer Seite.
Aus einem Titel wie:
Das ist ein großartiger Beitrag!
erzeugt WordPress beispielsweise einen bereinigten Postnamen mit Bindestrichen. Der %postname%-Baustein einer WordPress-Permalink-Struktur verwendet genau diesen bereinigten Slug. (WordPress.org)
Für:
Was ist Webhosting?
könnte der Slug lauten:
was-ist-webhosting
und die vollständige URL:
https://example.de/wissen/was-ist-webhosting/
Gute Slugs sollten auch in fünf Jahren noch passen
Das ist ein besseres Qualitätskriterium als:
Enthält die URL mein Hauptkeyword?
Angenommen, ein Artikel erscheint mit:
/die-10-besten-wordpress-plugins-2026/
Später werden daraus 14 Plugins.
2027 wird der Artikel erneut aktualisiert.
Nun besitzt die URL drei historische Informationen, die nicht mehr stimmen:
10
besten
2026
Der Inhalt kann natürlich trotzdem aktualisiert werden.
Aber die Adresse ist unnötig an die erste Artikelversion gebunden.
Robuster wäre beispielsweise:
/wordpress-plugins-auswahl/
oder – abhängig vom Inhalt – eine andere dauerhaft passende Form.
Zahlen im Slug sind nicht grundsätzlich falsch
Ein Artikel kann tatsächlich dauerhaft eine bestimmte Zahl behandeln.
Zum Beispiel:
/3-2-1-backup-regel/
Hier ist „3-2-1“ Bestandteil des Konzepts.
Das ist etwas völlig anderes als eine Listenüberschrift:
/7-tipps-fuer-...
die nächstes Jahr vielleicht zwölf Tipps enthält.
Die Frage lautet deshalb nicht:
Sind Zahlen in URLs erlaubt?
Sondern:
Gehört diese Zahl dauerhaft zur Identität des Themas?
Jahreszahlen sind ebenfalls nicht grundsätzlich verboten
Ein Beitrag über eine konkrete Veranstaltung kann sinnvoll heißen:
/wordpress-konferenz-2026/
Das Jahr ist Teil des Themas.
Ein Evergreen-Ratgeber wie:
/wordpress-seo-tipps-2026/
wird dagegen unnötig gealtert, wenn er jedes Jahr weiter gepflegt werden soll.
Datums- und Jahresangaben sollten also eine fachliche Bedeutung besitzen – nicht nur aktuelle Frische simulieren.
„Kurz“ ist kein Selbstzweck
Häufig lautet die Empfehlung:
URLs müssen möglichst kurz sein.
Daraus entstehen manchmal Slugs wie:
/wp-perf/
oder:
/dns2/
Das ist zwar kurz.
Aber nicht unbedingt verständlich.
Eine etwas längere URL wie:
/wordpress-performance/
ist für Menschen wesentlich eindeutiger.
Google empfiehlt beschreibende Wörter und eine logische, verständliche Struktur. Die Forderung lautet nicht, jede URL auf möglichst wenige Zeichen zu reduzieren. (Google for Developers)
Die bessere Regel lautet:
So kurz wie sinnvoll – nicht so kurz wie technisch möglich.
Unnötige Wörter können trotzdem entfallen
Ein Titel lautet:
Was ist eine Domain und wie funktioniert eine Domain eigentlich genau?
Ein Slug könnte einfach sein:
/was-ist-eine-domain/
Niemand braucht:
/was-ist-eine-domain-und-wie-funktioniert-eine-domain-eigentlich-genau/
Die URL soll das Thema identifizieren.
Sie muss keinen vollständigen Satz darstellen.
Stoppwörter müssen nicht zwanghaft entfernt werden
Manche ältere SEO-Anleitungen entfernen automatisch Wörter wie:
was
ist
eine
und
wie
Dann wird aus:
/was-ist-eine-domain/
beispielsweise:
/domain/
Beides kann funktionieren.
Aber „was-ist-eine-domain“ beschreibt die konkrete Seite hervorragend und ist für Menschen unmittelbar verständlich.
Es gibt keinen Grund, natürliche Sprache zugunsten einer kryptischen Keyword-Konstruktion zu zerstören.
Google empfiehlt ausdrücklich URLs in der Sprache der Zielgruppe und für Menschen verständliche Wörter. (Google for Developers)
Bindestriche sind die sinnvollste Worttrennung
Google empfiehlt derzeit Bindestriche:
wordpress-performance
statt Unterstrichen:
wordpress_performance
oder zusammengeschriebenen Wörtern:
wordpressperformance
Google begründet dies unter anderem mit der etablierten Bedeutung von Unterstrichen in anderen technischen Kontexten. (Google for Developers)
Für einen neuen Slug ist deshalb:
/wordpress-performance/
eine naheliegende Schreibweise.
Bestehende Unterstrich-URLs müssen deshalb nicht sofort umgebaut werden
Angenommen, eine Website besitzt seit zehn Jahren:
/wordpress_performance/
Die Seite ist indexiert.
Sie besitzt externe Links.
Alles funktioniert.
Nun wäre es absurd, nur wegen des Bindestrich-Hinweises die URL zu ändern und eine Migration zu verursachen.
Eine etablierte funktionierende URL ist häufig wertvoller als eine theoretisch hübschere neue.
Das ist eine der wichtigsten Regeln dieses gesamten Artikels:
Best Practice für neue URLs ist nicht automatisch ein Migrationsgrund für bestehende URLs.
Groß- und Kleinschreibung sollte vereinheitlicht werden
Google behandelt URL-Pfade grundsätzlich case-sensitive. Damit können:
/WordPress/
und:
/wordpress/
als unterschiedliche URLs verstanden werden. Wenn der eigene Server beide Varianten gleich behandelt, empfiehlt Google, sich auf eine einheitliche Groß- oder Kleinschreibung festzulegen. (Google for Developers)
Für normale Webadressen ist konsequente Kleinschreibung meist am einfachsten:
/wordpress-performance/
statt:
/WordPress-Performance/
Das reduziert mögliche Varianten.
Uneinheitliche Großschreibung kann Duplikate erzeugen
Stell dir einen Server vor, der sowohl:
/Wissen/Caching/
als auch:
/wissen/caching/
mit 200 OK ausliefert.
Für Menschen erscheint derselbe Inhalt.
Technisch existieren aber zwei URLs.
Nun müssen:
Canonical,
Weiterleitung
oder andere Signale
diese Varianten wieder zusammenführen.
Einheitliche URL-Erzeugung verhindert das Problem bereits an der Quelle.
Die Sprache der Zielgruppe darf in der URL vorkommen
Google empfiehlt ausdrücklich Wörter in der Sprache des jeweiligen Publikums. Für eine deutschsprachige Website sind also deutsche Slugs vollkommen sinnvoll. (Google for Developers)
Beispielsweise:
/wissen/webhosting/
oder:
/wissen/bilder-optimieren/
Es besteht kein SEO-Grund, daraus zwanghaft englische Pfade zu machen wie:
/knowledge/image-optimization/
wenn die gesamte Website deutschsprachig ist.
Was ist mit Umlauten?
Technisch können URLs auch Nicht-ASCII-Zeichen enthalten beziehungsweise entsprechend codiert übertragen werden. Google empfiehlt für Zielgruppenbegriffe ausdrücklich auch Wörter in der jeweiligen Sprache und nennt selbst Beispiele mit nichtlateinischen Zeichen. (Google for Developers)
Eine deutsche URL könnte theoretisch beispielsweise enthalten:
/über-uns/
In übertragenen oder kopierten Formen kann daraus eine prozentcodierte Darstellung entstehen.
Für die redaktionelle Praxis kann deshalb auch die Umschrift:
/ueber-uns/
angenehm sein.
Das ist jedoch eher eine Entscheidung über Lesbarkeit, Kompatibilität und Konvention als eine notwendige SEO-Regel.
Für ein bestehendes System sollte eine Konvention festgelegt werden
Bei deutschen Slugs sollte nicht zufällig gemischt werden:
/über-uns/
/groesse/
/schöne-bilder/
/aenderungen/
Besser ist eine klare redaktionelle Regel.
Beispielsweise:
ä → ae
ö → oe
ü → ue
ß → ss
oder bewusst echte Unicode-Zeichen.
Eine gute URL-Struktur lebt von Konsistenz.
Sonderzeichen sollte man nicht dekorativ einsetzen
Ein Slug wie:
/bester+++wordpress!!!/
ist weder für Menschen noch technisch besonders elegant.
Google erwartet URLs gemäß den entsprechenden Internetstandards; reservierte Zeichen müssen korrekt codiert werden. (Google for Developers)
Normale Wörter, Ziffern und Bindestriche decken fast sämtliche redaktionellen URL-Anforderungen ab.
Ein Slug braucht keine grafische Kreativität.
WordPress bietet verschiedene Permalink-Strukturen
WordPress kann Beiträge mit unterschiedlichen globalen Strukturen erzeugen.
Die aktuelle Dokumentation nennt unter anderem:
Plain
Day and name
Month and name
Numeric
Post name
Custom Structure
Eine benutzerdefinierte Struktur kann über Platzhalter wie %postname%, %year%, %monthnum%, %category% oder %post_id% aufgebaut werden. (WordPress.org)
Damit lässt sich nahezu jede klassische Blogstruktur erzeugen.
Die entscheidende Frage ist nicht, was technisch möglich ist.
Sondern:
Welche Struktur bleibt langfristig sinnvoll?
Die einfache Post-Name-Struktur ist für viele Websites attraktiv
Ein WordPress-Blog könnte beispielsweise Beiträge erzeugen als:
/beitragstitel/
Die Permalink-Einstellung verwendet dafür %postname%. WordPress unterstützt diese Struktur nativ. (WordPress.org)
Für ein klassisches kleines Blog kann das sehr übersichtlich sein.
Bei größeren Portalen möchte man möglicherweise zusätzlich einen stabilen funktionalen Bereich unterscheiden.
Beispielsweise:
/wissen/caching/
/magazin/neue-wordpress-version/
Damit lässt sich bereits an der URL erkennen, ob ein Inhalt zum Evergreen-Wissen oder zum Magazin gehört.
Genau deshalb ist die Casiopeya-Struktur sinnvoll flach
Für den Wissensbereich verwenden wir:
/wissen/<slug>/
beispielsweise:
/wissen/was-ist-dns/
/wissen/caching/
/wissen/canonical-tag/
Die fachliche Einordnung:
Web & WordPress
→ Performance
oder:
Web & WordPress
→ SEO & Analyse
steckt bewusst nicht vollständig im URL-Pfad.
Warum?
Weil sich die redaktionelle Taxonomie später verändern kann.
Ein Artikel kann in einen anderen Unterbereich verschoben werden, ohne dass seine öffentliche Adresse geändert werden muss.
Eine tiefe URL kann redaktionelle Änderungen teuer machen
Angenommen, wir verwenden:
/wissen/web-wordpress/performance/core-web-vitals/
Später wird der Bereich umstrukturiert und Core Web Vitals gehören redaktionell zu:
SEO & Analyse
Müssten wir die URL nun ändern zu:
/wissen/web-wordpress/seo-analyse/core-web-vitals/
entsteht ein unnötiger technischer Umzug.
Mit:
/wissen/core-web-vitals/
kann die Seite redaktionell beliebig neu eingeordnet werden.
Navigation und interne Verlinkung ändern sich.
Die URL bleibt stabil.
Tiefe URLs sind deshalb nicht grundsätzlich schlecht
Eine Struktur wie:
/shop/schuhe/herren/laufschuhe/
kann fachlich vollkommen sinnvoll sein.
Wenn diese Taxonomie tatsächlich stabiler Bestandteil des Angebots ist, spricht nichts gegen mehrere Verzeichnisebenen.
Google empfiehlt logisch und verständlich konstruierte URLs. (Google for Developers)
Das Problem ist also nicht:
Mehr als ein Slash ist schlecht.
Sondern:
Wird jede URL-Ebene wirklich dauerhaft benötigt?
URL-Tiefe und Klicktiefe sind zwei unterschiedliche Dinge
Eine Seite kann heißen:
/a/
und trotzdem nur nach sieben Klicks erreichbar sein.
Eine andere kann heißen:
/wissen/web/wordpress/performance/caching/
und direkt von der Startseite verlinkt sein.
Die Länge des Pfades sagt deshalb nicht automatisch, wie tief ein Inhalt innerhalb der Navigation steckt.
Suchmaschinen entdecken Seiten über Links und Sitemaps; eine sinnvolle interne Verlinkung bleibt unabhängig von der URL-Länge entscheidend. (Google for Developers)
Kategorien in WordPress-URLs sind möglich
WordPress unterstützt %category% in benutzerdefinierten Permalink-Strukturen. Dabei kann eine bereinigte Kategoriebezeichnung Teil der URL werden; verschachtelte Unterkategorien können zusätzliche Verzeichnisse erzeugen. (WordPress.org)
Beispielsweise:
/%category%/%postname%/
könnte ergeben:
/wordpress/caching/
Das sieht zunächst sehr ordentlich aus.
Es besitzt allerdings eine wichtige Konsequenz:
Die Kategorie wird Teil der Adresse des Beitrags.
Dann wird ein Kategorienwechsel zum URL-Wechsel
Angenommen, der Artikel liegt zunächst unter:
/performance/caching/
Später wird er in eine neue Kategorie verschoben:
/wordpress/caching/
Wenn die Kategorie Teil des Permalinks ist, hat sich damit auch die öffentliche URL verändert.
Nun brauchen wir gegebenenfalls:
301-Weiterleitung,
aktualisierte interne Links,
neues Canonical,
aktualisierte Sitemap.
Eine rein redaktionelle Entscheidung wird zu einer technischen Migration.
Genau deshalb würde ich bei einem großen Wissensportal Kategorien nicht ohne guten Grund in Artikel-URLs einbauen.
Mehrfachkategorien machen das Modell zusätzlich komplizierter
Ein WordPress-Beitrag kann mehreren Kategorien zugeordnet sein.
Wenn %category% Teil des Permalinks ist, muss WordPress trotzdem eine bestimmte Kategorie für die URL wählen. Die offizielle Dokumentation weist darauf hin, dass bei mehreren Kategorien nur eine davon im Permalink erscheinen kann. (WordPress.org)
Damit entsteht eine interessante Frage:
Wenn der Inhalt fachlich zu drei Themen gehört, warum sollte ausgerechnet eine davon dauerhaft Bestandteil seiner Adresse werden?
Für Navigation sind Kategorien flexibel.
Für permanente URLs oft weniger.
Datumsangaben in WordPress-Permalinks sind ebenfalls möglich
WordPress unterstützt beispielsweise:
/%year%/%monthnum%/%day%/%postname%/
oder Strukturen mit Jahr und Monat. (WordPress.org)
Ein Nachrichtenblog könnte dadurch erzeugen:
/2026/08/09/neue-wordpress-version/
Bei tatsächlich zeitgebundenen Nachrichten kann das nachvollziehbar sein.
Bei Evergreen-Wissen besitzt ein Datum dagegen oft wenig funktionalen Nutzen.
Ein Datum kann einen Evergreen-Inhalt unnötig alt aussehen lassen
Angenommen:
/2022/04/was-ist-dns/
Der Artikel wird 2026 vollständig aktualisiert.
Die URL trägt trotzdem weiterhin 2022.
Technisch ist daran nichts kaputt.
Für Menschen kann die Adresse aber unnötig an die ursprüngliche Veröffentlichung erinnern.
Daraus folgt nicht:
Alle Websites mit Datums-URLs müssen migrieren.
Es folgt nur:
Bei neuen Evergreen-Projekten sollte man überlegen, ob das Datum überhaupt dauerhaft zur Adresse gehört.
Bereits etablierte Datums-URLs sollte man nicht leichtfertig entfernen
Eine Website besitzt seit zwölf Jahren:
/2020/05/artikel/
/2021/02/artikel/
/2022/09/artikel/
Nun liest jemand:
Dates in URLs are bad.
Und 5.000 URLs werden verändert.
Das erzeugt eine massive Migration für einen möglicherweise sehr kleinen Nutzen.
WordPress selbst betont den dauerhaften Charakter von Permalinks. (WordPress.org)
Eine neue Struktur anders zu planen und eine etablierte Struktur umzubauen sind zwei völlig unterschiedliche Entscheidungen.
IDs in URLs sind technisch nicht falsch
WordPress kann beispielsweise eine numerische Struktur verwenden.
Eine andere Anwendung könnte erzeugen:
/product/183721/
Google kann solche URLs grundsätzlich crawlen.
Google empfiehlt jedoch, wenn möglich verständliche beschreibende Wörter statt langer nichtssagender IDs zu verwenden. (Google for Developers)
Für einen Menschen sagt:
/product/183721/
wenig.
Dagegen:
/product/roter-wasserkocher/
vermittelt bereits Kontext.
IDs können trotzdem technisch sinnvoll sein
Bei sehr großen Datenbanken können interne IDs nützlich sein.
Eine URL kann beispielsweise gleichzeitig ID und lesbaren Slug besitzen:
/product/183721-roter-wasserkocher/
Ob das sinnvoll ist, hängt von der Anwendung ab.
SEO verlangt nicht, dass ein technisches System sämtliche internen Identifikatoren versteckt.
Die URL sollte nur nicht unnötig unverständlich werden.
Query-Parameter sind normale Bestandteile von URLs
Eine URL kann nach einem Fragezeichen zusätzliche Informationen übermitteln.
Beispielsweise:
/shop?farbe=rot&sortierung=preis
Google empfiehlt für Parameter die übliche Form:
?key=value&key2=value2
also = zwischen Schlüssel und Wert sowie & zwischen mehreren Parametern. (Google for Developers)
Parameter sind nicht automatisch schlecht.
Sie sind ein normales Werkzeug des Webs.
Problematisch wird vor allem ihre unkontrollierte Vervielfachung.
Ein Parameter kann den Inhalt tatsächlich verändern
Beispiel:
/schuhe?farbe=rot
zeigt rote Schuhe.
/schuhe?farbe=blau
zeigt blaue Schuhe.
Hier hat der Parameter eine echte Funktion.
Ob beide Varianten als eigene Suchseiten relevant sein sollen, ist eine separate Architekturentscheidung.
Google behandelt gerade facettierte Navigation und Filter als Bereich, in dem schnell sehr viele URLs entstehen können. (Google for Developers)
Andere Parameter verändern den Inhalt überhaupt nicht
Beispielsweise:
/artikel?utm_source=newsletter
Der Artikel bleibt exakt derselbe.
Der Parameter dient nur der Kampagnenzuordnung.
Solche Varianten sollten nicht plötzlich zu eigenständigen Inhaltsadressen werden.
Hier kommen unsere bereits behandelten Canonical-Grundlagen ins Spiel.
Die stabile Haupt-URL bleibt beispielsweise:
/artikel/
Unnötige Parameter sollten möglichst vermieden werden
Google empfiehlt ausdrücklich, die Zahl unnötiger URL-Parameter möglichst klein zu halten. Besonders Referral-, Sortier- und Session-Parameter können sehr große Mengen zusätzlicher URLs erzeugen. (Google for Developers)
Eine Website mit einem echten Artikel sollte nicht versehentlich tausende technisch unterschiedliche Adressen desselben Inhalts erzeugen.
Beispielsweise:
/artikel/?session=123
/artikel/?session=456
/artikel/?session=789
Das erzeugt Crawl- und Canonicalisierungsarbeit ohne zusätzlichen Inhalt.
Session-IDs gehören nach Möglichkeit nicht in URLs
Google nennt Session-IDs ausdrücklich als Beispiel für irrelevante Parameter und empfiehlt, sie nach Möglichkeit nicht in URLs zu verwenden. (Google for Developers)
Warum das problematisch ist, sieht man sofort.
Jeder Besucher könnte eine eigene URL erzeugen:
/artikel?sessionid=a1
/artikel?sessionid=b2
/artikel?sessionid=c3
Inhaltlich handelt es sich aber möglicherweise um dieselbe Seite.
Aus einer Ressource werden technisch tausende URLs.
Das ist unnötige Komplexität.
Filter können eine URL-Explosion erzeugen
Nehmen wir einen Shop mit fünf Filtern:
Farbe.
Größe.
Marke.
Material.
Preis.
Jeder Filter besitzt mehrere Werte.
Nun können Kombinationen entstehen:
?farbe=rot
?farbe=rot&groesse=42
?farbe=rot&groesse=42&marke=x
?farbe=rot&groesse=42&marke=x&material=leder
Dazu kommen unterschiedliche Sortierungen:
&sort=preis
&sort=beliebt
&sort=neu
Aus relativ wenigen Produkten können tausende unterschiedliche URL-Varianten entstehen.
Google warnt ausdrücklich vor komplexen URL-Strukturen, bei denen additive Filter und andere Parameter sehr große Mengen gleicher oder ähnlicher Inhalte erzeugen. (Google for Developers)
Gute URL-Planung beginnt deshalb beim Anwendungskonzept
Das Problem lässt sich nicht vollständig durch ein SEO-Plugin lösen.
Bevor ein Shop oder Verzeichnis entwickelt wird, sollte geklärt werden:
Welche Filter brauchen eigene URLs?
Welche davon sollen crawlbar sein?
Welche besitzen eigenständigen Suchwert?
Welche sind nur Bedienfunktionen?
Welche URL ist kanonisch?
Welche Kombinationen dürfen überhaupt intern verlinkt werden?
URL-Architektur ist hier Teil der Softwarearchitektur.
Unendliche URL-Räume sind besonders problematisch
Google nennt beispielsweise dynamische Kalender als typischen Fall.
Wenn eine Website automatisch Links erzeugt zu:
/jahr/2026/
/jahr/2027/
/jahr/2028/
...
und ebenso unbegrenzt rückwärts, kann der Crawler theoretisch immer neue Adressen entdecken. Google dokumentiert solche „infinite spaces“ ausdrücklich als URL-Strukturproblem. (Google for Developers)
Dasselbe Prinzip kann entstehen durch:
Kalender,
endlose Filterkombinationen,
automatische Pagination,
zufällige Parameter.
Ein Crawler sollte nicht durch eine technisch unendliche Website laufen müssen.
Fragmente funktionieren anders als Query-Parameter
Ein Fragment steht hinter:
#
zum Beispiel:
/wissen/url-struktur/#parameter
Solche Fragmente werden häufig verwendet, um zu einer bestimmten Stelle innerhalb eines Dokuments zu springen.
Beispielsweise:
#wordpress
kann direkt zum Abschnitt über WordPress führen.
Für klassische Sprungmarken innerhalb einer Seite ist das völlig normal.
Ein Fragment sollte aber nicht verschiedene Webseiten simulieren
Google empfiehlt ausdrücklich, URL-Fragmente nicht zu verwenden, um unterschiedliche Seiteninhalte zu repräsentieren. Google Search unterstützt Fragmente für solche Inhaltswechsel im Allgemeinen nicht als separate URL-Struktur. Für JavaScript-Anwendungen empfiehlt Google stattdessen geeignete History-API-basierte URLs. (Google for Developers)
Problematisch wäre also ein System wie:
/shop/#schuhe
/shop/#jacken
/shop/#hosen
wenn diese Fragmente eigentlich drei vollständig unterschiedliche Suchseiten darstellen sollen.
Robuster wären echte crawlbare URLs.
Sprungmarken innerhalb eines Artikels sind etwas anderes
Beispielsweise:
/wissen/url-struktur/#wordpress
bedeutet weiterhin:
Öffne denselben Artikel, aber springe zum Abschnitt WordPress.
Der Hauptinhalt und seine kanonische Identität bleiben:
/wissen/url-struktur/
Das ist ein sinnvoller Fragment-Einsatz.
Die wichtige Trennung lautet also:
Fragment zur Navigation innerhalb eines Dokuments: normal.
Fragment als Ersatz für unterschiedliche eigenständige Inhalte: problematisch.
Trailing Slash oder kein Trailing Slash?
Zwei URLs können aussehen wie:
/wissen/caching/
und:
/wissen/caching
Welches Format verwendet werden soll, ist weniger wichtig als Konsistenz.
Ein Server kann beide Varianten unterschiedlich behandeln.
Eine Website sollte deshalb eine bevorzugte Form definieren und die andere bei Bedarf darauf weiterleiten.
Für WordPress hängt die konkrete Darstellung von der Permalink-Konfiguration und dem Routing ab.
Beide Varianten sollten nicht parallel denselben Inhalt mit 200 liefern
Wenn:
/wissen/caching
und:
/wissen/caching/
beide unabhängig mit:
200 OK
denselben Inhalt ausliefern, entstehen zwei Adressen.
Nun muss Canonicalisierung sie wieder zusammenführen.
Sauberer ist:
/wissen/caching
↓
301
/wissen/caching/
oder umgekehrt.
Dann existiert genau eine bevorzugte öffentliche Adresse.
Der Slash selbst besitzt keinen magischen SEO-Wert
Es gibt keinen Grund, eine etablierte Website nur aus SEO-Gründen von:
/artikel
auf:
/artikel/
umzustellen.
Der Nutzen liegt in Einheitlichkeit und technischer Eindeutigkeit.
Nicht in der Form des letzten Zeichens.
Die Dateiendung muss nicht Bestandteil moderner Content-URLs sein
Ältere Seiten besitzen häufig:
/artikel.html
oder:
/index.php?id=23
Moderne CMS können ohne sichtbare Dateiendung arbeiten:
/artikel/
Das ist meist leichter lesbar und weniger an eine konkrete technische Implementierung gebunden.
Wenn eine etablierte Seite allerdings seit Jahren unter:
/artikel.html
läuft, besteht wiederum kein Zwang, sie nur aus optischen Gründen umzubenennen.
Technische Implementierung sollte möglichst nicht in der URL festgeschrieben werden
Angenommen, eine Website nutzt heute PHP:
/ratgeber.php
Morgen wird sie auf ein anderes System migriert.
Die Ressource ist inhaltlich weiterhin derselbe Ratgeber.
Eine neutrale Adresse:
/ratgeber/
ist weniger an die technische Plattform gebunden.
Das erhöht langfristige Flexibilität.
Es ist ein gutes Beispiel dafür, warum URLs eher Inhalte als Software beschreiben sollten.
Eine URL sollte nicht ständig mit dem Seitentitel synchronisiert werden
WordPress erzeugt bei der ersten Veröffentlichung typischerweise einen Slug aus dem Beitragstitel. Der %postname% basiert auf dem bereinigten Titel beziehungsweise dem im Editor festgelegten Slug. (WordPress.org)
Danach sollte der Slug jedoch bewusst als dauerhafte Adresse betrachtet werden.
Ändert sich die Überschrift von:
Was ist DNS?
zu:
DNS verstehen: So funktioniert das Domain Name System
muss daraus nicht automatisch eine neue URL werden.
Die bestehende Adresse:
/was-ist-dns/
passt weiterhin hervorragend.
Überschriften dürfen dynamischer sein als URLs
Ein Seitentitel muss möglicherweise:
aktueller,
präziser,
attraktiver,
vollständiger
werden.
Die URL erfüllt eine andere Aufgabe.
Sie identifiziert die Ressource.
Deshalb ist es völlig normal, wenn Titel und Slug nach einigen Jahren nicht mehr wortgleich sind.
Das ist kein SEO-Fehler.
Es ist häufig ein Zeichen dafür, dass die URL vernünftig stabil geplant wurde.
URL-Änderungen benötigen einen echten Grund
Ein sinnvoller Grund kann sein:
Eine fehlerhafte oder irreführende Adresse.
Eine umfangreiche Website-Migration.
Zwei Inhalte werden zusammengeführt.
Eine technische Altstruktur wird bewusst aufgelöst.
Eine Domain ändert sich.
Ein nicht mehr haltbarer Produktname muss ersetzt werden.
Nicht ausreichend ist häufig:
Der neue Slug klingt etwas besser.
Jede URL-Änderung erzeugt technische Folgearbeit.
Bei einer URL-Änderung beginnt eine kleine Migration
Aus:
/alter-slug/
wird:
/neuer-slug/
Dann müssen wir mindestens betrachten:
301-Weiterleitung
interne Links
Canonical
Sitemap
eventuelle externe Referenzen
Genau deshalb haben wir den Artikel zu 301-Weiterleitungen vor dieser Seite aufgebaut.
Eine URL umzubenennen bedeutet nicht nur, ein WordPress-Feld zu bearbeiten.
Alte URLs sollten möglichst direkt auf die neue Zieladresse zeigen
Wenn eine Änderung notwendig ist:
/alt/
↓
301
/neu/
Die interne Navigation wird ebenfalls auf:
/neu/
angepasst.
Das Canonical lautet:
/neu/
Die Sitemap enthält:
/neu/
Damit besitzt die neue Adresse sofort eine konsistente technische Umgebung.
Eine URL sollte nicht die gesamte Navigation nachbilden
Nehmen wir eine Wissensseite mit folgender Navigation:
Wissen
→ Web & WordPress
→ SEO & Analyse
→ URL-Struktur
Man könnte daraus machen:
/wissen/web-wordpress/seo-analyse/url-struktur/
Das ist nicht automatisch falsch.
Aber jede Ebene erhöht die Bindung zwischen Navigation und öffentlicher Adresse.
Eine zukünftige Umstrukturierung wird dadurch schwieriger.
Deshalb ist bei redaktionellen Inhalten oft sinnvoll:
/wissen/url-struktur/
während Navigation und Breadcrumb die vollständige fachliche Einordnung darstellen.
Bei Shops kann Hierarchie dagegen stärker zur URL gehören
Ein Shop kann sinnvoll besitzen:
/herren/schuhe/laufschuhe/
wenn diese Ebenen tatsächlich stabile eigene Kategorieseiten sind.
Dann beschreibt die URL eine echte taxonomische Struktur.
Google empfiehlt logisch aufgebaute und beschreibende URL-Pfade und weist gerade für E-Commerce darauf hin, alternative URLs mit identischem Inhalt möglichst zu reduzieren. (Google for Developers)
Auch hier gilt also:
Keine pauschale Regel.
Der Seitentyp entscheidet.
Mehrsprachigkeit braucht ebenfalls eine URL-Strategie
Für mehrsprachige Websites können beispielsweise Unterverzeichnisse genutzt werden:
/de/wissen/caching/
/en/knowledge/caching/
Google nennt länderspezifische Domains oder sprach-/regionsbezogene Unterverzeichnisse als mögliche verständliche Strukturen für multiregionale Websites. (Google for Developers)
Wichtig ist wiederum eine frühzeitige Entscheidung.
Später die komplette Sprachebene in tausende etablierte URLs einzubauen, bedeutet einen großen Umzug.
Sprachen sollten nicht nur als Parameter versteckt werden, wenn echte eigenständige Seiten benötigt werden
Ein Modell wie:
/artikel?lang=de
/artikel?lang=en
kann technisch funktionieren.
Für umfangreiche mehrsprachige Contentprojekte sind klar getrennte crawlbare URLs häufig leichter zu verwalten:
/de/artikel/
/en/article/
Dann lassen sich:
Canonicals,
hreflang,
Sitemaps
und interne Navigation
klar pro Sprachversion abbilden.
Die genaue Mehrsprachenarchitektur behandeln wir später separat.
Subdomains sind ebenfalls eigene URL-Bereiche
Beispielsweise:
blog.example.de
shop.example.de
hilfe.example.de
Technisch können solche Strukturen sinnvoll sein.
Sie erhöhen allerdings die infrastrukturelle Trennung.
Für einfache Wissensbereiche ist deshalb häufig ein Unterverzeichnis leichter:
example.de/wissen/
statt:
wissen.example.de/
Das ist keine universelle SEO-Regel.
Es ist eine Architekturentscheidung über Betrieb, Organisation und Wartung.
Die URL sollte keine Nutzerzustände enthalten
Ein Besucher loggt sich ein.
Nun entsteht:
/artikel?user=4711
Ein anderer:
/artikel?user=8292
Wenn der Inhalt öffentlich grundsätzlich derselbe ist, entstehen dadurch unnötig viele Adressen.
Noch problematischer wären personenbezogene oder sensible Informationen in URLs.
URLs können in:
Browserhistorien,
Logs,
Analytics,
Referrern,
Screenshots
oder geteilten Nachrichten
auftauchen.
Daten, die nicht in eine öffentliche Adresse gehören, sollten dort auch nicht landen.
Trackingparameter dürfen genutzt werden – aber bewusst
Ein Newsletterlink kann lauten:
/wissen/caching/?utm_source=newsletter&utm_campaign=august
Damit lässt sich Kampagnentraffic analysieren.
Der Inhalt bleibt jedoch:
/wissen/caching/
Eine solche Tracking-URL ist ein Transport- und Messwerkzeug.
Sie sollte nicht zur neuen redaktionellen Hauptadresse werden.
Die kanonische URL und internen Links sollten weiterhin auf die saubere Hauptversion zeigen.
Interne Links brauchen normalerweise keine Kampagnenparameter
Ein typischer Fehler wäre:
Startseite
↓
/wissen/caching/?utm_source=startseite
und aus einem Artikel:
/wissen/caching/?utm_source=artikel
Damit produziert die eigene Website selbst ständig zusätzliche URL-Varianten.
Interne Navigation kann mit Analytics-Ereignissen oder anderen internen Methoden ausgewertet werden.
Externe Kampagnenparameter gehören nicht zwangsläufig in das interne Linknetz.
URLs sollten keine unnötigen Sortierungen dauerhaft verlinken
Ein Shop besitzt:
/produkte?sort=preis
/produkte?sort=neu
/produkte?sort=beliebt
Wenn alle diese URLs großflächig intern verlinkt werden, entstehen für Crawler viele zusätzliche Wege zu weitgehend denselben Listen.
Google nennt Sortierparameter ausdrücklich als möglichen Auslöser unnötig vieler URLs. (Google for Developers)
Die Nutzerfunktion kann weiterhin existieren.
Die Crawl- und Indexierungsarchitektur sollte aber bewusst geplant werden.
Suchergebnisse erzeugen ebenfalls schnell viele URLs
Eine interne Suche könnte beispielsweise produzieren:
/suche?q=wordpress
/suche?q=dns
/suche?q=hosting
Theoretisch gibt es damit unendlich viele mögliche Suchbegriffe und URLs.
Genau solche dynamischen Such-URLs nennt Google als Bereich, bei dem unnötiges Crawling begrenzt werden kann. (Google for Developers)
WordPress behandelt seine eigenen Suchergebnisse zudem standardmäßig als nicht für den Suchindex vorgesehene Seiten, wie wir bereits beim noindex-Thema gesehen haben.
URL-Struktur und Indexierungsstrategie greifen hier ineinander.
Eine Sitemap sollte nur die bevorzugten URLs enthalten
Wenn eine Website besitzt:
/artikel/
/artikel?utm_source=a
/artikel?utm_source=b
sollte die Sitemap normalerweise nicht sämtliche Varianten auflisten.
Die Sitemap bildet den bevorzugten indexierbaren Bestand ab.
Damit passt sie zur Canonical-Strategie.
Google empfiehlt auch im E-Commerce-Kontext ausdrücklich, in internen Links, Sitemap und Canonical möglichst dieselbe URL-Version zu verwenden. (Google for Developers)
Das ist eine der stärksten Grundregeln unserer gesamten technischen SEO-Reihe:
Die Website sollte selbst eindeutig wissen, welche URL sie meint.
Canonical, Sitemap und interne Links sollten übereinstimmen
Ein idealer Artikel besitzt:
URL:
https://example.de/wissen/caching/
Canonical:
https://example.de/wissen/caching/
Sitemap:
https://example.de/wissen/caching/
interne Links:
https://example.de/wissen/caching/
Das ist langweilig.
Und genau deshalb gut.
Keine zweite Domain.
Keine zufälligen Parameter.
Keine HTTP-Variante.
Keine alternative Großschreibung.
Keine Redirect-Zwischenstufe.
Je eindeutiger die URL-Struktur ist, desto weniger muss Google später deduplizieren.
Gute URL-Struktur reduziert den Bedarf an Canonicals
Canonical-Tags bleiben sinnvoll.
Aber je weniger technische Duplikate eine Website erzeugt, desto weniger muss Canonicalisierung reparieren.
Wenn der Server nur eine Hauptvariante ausliefert und interne Systeme dieselbe Adresse verwenden, entsteht wesentlich weniger Mehrdeutigkeit.
Die beste Duplicate-Content-Lösung ist oft:
unnötige Duplikate gar nicht erst erzeugen.
Gute URL-Struktur reduziert auch Redirect-Arbeit
Wenn ein Wissensartikel von Anfang an heißt:
/wissen/webhosting/
kann der Titel zehnmal geändert werden.
Die Kategorie kann wechseln.
Das Theme kann wechseln.
WordPress kann später ersetzt werden.
Die Adresse bleibt.
Jede vermiedene URL-Änderung bedeutet:
keinen Redirect,
keine Sitemap-Migration,
keine Linkkorrekturen,
keine Canonical-Anpassung.
Stabilität spart technische Schulden.
Die perfekte URL muss deshalb nicht „maximal SEO“ sein
Ein häufiger Fehler besteht darin, eine URL wie eine zweite Meta-Description zu behandeln.
Beispielsweise:
/wordpress-webseite-schneller-machen-performance-optimieren-tipps/
Damit sollen möglichst viele Suchbegriffe abgedeckt werden.
Das Ergebnis ist eine lange, schwer wartbare Adresse.
Google empfiehlt verständliche, einfache, beschreibende URLs. (Google for Developers)
Ein treffender Begriff reicht häufig:
/wordpress-performance/
Der eigentliche Inhalt erklärt den Rest.
Der URL-Slug muss nicht jede semantische Variante enthalten
Ein Artikel kann für Suchanfragen erscheinen wie:
wordpress schneller machen
wordpress performance optimieren
wordpress geschwindigkeit verbessern
wordpress speed optimieren
Daraus folgt nicht, dass die URL lauten sollte:
/wordpress-schneller-machen-performance-speed-optimieren/
Die URL identifiziert das Thema.
Suchmaschinen verstehen Seiten nicht ausschließlich anhand der Zeichen im Pfad.
Titel, Inhalt, Links und weitere Seitensignale liefern wesentlich mehr Kontext.
Bestehende URLs sollte man nicht wegen Keyword-Recherche umbenennen
Angenommen:
/wissen/webanalyse/
besteht bereits.
Neue Keywordanalyse zeigt:
website analyse
besitzt höheres Suchvolumen.
Daraus sollte nicht automatisch werden:
/wissen/website-analyse/
Der Artikel kann:
Überschriften,
Inhalt,
Title
und interne Verlinkung
an tatsächliche Nutzerfragen anpassen.
Die bestehende Adresse kann trotzdem stabil bleiben.
SEO-Optimierung bedeutet nicht URL-Roulette.
URL-Stabilität ist besonders für Evergreen-Content wertvoll
Ein guter Grundlagenartikel kann zehn oder zwanzig Jahre leben.
Er wird aktualisiert.
Neue Beispiele kommen hinzu.
Alte Abschnitte verschwinden.
Vielleicht wechselt sogar der Betreiber.
Eine dauerhafte URL ermöglicht, dass:
alte Backlinks,
Lesezeichen,
Literaturverweise,
Forenlinks,
Newsletter
weiter funktionieren.
Das ist ein enormer Wert, der in kurzfristigen SEO-Checklisten oft unterschätzt wird.
Ein alter Slug darf ein wenig historisch wirken
Angenommen, ein Artikel hieß ursprünglich:
Homepage schneller machen
und besitzt:
/homepage-schneller/
Heute spricht die Website im Text konsequent von „Website“.
Muss deshalb die URL geändert werden?
Nicht zwingend.
Wenn sie weiterhin verständlich ist und der Inhalt passt, kann der historische Slug bestehen bleiben.
Eine URL muss nicht sprachlich perfekt mit jeder redaktionellen Modernisierung Schritt halten.
Sie muss eindeutig bleiben.
Nur wirklich falsche URLs verdienen eine Migration
Beispielsweise:
/wissen/dns/
enthält plötzlich ausschließlich einen Artikel über WordPress-Plugins.
Dann stimmt die Adresse nicht mehr mit dem Inhalt überein.
Oder ein versehentlich veröffentlichter Slug lautet:
/neuer-beitrag-73/
und wurde gerade erst publiziert.
Hier kann eine frühe Korrektur sinnvoll sein.
Die Kosten einer URL-Änderung wachsen typischerweise mit der Zeit, weil immer mehr Systeme die alte Adresse kennenlernen.
Vor Veröffentlichung lohnt deshalb ein kurzer URL-Check
Bei einem neuen Artikel sollte vor dem Veröffentlichen geprüft werden:
Passt der Slug dauerhaft zum Thema?
Enthält er unnötige Jahreszahlen?
Enthält er eine flüchtige Anzahl?
Ist er verständlich?
Ist er konsistent geschrieben?
Existiert bereits eine andere Seite unter einem sehr ähnlichen Slug?
Ist die URL der richtigen Inhaltsart zugeordnet?
Diese Minute Planung kann Jahre spätere Migration verhindern.
Ein Wissensportal sollte URL-Regeln dokumentieren
Für Casiopeya könnte die Regel beispielsweise lauten:
Wissensartikel:
/wissen/<slug>/
Magazin:
/magazin/<slug>/
Slugs:
klein geschrieben
deutsche Begriffe
Wörter mit Bindestrich getrennt
keine Jahreszahl bei Evergreen
keine Kategorie im Artikelpfad
keine unnötigen Parameter
Damit entscheidet nicht jeder Autor neu.
Eine redaktionelle URL-Konvention verhindert Wildwuchs.
Solche Regeln helfen besonders bei Automatisierung
Wenn Inhalte automatisch vorbereitet werden, sollte das System ebenfalls wissen:
Wie entsteht der Slug?
Welche Zeichen werden ersetzt?
Wie werden Umlaute behandelt?
Wie lang darf er sinnvoll werden?
Welche bestehenden Slugs sind bereits belegt?
Wann darf eine URL nach Veröffentlichung noch verändert werden?
Automatisierung ohne solche Regeln erzeugt schnell inkonsistente Adressen.
Slugs sollten auf Kollisionen geprüft werden
Zwei Seiten können nicht sinnvoll gleichzeitig dieselbe öffentliche URL besitzen.
WordPress sorgt technisch dafür, dass Slugs innerhalb der relevanten Strukturen eindeutig bleiben und kann bei Konflikten Varianten erzeugen.
Dann entstehen beispielsweise:
/caching/
/caching-2/
-2 ist ein Warnsignal dafür, dass möglicherweise bereits ein Inhalt mit demselben Namen existiert.
Vor Veröffentlichung sollte man dann nicht einfach akzeptieren:
/caching-2/
sondern prüfen:
Was ist /caching/?
Brauchen wir wirklich eine zweite Seite?
Eine Slug-Kollision kann ein Content-Architekturproblem sichtbar machen
Vielleicht soll ein neuer Artikel heißen:
Caching einfach erklärt
und WordPress erzeugt:
/caching-2/
weil bereits:
/caching/
existiert.
Das ist keine lästige technische Einschränkung.
Es ist möglicherweise ein wertvoller Hinweis:
Wir haben dieses Thema bereits.
Dann sollte geprüft werden, ob:
der alte Artikel aktualisiert,
der neue anders positioniert
oder beide zusammengeführt
werden sollten.
URL-Planung kann damit sogar Redaktionsduplikate verhindern.
Alte Entwürfe können Slugs ebenfalls blockieren
Manchmal existiert ein Inhalt:
im Papierkorb,
als Entwurf,
in einer alten Seitenstruktur.
Dann kann WordPress einen erwarteten Slug nicht wie gewünscht verwenden.
Bevor deshalb irgendein:
-2
-3
-neu
-final
akzeptiert wird, lohnt ein Blick auf die vorhandenen Inhalte.
Professionelle URLs sollten nicht aussehen wie Dateinamen auf einem chaotischen Desktop.
„final“, „neu“ und „v2“ gehören selten in öffentliche URLs
Beispiele:
/wordpress-guide-neu/
/wordpress-guide-final/
/wordpress-guide-v2/
sind meist Zeichen interner Arbeitslogik.
Für Besucher gibt es hoffentlich genau einen aktuellen Artikel.
Die Versionierung findet im Content-Management statt.
Die öffentliche URL bleibt beispielsweise:
/wordpress-guide/
Das ist ein weiteres Beispiel dafür, dass URLs Inhalte identifizieren und nicht den Produktionsprozess dokumentieren sollten.
Produkt- und Modellnummern können dagegen wichtig sein
Bei technischen Produkten kann eine Modellbezeichnung dauerhaft zur Identität gehören.
Beispielsweise:
/test/galaxy-tab-s8-plus/
Hier ist „s8-plus“ keine willkürliche technische ID.
Es ist der Produktname.
Solche Begriffe gehören natürlich in die URL, wenn der Inhalt genau dieses Modell behandelt.
Wieder entscheidet Bedeutung statt einer starren „keine Zahlen“-Regel.
Eine URL sollte nicht unnötig von der Datenbankstruktur abhängen
Eine Datenbank kann intern besitzen:
category_id=17
post_id=728
author_id=44
Diese Identifikatoren müssen nicht zwangsläufig Bestandteil der öffentlichen Adresse werden.
Ein Mensch braucht sie nicht.
Wenn das CMS sie intern benötigt, kann es sie intern verwenden.
Die öffentliche URL kann weiterhin verständlich bleiben.
Genau diese Trennung zwischen interner Technik und öffentlicher Informationsarchitektur macht Systeme langfristig flexibler.
WordPress-Permalinks sollte man früh festlegen
Die Permalink-Einstellung befindet sich in WordPress unter:
Einstellungen
→ Permalinks
Dort können Standard- oder benutzerdefinierte Strukturen ausgewählt werden. (WordPress.org)
Der ideale Zeitpunkt dafür ist:
vor dem Aufbau größerer Contentbestände.
Denn eine spätere Änderung kann die URLs vieler Beiträge gleichzeitig verändern.
Ein Permalink-Wechsel bei 500 Artikeln ist eine Migration
Angenommen, bisher:
/2024/05/mein-artikel/
und künftig:
/mein-artikel/
Dann ändern sich möglicherweise hunderte Adressen auf einmal.
Dafür benötigt man:
vollständige alte URL-Liste,
neue URL-Liste,
Redirect-Mapping,
Tests,
Sitemap-Anpassung,
Canonical-Kontrolle,
interne Linkkontrolle.
Das ist kein harmloser WordPress-Schalter mehr.
Es ist ein Website-Relaunch auf URL-Ebene.
„Post name“ ist keine universelle Pflicht
Die WordPress-Dokumentation bietet verschiedene Permalink-Strukturen, weil Websites unterschiedliche Aufgaben besitzen. (WordPress.org)
Ein Newsportal kann Datumsstrukturen bewusst verwenden.
Ein Forum könnte IDs benötigen.
Ein Shop besitzt eigene Produktstrukturen.
Ein Wissensportal kann einen stabilen Inhaltspräfix bevorzugen.
Die richtige Permalink-Struktur entsteht aus:
Inhaltstyp,
Langfristigkeit,
Technik,
Informationsarchitektur.
Nicht aus einem universellen Screenshot eines SEO-Tutorials.
Für Casiopeya ist die aktuelle Lösung bewusst einfach
Unsere Wissensartikel liegen unter:
/wissen/<slug>/
Damit erkennen Menschen sofort:
Das ist ein Wissensartikel.
Der individuelle Slug beschreibt das konkrete Thema.
Beispiele:
/wissen/was-ist-dns/
/wissen/wordpress-performance/
/wissen/google-search-console/
/wissen/url-struktur/
Die feinere fachliche Zuordnung zu:
Web & WordPress
SEO & Analyse
Performance
erfolgt über die Seitenarchitektur und interne Verlinkung.
Dadurch bleiben Artikeladressen auch bei einer späteren redaktionellen Umstrukturierung stabil.
Das Magazin darf eine parallele URL-Welt bilden
Magazinbeiträge könnten entsprechend unter:
/magazin/<slug>/
liegen.
Damit unterscheiden sich zwei Inhaltsarten bereits strukturell:
/wissen/
→ systematisches Evergreen-Wissen
/magazin/
→ aktuelle Beiträge, Tests, Entwicklungen, Meinung
Das ist eine URL-Ebene mit dauerhafter fachlicher Bedeutung.
Sie beschreibt nicht irgendeine temporäre WordPress-Kategorie.
Sie beschreibt den Seitentyp.
Genau solche stabilen Unterschiede eignen sich gut für URL-Strukturen.
URL-Struktur und Navigation dürfen sich unterschiedlich entwickeln
Vielleicht besitzt Casiopeya später im Wissensbereich zwanzig Themencluster.
Die URLs müssen deshalb nicht zwanzig zusätzliche Verzeichnisse erhalten.
Wir können die Navigation komplett neu organisieren:
Web & WordPress
→ Websites
→ WordPress
→ Hosting
→ Performance
→ SEO
ohne:
/wissen/was-ist-dns/
zu verändern.
Das ist langfristig ein enormer Vorteil.
Die Adresse eines Inhalts sollte idealerweise seine stabilste Eigenschaft enthalten
Das ist eine gute allgemeine Planungsregel.
Instabil sind häufig:
Veröffentlichungsdatum.
aktuelle Kategorie.
Anzahl der Tipps.
aktueller Marketingtitel.
Versionsnummer des Textes.
Stabil ist meist:
das eigentliche Thema.
Deshalb sind URLs wie:
/wissen/caching/
so robust.
Solange der Inhalt weiterhin Caching erklärt, passt die Adresse.
URLs sollten schon vor der Skalierung getestet werden
Eine problematische URL-Struktur bei 20 Seiten lässt sich relativ leicht ändern.
Bei:
20.000 Produkten,
100.000 Filtervarianten,
50 Sprachversionen
wird dieselbe Entscheidung extrem teuer.
Gerade dynamische Systeme sollten deshalb vor dem Launch Testfälle durchspielen:
Welche URL entsteht beim Filtern?
Wie sieht Pagination aus?
Was passiert mit leeren Kategorien?
Werden Parameter sortiert?
Kann dieselbe Seite über mehrere Pfade erreicht werden?
Welches Canonical entsteht?
Was steht in der Sitemap?
Gute URL-Architektur wird geplant, bevor Crawler ihre Probleme entdecken.
Eine saubere URL-Struktur hilft auch bei der Analyse
Angenommen, alle Wissensartikel beginnen mit:
/wissen/
und alle Magazinbeiträge mit:
/magazin/
Dann lassen sich in:
Search Console,
Webanalyse,
Serverlogs
diese Bereiche einfacher segmentieren.
Man kann beispielsweise untersuchen:
Traffic /wissen/
gegen
Traffic /magazin/
Eine verständliche URL-Architektur ist deshalb auch für Datenanalyse praktisch.
Sie bildet sinnvolle Inhaltsgruppen bereits technisch ab.
Zu viele Ebenen machen auch Analysen unübersichtlich
Ein Pfad wie:
/content/type/article/category/web/subcategory/seo/year/2026/url-struktur/
trägt sehr viele Informationen.
Aber viele davon ändern sich möglicherweise.
Außerdem macht er einfache Auswertungen unnötig kompliziert.
Die beste Struktur enthält nur diejenigen Ebenen, die tatsächlich dauerhaft und nützlich sind.
Gute URLs funktionieren auch ohne Suchmaschine
Das ist vielleicht der beste Qualitätstest.
Angenommen, Google würde morgen verschwinden.
Ist:
/wissen/url-struktur/
weiterhin eine gute Adresse?
Ja.
Sie ist:
verständlich,
teilbar,
merkbar,
technisch stabil.
Genau deshalb ist sie auch für SEO gut geeignet.
Viele nachhaltige SEO-Grundsätze sind letztlich gute Webarchitektur.
Eine URL sollte Menschen nicht überraschen
Jemand klickt auf:
/wissen/wordpress-backup/
und erwartet einen Artikel über WordPress-Backups.
Wenn dort stattdessen ein Kreditvergleich erscheint, ist nicht die URL das Hauptproblem.
Aber die Diskrepanz zeigt:
Adresse und Ressource gehören semantisch zusammen.
Dasselbe Prinzip hilft Suchmaschinen, Inhalte logisch einzuordnen.
Google empfiehlt deshalb verständliche beschreibende Wörter in URL-Pfaden. (Google for Developers)
URLs sollten bei Relaunches bewusst inventarisiert werden
Eine etablierte Website besitzt möglicherweise tausende alte Adressen.
Vor einem Relaunch sollte man sie nicht als unwichtige technische Altlast betrachten.
Jede kann besitzen:
Google-Sichtbarkeit,
Backlinks,
Lesezeichen,
interne Links,
historischen Traffic.
Eine URL-Inventur gehört deshalb vor einen größeren Umbau.
Anschließend wird für jede alte Adresse entschieden:
bleibt identisch,
wird weitergeleitet,
entfällt mit 404/410.
Genau hier verbindet sich URL-Architektur mit unserem Artikel über 301-Weiterleitungen.
Eine gute neue Website sollte möglichst wenig Redirects benötigen
Redirects sind wichtig.
Aber eine Website, die bereits am ersten Tag jede zweite URL umleitet, wurde wahrscheinlich unnötig kompliziert geplant.
Idealerweise lautet der Normalzustand:
angeforderte kanonische URL
↓
200 OK
Redirects werden hauptsächlich benötigt für:
historische Adressen,
Migrationen,
alternative Hostvarianten,
HTTP → HTTPS,
echte dauerhafte Umzüge.
Sie sollten nicht die Grundlage normaler Navigation bilden.
Auch Canonical-Tags sollten keine chaotische URL-Struktur rechtfertigen
Ein Entwickler könnte sagen:
Wir erzeugen einfach 100 Varianten pro Seite und setzen überall Canonical.
Google kann Canonicalisierung verwenden.
Aber jede zusätzliche URL kann zunächst entdeckt und unter Umständen gecrawlt werden. Google empfiehlt ausdrücklich, die Zahl alternativer URLs mit demselben Inhalt möglichst klein zu halten. (Google for Developers)
Canonical ist ein wichtiges Werkzeug.
Es ist kein Freibrief für unbegrenzte Duplikaterzeugung.
URL-Architektur ist deshalb Prävention
Unsere vorherigen Artikel beschäftigten sich häufig mit Reparatur:
Canonical gegen Duplikate.
301 bei Umzügen.
robots.txt bei Crawlsteuerung.
noindex bei unerwünschter Indexierung.
Indexierungsdiagnose bei Problemen.
Gute URL-Planung setzt davor an:
weniger unnötige URLs
↓
weniger Duplikate
↓
weniger Canonical-Konflikte
↓
weniger Redirects
↓
weniger Crawlingprobleme
↓
einfachere Analyse
Das ist wesentlich effizienter als spätere technische Korrektur.
Ein guter Standard für neue WordPress-Wissensseiten
Für einen neuen Evergreen-Artikel kann die Zielvorstellung sehr einfach sein:
https://example.de/wissen/thema/
Dabei:
https
→ sichere Hauptvariante
example.de
→ eindeutiger Host
wissen
→ stabiler Inhaltstyp
thema
→ kurzer, verständlicher, dauerhafter Slug
/
→ konsistent verwendete URL-Form
Der Artikel liefert:
200 OK
Das Canonical zeigt auf sich selbst.
Die Sitemap enthält diese URL.
Interne Links verwenden diese URL.
Andere Varianten werden gegebenenfalls sauber weitergeleitet oder kanonisiert.
Mehr braucht ein normaler Wissensartikel technisch häufig nicht.
Ein schlechterer Standard erzeugt schon vor dem ersten Besucher Arbeit
Beispielsweise:
http://www.example.de/2026/category/web/seo/article.php?id=1937&utm_internal=startseite
und zusätzlich funktionieren:
https://example.de/article.php?id=1937
https://www.example.de/article.php?id=1937
https://example.de/2026/category/web/seo/article.php?id=1937
Nun benötigen wir:
HTTPS-Redirects,
Host-Redirects,
Canonicalisierung,
Parameterbereinigung,
möglicherweise weitere Regeln.
Der Inhalt selbst ist noch derselbe.
Nur die Adressarchitektur erzeugt Komplexität.
Gute URLs sind langweilig – und das ist ein Kompliment
Die beste URL erzeugt normalerweise keine Diskussion.
Man sieht:
/wissen/url-struktur/
und versteht sie.
Sie bleibt jahrelang bestehen.
Kein SEO-Tool schlägt jedes Quartal eine andere Form vor.
Kein Redakteur muss sich an einen komplexen Parameter erinnern.
Kein Entwickler braucht eine Sonderregel.
Genau diese Unspektakulärität ist gute Infrastruktur.
Was du dir über URL-Strukturen merken solltest
URLs sind dauerhafte Adressen von Ressourcen und sollten deshalb langfristiger geplant werden als Überschriften oder Kategorien. WordPress bezeichnet seine Inhaltsadressen entsprechend als Permalinks und empfiehlt, sie möglichst dauerhaft beizubehalten. (WordPress.org)
Google empfiehlt eine einfache, logisch verständliche URL-Struktur mit beschreibenden Wörtern in der Sprache der Zielgruppe. Bindestriche sind für die Worttrennung die bevorzugte Form; unnötige Parameter sollten möglichst vermieden und Groß-/Kleinschreibung konsistent behandelt werden. (Google for Developers)
Ein guter Slug beschreibt vor allem das dauerhafte Thema einer Seite.
Deshalb ist:
/wordpress-performance/
für einen langfristigen Ratgeber häufig robuster als:
/7-beste-wordpress-speed-tipps-2026/
Die URL muss nicht die komplette Navigationshierarchie enthalten.
Ein Artikel unter:
/wissen/caching/
kann redaktionell trotzdem zu:
Web & WordPress
→ Performance
gehören.
Kategorien, Breadcrumbs und interne Links können diese Beziehung abbilden, ohne dass ein späterer Kategorienwechsel zwangsläufig die Adresse verändert.
WordPress unterstützt verschiedene Permalink-Strukturen, darunter Postname, Datumsstrukturen, numerische URLs und individuelle Strukturen mit Platzhaltern wie %postname%, %category% und %year%. (WordPress.org)
Query-Parameter sind nicht grundsätzlich problematisch. Unnötige Referral-, Sortier-, Session- und Filterparameter können allerdings sehr große Mengen zusätzlicher URLs erzeugen. Google empfiehlt deshalb, die Zahl unnötiger Parameter klein zu halten und insbesondere Session-IDs nach Möglichkeit nicht in URLs zu verwenden. (Google for Developers)
Fragmente mit # können hervorragend als Sprungmarken innerhalb eines Dokuments dienen, sollten aber nicht verwendet werden, um unterschiedliche eigenständige Seiteninhalte zu simulieren. (Google for Developers)
Vor allem aber gilt:
gute URL
=
verständlich
+
eindeutig
+
dauerhaft
Nicht:
gute URL
=
möglichst viele Keywords
Die beste URL ist diejenige, die ein Inhalt viele Jahre behalten kann.