Zielsetzung: Indexierung für eine Subdomain-Website verbieten

Für diese Aufgabenstellung könnte es verschiedene Szenarien geben die einen triftigen Grund liefern. Hier gehe ich mal von einer Konstellation aus, bei der Sie z.B. ein Hauptprojekt unter der Domain www.mein-projekt.de betreiben - als LIVE-Projekt. Zu Test und Entwicklungszwecken haben Sie auf einer Subdomain, z.B. dev.mein-projekt.de eine gespiegeltes Projekt laufen. Natürlich würde es zu allererst Sinn machen, das DEV-Projekt per Passwortschutz zu sperren. Aber es kann Gründe geben, warum das gerade mal nicht tun will. Wenn das Projekt also offen ist, will man trotzdem verhindern, dass Suchmaschinen sich die Seite des DEV-Projektes gierig krallen und indexieren. Man hätte dann die Situation, dass Nutzer sich in dieses Projekt "verlaufen", was bei einem Shop-System aber auch normalen Websites große Irritationen erzeugen könnte - oder einfach nur dem LIVE-Projekt Konkurrenz macht (z.B. durch dublicate content). Also wollen wir verhindern, dass Suchmaschinen diese Seiten indexieren.

 

Lösung für das Verhindern der Indexierung eine Parallelprojektes

Für diese Aufgabe gibt es zunächst zwei übliche von den seriösen Suchmaschinen akzeptierte und berücksichtigte Werkzeuge. Zum einen die robots.txt, zum anderen einen Meta-Tag in den Dateiheadern.

 

 

A) Lösung: Meta-Tag im Dateiheader

Dazu fügt man in das Template seines DEV-Projektes einen Meta-Tag ein, der die Indexierung verhindert. Dieser sieht üblicherweise so aus:

<meta name="robots" content="noindex, nofollow, noarchive, nosnippet, noimageindex">

Dieser Tag muss natürlich auf allen Seiten des Projektes eingefügt werden, die nicht durch die Suchmaschinen erfasst werden sollten. In meinem oben beschriebenen Szenario also alle. Also würde man es in das Haupttemplate schreiben.

Leider hat das einen Nachteil: Angenommen Sie haben das Projekt gespiegelt und führen auch ständig Abgleiche der Codebasis ihrer beiden Projekte durch, dann würde sich diese Tag auch schnell im LIVE-Projekt wiederfinden. Das wäre natürlich so nicht gewollt im LIVE-Projekt. Für meine Projekte habe ich mir eine kleines Plugin programmiert. Hier gebe ich die Domain des DEV-Projektes ein und alle die Dinge, die im Header anders eingefügt werden sollen als im LIVE-Projekt. Das Projekt erkennt also selbstständig, ob es das DEV-Projekt ist und spielt nur dann diesen Meta-Tag in den Header aus. Dieses Plugin liegt vor als Joomla-Plugin und kann recht einfach auch für Wordpress oder andere CMS realisiert werden. Wer Interesse an diesem Plugin hat, kann sich gern an mich wenden.

 

B) Lösung: robots.txt mit einem .htaccess-Eintrag

In der robots.txt kann man durch disallow-Anweisungen sagen, welche Seiten durch die Suchmaschinen NICHT erfasst und somit NICHT indexiert werden sollen.Dazu schreibt man in die robots.txt einfach folgende Zeilen:

User-agent: *
Disallow: /

Aber auch hier haben wir wieder das Problem mit den gespiegelten Projekten. Es wird ja immer nur die robots.txt gesucht und die muss also auf beiden Servern identisch heißen. Es ist aber notwendig, dass ich den Suchmaschinen im LIVE- und DEV-Projekt jeweils eine andere robots.txt ausliefere. Das gelingt nur über eine Rewrite-Regel in der der .htaccess.

Dazu lege ich zunächst eine neue Robots-Datei an, benenne diese aber z.B. als robots-disallow-all.txt und füge dort die beiden o.g. Zeilen zum Verbieten des Zugriffs ein.

Nun öffne ich die .htaccess und füge hier folgende Regel ein:

RewriteCond %{HTTP_HOST} !^(www\.)?mein-projekt\.de$ [NC]
RewriteRule ^robots\.txt$ robots-disallow-all.txt [L]
RewriteRule ^robots.txt$ - [L]
RewriteRule ^robots-disallow-all.txt$ - [L]

Das besagt: wenn der Domain-Name nicht mit www. beginnt, dann liefere beim Aufruf von robots.txt statt dessen die robots-disallow-all.txt aus. Also, obwohl der URL dann so aussieht: https://dev.mein-projekt.de/robots.txt wird nicht diese Datei ausgeliefert sondern die Disallow-Version. Natürlich kopieren Sie diese so geänderten/erstellten .htaccess und robots-disallow-all.txt auf beide Server-Root-Verzeichnisse (also auf DEV und LIVE).

Die 3. und 4. Zeile ist ein ergänzender Regeleintrag, der zulässt, dass überhaupt diese TXT-Dateien gelesen werden dürfen -für alle die, die ihr Webverzeichnis gut abgesichert haben gegen unerlaubte Zugriffe auf alle TXT-Dateien.