Routing in PHP: verständliche Adressen und korrekte Antworten

Eine verständliche Adresse ist ein dauerhaftes Versprechen: Unter diesem Pfad finden Menschen einen bestimmten Inhalt oder eine klar beschriebene Funktion. Routing entscheidet, welche Anwendung dieses Versprechen erfüllt. Ein hübscher Slug allein reicht dafür nicht. Anfragepfad, HTTP-Methode, vorhandener Inhalt und Antwortstatus müssen zusammenpassen. Dieser Leitfaden entwickelt dafür eine kleine PHP-Lösung und zeigt, welche Entscheidungen beim Ausbau einer Unternehmenswebseite bewusst getroffen werden sollten.

Was Routing tatsächlich entscheidet

Routing ordnet einer Anfrage einen zuständigen Programmteil zu. Bei einer öffentlichen Leistungsseite kann dieser Teil Inhalt aus einer Redaktion laden und HTML erzeugen. Bei einer Schnittstelle kann er strukturierte Daten zurückgeben. Bei einem unbekannten Pfad sollte er einen nachvollziehbaren Fehler liefern. Der Router selbst muss dafür keine Texte verwalten und keine Datenbankabfragen zusammensetzen. Seine wichtigste Aufgabe ist die eindeutige Zuordnung.

Trennen Sie deshalb drei Fragen: Welche Adresse wurde angefragt? Welche Aktion ist mit der Methode gemeint? Existiert der angeforderte Inhalt tatsächlich und darf er ausgegeben werden? Eine passende Routenregel beantwortet zunächst nur die erste oder die ersten beiden Fragen. Eine Artikelroute kann syntaktisch passen, obwohl ihr Slug keinem veröffentlichten Artikel entspricht. Diese Unterscheidung verhindert, dass jede beliebige Zeichenfolge eine scheinbar erfolgreiche Seite erhält.

Für eine kleine Präsenz genügt häufig eine explizite Liste. Ein allgemeines Muster ist erst dann sinnvoll, wenn mehrere Inhalte wirklich dasselbe Verhalten teilen. Drei feste Informationsseiten brauchen keinen universellen Ausdruck, der aus beliebigen Pfaden automatisch PHP-Dateinamen konstruiert.

Pfad, Query und Fragment sauber auseinanderhalten

Die Bestandteile einer URI haben unterschiedliche Aufgaben. Im Beispiel /leistungen?bereich=pflege#ablauf bezeichnet der Pfad die Leistungsseite. Die Query enthält eine zusätzliche Auswahl. Das Fragment beschreibt ein Ziel innerhalb der Darstellung und wird bei einer normalen Browsernavigation nicht als Fragment an den HTTP-Server übertragen. Diese Trennung ist in RFC 3986 beschrieben.

Entscheiden Sie für jeden Query-Parameter, ob er den Inhalt verändert. Ein Suchbegriff gehört zur Suchfunktion. Ein Kampagnenparameter dokumentiert möglicherweise nur die Herkunft. Eine Seitennummer verändert die angezeigte Ergebnisgruppe. Werden alle Parameter gleich behandelt, entstehen unnötige Varianten oder verlorene Zustände. Die hier verwendeten Informationsseiten ignorieren die Query bewusst, weil sie keine solche Funktion besitzen.

Das PHP-Handbuch warnt ausdrücklich davor, parse_url() mit vollständiger URL-Validierung gleichzusetzen. Zerlegen und prüfen sind unterschiedliche Schritte. Unser enger Lernrouter verarbeitet den üblichen pfadbasierten Request-Target und trennt dafür zuerst am Fragezeichen. Eine allgemeine Proxy- oder URL-Bibliothek ersetzt diese einfache Entscheidung nicht.

Adressen aus Nutzeraufgaben entwickeln

Beginnen Sie mit einer kleinen Adressliste neben der Inhaltsplanung. Für jede Zeile notieren Sie die Aufgabe, den Seitentyp, die bevorzugte Adresse und den verantwortlichen Inhalt. Eine Reparaturleistung benötigt möglicherweise eine eigene Seite, weil Menschen genau danach suchen. Die interne Zuständigkeit eines Mitarbeiters ist dagegen selten ein sinnvoller Pfadbestandteil. Organisationsänderungen sollten nicht automatisch sämtliche öffentlichen Adressen verändern.

Verwenden Sie kurze verständliche Begriffe, die den Inhalt zuverlässig unterscheiden. Ein Slug muss keine vollständige Überschrift wiederholen. Fünf ähnliche Varianten für dieselbe Leistung sind auch dann unübersichtlich, wenn jede ein zusätzliches Suchwort enthält. Beschreiben Sie zuerst den fachlichen Unterschied der Seiten. Erst danach entscheiden Sie, ob wirklich mehrere Adressen nötig sind.

Googles Empfehlungen zur URL-Struktur behandeln unter anderem verständliche Wörter, Bindestriche als Worttrenner und unnötige Parameterkombinationen. Daraus folgt keine garantierte Platzierung. Für unser Projekt ist die praktische Konsequenz eine dokumentierte Benennungsregel, die Redaktion und Entwicklung gleichermaßen verwenden können.

Eine kleine Routenvereinbarung aufschreiben

Diese Tabelle ist eine Vereinbarung für unsere Beispielanwendung. Sie lässt sich vor der Programmierung fachlich besprechen. Besonders wichtig ist die Kontaktseite: Ihr Name bedeutet noch nicht, dass sie jede HTTP-Methode verarbeiten muss. Eine spätere Formularverarbeitung erhält eine eigene ausdrückliche Vereinbarung mit Validierung und tatsächlichem Versandverhalten.

Auch die Wahl ohne abschließenden Schrägstrich ist keine universelle Pflicht. Beide Konventionen können funktionieren. Entscheidend sind eine bevorzugte Form, konsistente interne Links und kontrollierte Weiterleitungen für bekannte Alternativen.

Der vollständige kleine PHP-Router

Der folgende Code trennt eine prüfbare Entscheidungsfunktion von der Ausgabe. Er liefert absichtlich Klartext statt eines vorgetäuschten vollständigen CMS. Eine Produktionsanwendung würde nach der Entscheidung ihre freigegebenen Vorlagen rendern. Feste interne Ziele verhindern hier, dass eine fremde Rücksprungadresse ungeprüft in einen Weiterleitungsheader gelangt.

<?php
declare(strict_types=1);

function route(string $method, string $target): array
{
    // Deliberately small ASCII policy for this public-page example.
    $path = explode('?', $target, 2)[0];
    if (!preg_match('~^/(?:[a-zA-Z0-9/-]*)$~D', $path)
        || str_contains($path, '//')) {
        return [400, [], 'Ungültiger Anfragepfad.'];
    }

    $pages = [
        '/' => 'Startseite',
        '/leistungen' => 'Leistungen',
        '/kontakt' => 'Kontaktinformationen',
    ];
    $aliases = ['/angebot' => '/leistungen'];
    $candidate = $path === '/' ? '/' : rtrim($path, '/');
    $destination = $aliases[$candidate] ?? $candidate;
    if (!array_key_exists($destination, $pages)) {
        return [404, [], 'Diese Seite wurde nicht gefunden.'];
    }
    if (!in_array($method, ['GET', 'HEAD'], true)) {
        return [405, ['Allow' => 'GET, HEAD'], 'Methode nicht erlaubt.'];
    }
    if ($path !== $destination) {
        // Fixed internal destinations; no user-supplied return URL.
        return [308, ['Location' => $destination], 'Adresse dauerhaft geändert.'];
    }
    return [200, [], $pages[$destination]];
}

$method = $_SERVER['REQUEST_METHOD'] ?? 'GET';
$target = $_SERVER['REQUEST_URI'] ?? '/';
[$status, $headers, $body] = route($method, $target);
http_response_code($status);
header('Content-Type: text/plain; charset=utf-8');
header('Cache-Control: no-store');
foreach ($headers as $name => $value) {
    header($name . ': ' . $value);
}
if ($method !== 'HEAD') {
    echo $body;
}

Die Antwort erhält einen expliziten Zeichensatz. Die Demo setzt außerdem no-store, damit während des Lernens keine dauerhafte Browserzwischenspeicherung die Beobachtungen verdeckt. Das ist keine pauschale Cache-Empfehlung für öffentliche Informationsseiten. Dort ist eine eigene Strategie mit Aktualisierung, Varianten und geeigneten Zwischenspeicherregeln nötig.

Warum die Prüfungen in dieser Reihenfolge stehen

Zuerst wird die im Beispiel erlaubte Pfadform geprüft. Prozentzeichen, Punkte, Rückstriche und wiederholte Schrägstriche werden dabei abgewiesen. Das begrenzt bewusst den Lernumfang. Ein internationalisiertes Redaktionssystem benötigt andere Regeln für Unicode, Prozentkodierung und die Abstimmung mit dem vorgeschalteten Server. Diese Fälle sollte man nicht nebenbei durch mehrfaches Dekodieren vermeintlich reparieren.

Danach wird nur für die bekannten Seiten ein mögliches Ziel bestimmt. Eine unbekannte Adresse bleibt unbekannt. Anschließend prüft die Funktion, ob GET oder HEAD vorliegt. Erst dann folgt gegebenenfalls die Weiterleitung. Dadurch leitet ein POST auf die alte Angebotsadresse in diesem Beispiel nicht versehentlich in eine andere Verarbeitung weiter. Die Anwendung akzeptiert solche schreibenden Anfragen dort überhaupt nicht.

Für einen API-Router kann eine andere fachliche Vereinbarung nötig sein. Entscheidend ist, dass die Reihenfolge aus dem gewünschten Verhalten folgt und durch konkrete Anfragen geprüft wird. Ein allgemein formulierter Kommentar wie „URLs bereinigen“ beschreibt diese Auswirkungen nicht ausreichend.

Weiterleiten, ohne neue Probleme zu erzeugen

Eine Weiterleitung benötigt ein tatsächlich passendes Ziel. Die alte Angebotsseite verweist im Beispiel auf die neue Leistungsseite, weil beide dieselbe inhaltliche Aufgabe erfüllen sollen. Eine entfernte Stellenanzeige auf die Startseite umzuleiten wäre eine andere Entscheidung: Besucher erhalten dort möglicherweise keine Antwort auf ihr Anliegen. Pflegen Sie Umzüge daher als inhaltliche Zuordnung und nicht als pauschalen technischen Ersatz für fehlende Inhalte.

Google unterscheidet in seiner Dokumentation zu Weiterleitungen dauerhafte und vorübergehende Signale. Stimmen Sie Umzugsart und technischen Status aufeinander ab. Eine zeitweilige Kampagnenseite sollte nicht allein deshalb als dauerhaft verschoben gelten, weil diese Einstellung in der Serveroberfläche zuerst angeboten wird.

Im Beispiel landen alte Adresse und bekannte Slash-Variante direkt am bevorzugten Ziel. Prüfen Sie bei einem echten Umzug die gesamte Kette einschließlich HTTPS, Hostnamen und Sprachpräfix. Mehrere einzeln richtige Regeln können zusammen einen unnötigen Umweg oder eine Schleife bilden. Halten Sie das endgültige Ziel zusätzlich in internen Links aktuell.

Methoden und Antwortstatus ernst nehmen

Der HTTP-Standard RFC 9110 beschreibt die Bedeutung von Methoden und Statuscodes. Für unseren Router sind vier Unterschiede zentral: Ein erfolgreicher Abruf erhält 200. Ein unbekannter Inhalt erhält 404. Eine für die bekannte Ressource nicht erlaubte Methode erhält 405 samt Allow-Header. Die gewählte dauerhafte Weiterleitung verwendet 308 und bewahrt die Methode.

HEAD liefert grundsätzlich keinen Antwortkörper. Im Beispiel verwendet die Entscheidung denselben Inhaltseintrag wie GET und unterdrückt anschließend die Ausgabe. Für größere Anwendungen muss diese Beziehung auch bei automatisch gesetzten Darstellungsheadern stimmen. Ein erfolgreicher HEAD-Test beweist außerdem noch nicht, dass der vollständige GET-Inhalt korrekt aufgebaut wird. Testen Sie beides.

GET darf in Ihrer Anwendung keine Bestellung auslösen oder ein Benutzerkonto löschen. Ein anklickbarer Link lässt sich vorab laden, wiederholen oder von einem Crawler verfolgen. Schreibende Funktionen benötigen passende Methoden und zusätzliche Schutzmaßnahmen. Die hier gezeigte Routenprüfung ist weder Anmeldung noch Berechtigungsprüfung und auch kein Schutzkonzept für Formulare.

Fehlerseiten gehören zur Inhaltsarchitektur

Eine hilfreiche Fehlerseite erklärt knapp, dass die angefragte Seite nicht gefunden wurde. Sie kann Navigation und eine vorhandene Suche anbieten. Sie sollte jedoch den passenden Fehlerstatus behalten. Eine hübsche Gestaltung mit 200 macht den fehlenden Inhalt technisch nicht erfolgreich. Google beschreibt solche Widersprüche und ihre Folgen in der Dokumentation zu HTTP-Statuscodes.

Vermeiden Sie eine automatische Sammlung beliebiger angeblich ähnlicher Seiten, wenn deren Relevanz nicht geprüft ist. Bei einer überschaubaren Unternehmenspräsenz helfen häufig die wichtigsten Leistungsbereiche und ein klarer Kontaktweg. Die Fehlerseite darf außerdem keine privaten internen Pfade, Konfigurationen oder detaillierten Fehlermeldungen des Servers offenlegen.

Beobachten Sie gehäuft auftretende unbekannte Pfade nach einem Relaunch. Ein einzelner Tippfehler erfordert selten eine neue Route. Viele Zugriffe auf denselben alten Link können dagegen auf eine vergessene Weiterleitung oder eine weiterhin falsche interne Verknüpfung hinweisen. Die eigentliche Korrektur liegt dann möglicherweise im Linkbestand.

Dynamische Inhalte von ihrer Adresse trennen

Bei einem Journal ist die Adresse eine öffentliche Kennung, während ein interner Datensatz zusätzlich eine stabile ID besitzt. Eine Titeländerung sollte nicht zwangsläufig den Datensatz oder alle Beziehungen verändern. Wenn sich der Slug tatsächlich ändern muss, kann die alte Kennung als ausdrücklich gespeicherter Alias bestehen bleiben. Überschreiben Sie nicht einfach den einzigen bekannten Wert und verlieren damit die Grundlage für eine gezielte Weiterleitung.

Eine dynamische Route darf erst nach einer Datenabfrage Erfolg melden. Dabei zählen Veröffentlichungsstatus und gegebenenfalls Sprache ebenso wie die Existenz des Datensatzes. Ein geplanter Artikel muss für die öffentliche Anfrage nicht dieselbe Antwort erhalten wie für eine berechtigt angemeldete Vorschau. Diese Entscheidung gehört in die zuständige Anwendungsschicht und darf nicht allein aus dem sichtbaren Slug abgeleitet werden.

Definieren Sie außerdem Konflikte zwischen festen und dynamischen Pfaden. Ein Artikel mit der Kennung „suche“ darf nicht unbemerkt die vorhandene Suchfunktion verdrängen. Reservierte Begriffe und eindeutige Routengruppen sind leichter zu erklären als zufällige Gewinner in einer langen Liste überlappender Muster.

Routing ist kein Dateisystemzugriff

Vermeiden Sie Konstruktionen, die Benutzereingaben unmittelbar an include oder an einen Dateipfad hängen. Der gewünschte öffentliche Begriff ist kein vertrauenswürdiger Vorlagenname. OWASP beschreibt Path Traversal als Zugriff außerhalb vorgesehener Verzeichnisse durch manipulierte Pfadangaben. Die sichere Architektur beginnt damit, diese unnötige Verbindung gar nicht herzustellen.

Unsere feste Liste enthält nur inhaltliche Antworten. In einem größeren Projekt kann eine geprüfte Route einen bekannten Controller oder eine feste Vorlagenkennung auswählen. Hochgeladene Dateien benötigen dagegen eine separate Ablage- und Auslieferungsstrategie. Ein Download-Endpunkt muss seine Berechtigung und die erlaubte Datei ausdrücklich prüfen, auch wenn sein URL-Muster sauber aussieht.

Die Funktion rawurldecode() wandelt Kodierungen um. Sie beantwortet nicht, ob das Ergebnis für eine Route oder einen Dateizugriff zulässig ist. Legen Sie vor der Implementierung fest, welche Schicht dekodiert und welche Darstellung geprüft wird. Unterschiedliche Interpretationen zwischen Proxy und Anwendung sind eine eigene Fehlerquelle.

Mehrsprachigkeit und bevorzugte Adressen abstimmen

Eine englische Fassung ist nicht automatisch eine doppelte deutsche Seite. Sie besitzt eigenen Text und möglicherweise einen übersetzten Slug. Verknüpfen Sie Sprachfassungen über eine stabile interne Beziehung. Ein Sprachwechsel sollte nach Möglichkeit zum entsprechenden Inhalt führen und nicht immer zur jeweiligen Startseite. Für fehlende Übersetzungen ist eine bewusste redaktionelle Regel besser als ein erfundenes Ziel.

Für tatsächlich gleiche Varianten erläutert Google mehrere Möglichkeiten zur Kennzeichnung einer bevorzugten URL. Stimmen Sie insbesondere interne Links, Sitemap und Canonical aufeinander ab. Ein Canonical ist kein Ersatz für eine fehlende Routenentscheidung und keine Zugangssperre. Unterschiedliche Inhalte sollten nicht aus Bequemlichkeit auf eine gemeinsame Adresse kanonisiert werden.

Denken Sie bei Query-Varianten an die Nutzeraufgabe zurück. Eine gefilterte Trefferliste kann einen sinnvoll teilbaren Zustand besitzen. Ein bloßer Herkunftsparameter braucht möglicherweise keinen eigenen indexierbaren Inhalt. Diese Einordnung sollte vor der massenhaften Erzeugung von Filterlinks feststehen.

Parameter bei einem Umzug bewusst behandeln

Die kleine Demo entfernt beim Weiterleiten die komplette Query. Aus /angebot?quelle=mail wird deshalb unmittelbar /leistungen. Das ist hier beabsichtigt: Keine der drei Seiten besitzt eine parameterabhängige Funktion. Die Regel darf jedoch nicht ungeprüft auf Suchseiten, Buchungsabläufe oder gefilterte Produktlisten übertragen werden. Dort könnte sie genau den Zustand verlieren, den ein Mensch teilen oder wieder aufrufen wollte.

Erstellen Sie für solche Anwendungen eine Liste der tatsächlich unterstützten Parameter. Prüfen Sie pro Eintrag, ob er beim Umzug erhalten, übersetzt oder verworfen werden soll. Bauen Sie die neue Query aus diesen geprüften Bestandteilen auf. Das bloße Anhängen aller ursprünglichen Zeichen erhält möglicherweise veraltete Schalter oder widersprüchliche Auswahlwerte. Ein Rücksprungziel verdient besondere Aufmerksamkeit, weil daraus keine beliebige Weiterleitung zu einer fremden Domain werden darf.

Auch eine vorgeschaltete Analyse oder ein Werbesystem kann die Entscheidung beeinflussen. Wenn Kampagnendaten benötigt werden, stimmen Sie den Umgang vor dem Umzug mit der zuständigen Stelle ab. Dokumentieren Sie anschließend die fachliche Erwartung und einen konkreten Prüffall. „Parameter bleiben erhalten“ ist erst dann eine brauchbare Aussage, wenn klar ist, welche Parameter gemeint sind und ob ihre Bedeutung am neuen Ziel noch dieselbe ist. Eine nachvollziehbare Ausnahmeliste ist hier wertvoller als eine möglichst allgemeine Regel.

Die Demo mit echten HTTP-Anfragen prüfen

Speichern Sie den Code als router.php und starten Sie in seinem Verzeichnis den integrierten PHP-Testserver mit php -S 127.0.0.1:8099 router.php. Er ist laut PHP-Dokumentation zum eingebauten Webserver ein Entwicklungswerkzeug. Für öffentliche Bereitstellung benötigen Sie eine geeignete Serverkonfiguration und müssen deren Rewrite-Verhalten gesondert prüfen.

curl -i http://127.0.0.1:8099/leistungen
curl -I http://127.0.0.1:8099/leistungen
curl -i http://127.0.0.1:8099/angebot
curl -i -X POST http://127.0.0.1:8099/kontakt
curl -i http://127.0.0.1:8099/unbekannt

Bei der Prüfung dieses Artikels wurden die beiden eingebetteten Sprachfassungen jeweils als PHP-Datei ausgeführt. Der Prüfablauf kontrolliert echte HTTP-Antworten einschließlich Location, Allow und leerem HEAD-Körper. Zusätzlich prüft er unbekannte Adressen, Query-Verhalten und bewusst abgewiesene Pfadformen. Das sind Funktionsprüfungen dieser kleinen Demo und keine Sicherheitszertifizierung eines produktiven Servers.

Eine Übergabematrix für den Relaunch

Testen Sie nicht ausschließlich die neue Navigation. Alte Favoriten, gedruckte QR-Codes, Suchergebnisse und externe Verweise beginnen an anderen Stellen. Eine Liste der wichtigsten Einstiegspunkte macht diese Abhängigkeiten sichtbar. Bewahren Sie die Zuordnung auch nach dem Veröffentlichungstag auf, damit spätere Änderungen nicht die gerade geretteten Adressen erneut beschädigen.

Checkliste vor der Veröffentlichung

• Jede öffentliche Adresse hat einen nachvollziehbaren Inhalt oder eine ausdrücklich definierte Funktion.
• Feste und dynamische Routen überschneiden sich nicht unbeabsichtigt.
• Die erlaubten Methoden sind je Funktion festgelegt.
• Unbekannte Inhalte liefern einen passenden Fehlerstatus.
• Alte wichtige Adressen besitzen geprüfte inhaltliche Ziele.
• Weiterleitungen führen ohne Schleife zur bevorzugten Adresse.
• Query-Parameter haben eine dokumentierte Bedeutung.
• Keine Benutzereingabe wird unmittelbar zum Vorlagen- oder Dateipfad.
• Interne Links, Canonical, Sprachen und Sitemap passen zusammen.
• Die tatsächliche Serverumgebung besteht dieselben wesentlichen HTTP-Prüfungen wie die Anwendung.

Häufige Fragen zur Routenplanung

Muss jede Adresse möglichst kurz sein? Verständlichkeit und Stabilität sind wichtiger als das letzte eingesparte Zeichen. Ein kurzer mehrdeutiger Begriff kann für Menschen schlechter funktionieren als eine etwas längere klare Bezeichnung. Entfernen Sie zuerst technische Zufälligkeiten und doppelte Bedeutungen.

Sollte jede unbekannte Adresse auf die Startseite führen? Eine Startseite ersetzt keinen beliebigen fehlenden Inhalt. Verwenden Sie eine gezielte Weiterleitung bei einem echten passenden Umzug. Für unbekannte Ziele ist eine hilfreiche Fehlerseite mit geeignetem Status die verlässlichere Grundlage.

Ist ein eigener Router immer besser als ein Framework? Die kleine Funktion macht Entscheidungen sichtbar. Ein bestehendes Framework bietet häufig bereits Routenauflösung und Methodenbehandlung. Nutzen Sie dessen geprüfte Mechanismen, wenn Ihr Projekt darauf aufgebaut ist. Übertragen Sie die fachlichen Regeln und Tests statt zusätzlich eine konkurrierende Zuständigkeit einzuführen.

Wann ist die Planung ausreichend? Wenn Redaktion und Entwicklung für einen neuen Inhalt dieselbe Adresse, dieselbe öffentliche Sichtbarkeit und dasselbe Verhalten bei einem späteren Umzug erwarten. Ein einzelnes funktionierendes Beispiel ist der Anfang. Ein gepflegter Vertrag zwischen Inhalt, Anfrage und Antwort macht daraus ein belastbares System.