Sie öffnen die Google Search Console und sehen die Startseite doppelt indexiert: als site.ru/ und als site.ru/index.php. Oder site.ru/index.html. Für eine Suchmaschine sind das zwei verschiedene URLs mit identischem Inhalt. Die Folge: Die Autorität der Seite verteilt sich zur Hälfte auf die Duplikate, die Rankings sinken und das Crawl-Budget wird verschwendet.

Das Problem ist so alt wie das Web. Die Mechanik ist einfach: Standardmäßig liefert der Server beim Aufruf der Root-Adresse über die DirectoryIndex-Direktive index.html oder index.php aus, unterbindet aber nicht den direkten Zugriff auf site.ru/index.php. Aus Sicht von Apache sind beide Adressen legitim. Die Suchmaschine hingegen sieht zwei verschiedene Seiten mit identischem Inhalt und beginnt zu raten, welche sie ranken soll.

Nachfolgend finden Sie drei Wege, um einen 301-Redirect von Index-Dateien auf die Root-Adresse einzurichten: vom universellen .htaccess über Cloudflare bis hin zu Nginx. Dazu eine Verifikationsmethode, die zwei Minuten dauert.

💡 Kurzüberblick:

• Fügen Sie mod_rewrite-Regeln in die .htaccess ein, um Anfragen auf index.html und index.php abzufangen
• Nutzen Sie für WordPress und CMS einen PHP-Redirect in der Einstiegs-index.php (er übersteht Permalink-Änderungen)
• Verifizieren Sie das Ergebnis per curl -I oder redirectchecker.com (die Antwort muss 301 Moved Permanently lauten)
• Gehen Sie die internen Links der Seite durch und ersetzen Sie /index.php in Menüs, Logos und Widgets durch /

Warum Duplikate von Index-Dateien Ihrer Seite schaden

Wenn ein Besucher site.ru in die Adresszeile eingibt, ersetzt Apache stillschweigend index.html oder index.php gemäß DirectoryIndex. Der Browser zeigt die Seite an, die Adresse bleibt sauber und der Nutzer bemerkt die Ersetzung nicht.

Existiert jedoch bereits irgendwo ein Link auf den vollständigen Pfad site.ru/index.php, folgt der Such-Crawler diesem, sieht denselben Inhalt wie unter site.ru/ und registriert ein Duplikat. Woher stammt ein solcher Link? Die Möglichkeiten sind vielfältig: ein alter Beitrag auf einer Drittseite, ein Partner, der die falsche URL angegeben hat, ein Social-Sharing-Plugin, das einen Share mit index.php im Anhang generiert hat, oder gar der Entwickler, der beim Layout href="/index.html" in die Navigation eingefügt hat.

Was wir in der Praxis beobachten:

• Geteilte Link-Power. Backlinks verteilen sich auf / und /index.php, anstatt sich auf einer einzigen kanonischen Seite zu sammeln.
• Verschwendetes Crawl-Budget. Der Bot verwendet Zeit auf das Crawlen von Duplikaten anstatt auf nützliche Bereiche der Seite.
• Verwässerte Relevanz. Die Suchmaschine versteht nicht, welche der beiden Seiten sie in den Ergebnissen anzeigen soll, und wechselt möglicherweise zwischen ihnen hin und her, Nutzerverhaltensstatistiken werden verzerrt und die Rankings werden instabil.

Die Situation ist vollständig beherrschbar. Gelöst wird sie durch die Einrichtung eines permanenten 301-Redirects von index.html und index.php auf die Root-Adresse /. Sehen wir uns die verfügbaren Methoden an.

Methode 1: Redirect per.htaccess auf Apache

Die Datei .htaccess befindet sich im Root-Verzeichnis der Seite. Existiert sie nicht, erstellen Sie eine Textdatei mit einem Punkt am Anfang des Namens; jeder FTP-Client oder Dateimanager des Hostings kann das.

Öffnen Sie die .htaccess und suchen Sie die Zeile RewriteEngine On. Ist sie nicht vorhanden, fügen Sie sie als allererste Zeile nach etwaigen Kommentaren ein. Sie aktiviert das Modul mod_rewrite, das für alle Redirects zuständig ist.

Fügen Sie unterhalb von RewriteEngine On die Regeln ein. Hier ein funktionsfähiger Minimalsatz:

1
RewriteEngine On
2
 
3
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/
4
RewriteRule ^index\.php$ https://%{HTTP_HOST}/ [R=301,L]
5
 
6
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.html\ HTTP/
7
RewriteRule ^index\.html$ https://%{HTTP_HOST}/ [R=301,L]

So funktioniert das Zeile für Zeile:

• RewriteCond %{THE_REQUEST} prüft die ursprüngliche, vom Browser an den Server gesendete Anfragezeichenkette. Diese enthält explizit /index.php oder /index.html, und genau das fangen wir ab.
• RewriteRule leitet die Anfrage mit einem 301-Code (permanenter Redirect) auf die Domain-Root um. Das L-Flag (last) beendet die weitere Regelverarbeitung.
• %{HTTP_HOST} setzt automatisch die Domain der Seite ein; Sie müssen sie nicht manuell eintippen. Das Protokoll wird explizit als https:// angegeben.

Kritischer Hinweis: Verwenden Sie nicht das vereinfachte Konstrukt Redirect 301 /index.php /. Die Redirect-Direktive von mod_alias erzeugt bei Index-Dateien eine Schleife. Nach der Weiterleitung auf / ersetzt Apache erneut index.php per DirectoryIndex, die Regel greift wieder und der Browser wirft einen Fehler wegen einer Endlosschleife. Die Kombination RewriteCond + RewriteRule über mod_rewrite analysiert gezielt die ursprüngliche Anfrage (%{THE_REQUEST}), nicht die durch interne Regeln umgeschriebene, sodass keine Schleife entsteht.

Änderungen in der .htaccess werden sofort wirksam; Apache liest die Datei bei jeder Anfrage neu ein, ein Server-Neustart ist nicht erforderlich.

Methode 2: PHP-Redirect für WordPress und CMS

Auf Seiten, die mit WordPress, Joomla, Drupal und anderen CMS laufen, ist die Bearbeitung der .htaccess riskant: Das CMS überschreibt sie bei der Aktualisierung von Permalinks, der Änderung der URL-Struktur oder der Aktivierung von SEO-Plugins. Ihre Regeln können beim nächsten Speichern der Einstellungen verschwinden.

Für WordPress gibt es einen widerstandsfähigeren Ansatz: einen Redirect direkt in der Einstiegsdatei index.php. Diese befindet sich im Installations-Root des CMS und wird bei jeder Anfrage ausgeführt, bevor der Kern geladen wird.

Öffnen Sie die WordPress-index.php und fügen Sie ganz am Anfang, direkt nach dem öffnenden <?php-Tag, Folgendes ein:

1
<?php
2
// 301 redirect from index.php to root
3
if ($_SERVER['REQUEST_URI'] === '/index.php') {
4
    header('Location: /', true, 301);
5
    exit();
6
}
7
 
8
// Standard WordPress code follows
9
define('WP_USE_THEMES', true);
10
// ...

Für Seiten auf reinem PHP ohne CMS gilt dieselbe Logik: Platzieren Sie den Code in der Einstiegs-index.php im Root des öffentlichen Verzeichnisses. Verwendet Ihre Seite beide Index-Dateien (index.php und index.html), fügen Sie eine analoge Prüfung für index.html am Anfang desselben Skripts hinzu.

Warum diese Methode für CMS zuverlässiger ist als die Bearbeitung der .htaccess:

• Der Code lebt innerhalb einer PHP-Datei, die das CMS bei der Aktualisierung der Permalink-Einstellungen nicht anfasst.
• Die Prüfung von $_SERVER['REQUEST_URI'] fängt gezielt die angefragte URL ab, nicht die von den internen WordPress-Regeln umgeschriebene.
• exit() garantiert den Abbruch der Ausführung; keine einzige Zeile danach wird ausgeführt.

Auf Projekten mit hohem Traffic ist der PHP-Redirect geringfügig schneller als die .htaccess-Variante: mod_rewrite muss nicht zum Parsen regulärer Ausdrücke anlaufen, was bei jeder Anfrage Millisekunden spart.

Methode 3: Cloudflare, Nginx und andere Server

Cloudflare. Läuft Ihre Seite über Cloudflare, können Sie den Redirect auf CDN-Ebene einrichten, ohne Server-Dateien anzufassen. Gehen Sie zu Rules → Redirect Rules und erstellen Sie eine Regel:

• Feld: URI Path
• Operator: equals
• Wert: /index.php
• Redirect-URL: https://yourdomain.com/
• Statuscode: 301

Fügen Sie eine analoge Regel für /index.html hinzu. Der Vorteil: Der Redirect greift auf den Edge-Servern von Cloudflare, die Anfrage erreicht Ihr Hosting gar nicht erst. Der Nachteil: Die Domain muss an die Cloudflare-NS delegiert sein.

Nginx. Seiten auf Nginx verwenden keine .htaccess. Regeln werden in der Server-Konfigurationsdatei hinterlegt, üblicherweise /etc/nginx/sites-available/yourdomain:

1
location = /index.php {
2
    return 301 https://yourdomain.com/;
3
}
4
 
5
location = /index.html {
6
    return 301 https://yourdomain.com/;
7
}

Prüfen Sie nach der Bearbeitung die Syntax mit nginx -t und wenden Sie die Änderungen an: systemctl reload nginx.

LiteSpeed / OpenLiteSpeed. Der Server unterstützt .htaccess mit denselben mod_rewrite-Regeln wie Apache; Methode 1 funktioniert ohne Änderungen. Zusätzlich können Sie den eingebauten Redirect-Mechanismus im LiteSpeed WebAdmin-Panel nutzen.

IIS (Windows Server). Für Seiten auf IIS wird der Redirect über das URL-Rewrite-Modul in der web.config konfiguriert:

1
<rule name="Redirect index.php to root" stopProcessing="true">
2
    <match url="^index\.php$" />
3
    <action type="Redirect" url="/" redirectType="Permanent" />
4
</rule>

Fügen Sie eine analoge Regel für index.html hinzu.

So verifizieren Sie, dass der Redirect funktioniert

Die zuverlässigste Methode ist die Kommandozeile. Führen Sie aus:

1
curl -I https://yourdomain.com/index.php

Die erste Zeile der Antwort muss HTTP/1.1 301 Moved Permanently lauten und der Location-Header die Root-Adresse der Seite zeigen. Wiederholen Sie dies für index.html. Die Startseite unter der Root-Adresse / muss mit dem Code 200 antworten.

Alternative Verifikationswerkzeuge:

• Redirect Checker (redirectchecker.com) zeigt die vollständige Redirect-Kette mit Antwortcodes an, praktisch für die schnelle Diagnose ohne Terminal.
• Google Search Console → URL-Prüfung (das Inspect-and-Test-Tool): Zeigt, wie Googlebot die Seite nach dem Redirect sieht und ob sie für die Indexierung verfügbar ist.

Nach Einrichtung des Redirects ist es entscheidend, die internen Links Ihrer Seite zu prüfen. Stellen Sie sicher, dass Menüs, das Logo (das üblicherweise auf die Startseite verlinkt), Breadcrumbs und Blöcke mit ähnlichen Beiträgen auf / verweisen, nicht auf /index.php. Ein einziger fehlerhafter interner Link kann das gerade entfernte Duplikat neu erzeugen. Führen Sie eine Quelltextsuche über die gesamte Seite durch: Öffnen Sie eine beliebige Seite, drücken Sie Strg+U und suchen Sie nach href="/index.php" oder href="/index.html". Ersetzen Sie jedes Vorkommen durch href="/".

Video: eine kurze Erklärung zu 301-Redirects von Google

Ein vierminütiges Video von Google Search Central, essenziell, wenn Sie Redirects zum ersten Mal einrichten. John Mueller erklärt, wie die Suchmaschine permanente Redirects verarbeitet und ob es eine Begrenzung ihrer Anzahl gibt:

⁉️🤔 Häufig gestellte Fragen

Was passiert, wenn ich gar keinen Redirect von index.php einrichte?

Die Suchmaschine wählt selbst eine kanonische Version, aber nicht unbedingt die, die Sie benötigen. Ein Teil der Link-Power geht an das Duplikat und beide URLs können in den Suchergebnissen alternieren. Eine direkte Gefahr von Abstrafungen besteht nicht, aber die Rankings werden niedriger sein, als sie mit einer sauberen Struktur sein könnten. John Mueller von Google hat wiederholt betont, dass die Kanonisierung per rel="canonical" ein Hinweis an die Suchmaschine ist, keine Direktive. Google kann die kanonische URL ignorieren und eine andere Seite wählen, wenn es diese für relevanter hält. Ein 301-Redirect ist eine Direktive: Er garantiert die Gewichtsübertragung und schließt das Duplikat aus dem Index aus.

Kann ich Redirect 301 /index.php / anstelle von mod_rewrite verwenden?

Technisch ja, aber für Index-Dateien ist das gefährlich. Nach der Weiterleitung auf / ersetzt Apache erneut index.php per DirectoryIndex, die Redirect-Regel greift wieder, was zu einer Endlosschleife führt und der Browser bricht mit einem ERR_TOO_MANY_REDIRECTS-Fehler ab. RewriteCond mit der Prüfung auf %{THE_REQUEST} hat dieses Problem nicht: Es analysiert die ursprüngliche Anfrage des Browsers, nicht die durch interne Serverregeln umgeschriebene.

Muss ich einen Redirect einrichten, wenn die Seite nur über HTTPS läuft?

Ja. HTTPS und Index-Duplikate sind zwei unabhängige Probleme. Selbst mit eingerichtetem HTTP→HTTPS-Redirect und korrektem rel="canonical" liefert eine direkte Anfrage an https://site.ru/index.php einen 200-Code ohne Weiterleitung. Die Regeln aus Methode 1 decken beide Protokolle ab: RewriteRule gibt in der Ziel-URL explizit https:// vor.

Wie überprüfe ich, dass der Redirect die Seite nicht beschädigt hat?

Drei Kontrollpunkte: 1) Die Startseite öffnet sich unter der Root-Adresse / ohne Redirects (curl -I muss 200 liefern); 2) URLs mit index.php und index.html liefern 301 und führen auf /; 3) Der WordPress-Admin (/wp-admin/) funktioniert ohne Schleifen. Der letzte Punkt ist kritisch: Eine schlecht geschriebene Regel in der .htaccess kann Anfragen an index.php innerhalb des Admins abfangen und den Login zerstören. Das Konstrukt aus Methode 1 ist sicher: Es prüft auf exakte URI-Übereinstimmung und berührt /wp-admin/index.php nicht.

Was ist mit anderen Index-Dateien wie index.aspx oder index.py?

Die Mechanik ist dieselbe: Kopieren Sie den RewriteCond- + RewriteRule-Block, ersetzen Sie die Erweiterung und fügen Sie ihn in die .htaccess ein. Stellen Sie bei nicht standardmäßigen Erweiterungen sicher, dass die Datei physisch im Root existiert und in DirectoryIndex aufgeführt ist; andernfalls kann der Server sie ohnehin nicht als Index-Datei ausliefern und es ist kein Redirect erforderlich.

Umgang mit Duplikaten von Index-Dateien: finale Checkliste

Die Einrichtung eines 301-Redirects von index.html und index.php auf die Root-Adresse ist eine Aufgabe nach dem Motto „fünf Minuten Arbeit, jahrelanger Schutz". Die Regel lebt transparent in der .htaccess oder index.php und erfordert keine Wartung, wenn Sie das Design ändern oder zu einem anderen Hosting wechseln.

Nach den Änderungen durchzuführende Schritte:

• Verifizieren Sie den Redirect per curl -I oder redirectchecker.com; die Antwort muss 301 lauten.
• Stellen Sie sicher, dass die Startseite unter der Root-Adresse mit einem 200-Code geöffnet wird.
• Suchen Sie im Seitenquelltext nach href="/index.php" und href="/index.html"; ersetzen Sie jedes Vorkommen durch href="/".
• Führen Sie in der Google Search Console eine Prüfung der Startseite durch; der Bot muss einen 200-Code und die kanonische URL ohne /index.php sehen.

Danach werden Duplikate nach und nach aus dem Bericht „Abdeckung" in der Search Console verschwinden und die Backlink-Power konzentriert sich auf eine einzige kanonische Seite. Das Ergebnis ist nicht sofort sichtbar (die Suchmaschine benötigt Zeit zum erneuten Crawlen), aber es ist unausweichlich.