Transkript:
SEOs in der ganzen Welt, beißen regelmäßig in die Tischkante, wenn sie eine Entwicklungsumgebung indexiert sehen. Und obwohl man denkt, dass sowas bei all dem Wissen, das man um die Gefahr hat, nicht mehr vorkommen kann, hatte ich erst kürzlich wieder genau zwei solcher Fälle, wo Domaininhaber, die auf mich zukamen, nicht gewusst haben, was da passiert. Und wenn du wissen willst, welche Optionen du in einem solchen Fall hast, dann bleib jetzt dran. Hi und herzlich willkommen zu einer neuen Folge von Frag Andor. Ich bin SEO Berater und berate Shops, Marktplätze, Publisher und B2B Unternehmen und helfe ihnen dabei, durch eine Verbesserung ihrer strategischen Infrastruktur, durch eine bessere strategische Ausrichtung und durch eine Optimierung der internen Prozesse mehr Reichweite in der organischen Suche zu erzielen. Und hier geht es jetzt eben um die Frage der Staging Umgebung, der Entwicklungsumgebungen. Denn zu oft passiert es immer noch, dass ohne Wissen von SEO in Vorbereitung beispielsweise für einen Relaunch eine Entwicklungsumgebung einfach live gestellt wird. Und einem der angesprochenen Fälle war dies natürlich eine komplette Kopie der aktuellen Domain und voll indexierbar und auch schon indexiert. Innerhalb weniger Tage wurden somit tausende von Duplikaten von Google indexiert und die Entwicklungsumgebung hat dann auch angefangen, Rankings in der Suche zu erzeugen. Das ist natürlich dann ein Umstand, wo man meinen könnte, dass das in 2024 einfach nicht mehr vorkommen kann. Und trotzdem passiert es immer wieder. Und auch aus meiner Sicht gibt es hierfür vor allen Dingen zwei Gründe.
Der eine Grund ist die sind die fehlenden Prozesse. Natürlich findet sowas jetzt auch nicht regelmäßig in einem Unternehmen statt. Aber dennoch muss es ja eine Kommunikation beispielsweise zwischen Entwicklung und Marketing geben, wenn so etwas geplant ist. Und dann setzt man sich eigentlich zusammen und spricht die wichtigsten Themen durch, bevor man hier ins Handeln geht. Passiert das aber eben nicht, kann es schnell dazu kommen, dass eben eine solche Entwicklungsumgebung in den Index gerät. Und der zweite Grund ist eigentlich das fehlende Bewusstsein dafür, dass sowas am Ende für SEO relevant ist. Für viele ist die Erstellung einer Entwicklungsumgebung eben nichts, was mit SEO zu tun hat. Denn SEOs, das sind ja nur Keywörter und hier ein bisschen Technik und vielleicht auch ein bisschen Content. So, und das ist an vielen Stellen immer noch die vorherrschende Meinung. Wichtig ist aber zu verstehen, dass im Grunde alles, was mit Frontend und oder Subdomains zu tun hat und sie involviert, für SEO relevant ist. Seo ist eigentlich der einzige Marketingkanal, bei dem die Webseite als Ganzes relevant ist. Und da fällt natürlich auch eine Entwicklungsumgebung mit rein, denn hier wird ja ein komplett neues System erstellt. Und leider bestätigen Beispiele wie diese, die ich jetzt auch wieder mitbekommen habe, dass man auch heute noch dieses Mantra wie eine Monstranz vor sich hertragen muss, damit den Leuten das bewusst wird.
Was aber machen wir, wenn das Kind schon in den Brunnen gefallen ist? Dann, je nach Situation, hat man meist eine der folgenden Möglichkeiten. Die erste Option ist, man setzt die gesamte Entwicklungsumgebung erst einmal auf NoIndex, lässt sie aber noch für Google zugänglich. Das hat nämlich dann den Vorteil, dass Google noch alle Verlinkungen angeboten werden, wenn sie wieder auf die URLs zurückkommen. Und so können sie dann leichter das inzwischen gesetzte NoIndex Signal verarbeiten, weil eben die Verlinkungen da sind. Man könnte jetzt auch noch überlegen, ob eine Sitemap in der GSC einreicht, aber das sehe ich hier eher als optional. Diese Option hat nur eine kleine Unsicherheit, Wenn die URLs der Entwicklungsumgebung schon Rankings gesammelt haben und es auch schon zu einem URLwechsel zwischen der Liveumgebung und der Entwicklungsumgebung gekommen ist und man jetzt einfach ein NoIndex auf die URLs der Entwicklungsumgebung setzt, muss man im Grunde darauf hoffen, dass Google hier einfach die URLs wieder austauscht. Das ist, sofern wirklich ein URLwechsel vorgelegen hat, zwar schon anzunehmen, aber eine Sicherheit dafür gibt es natürlich nicht. Darum könnte man als zweite Option auch überlegen, je nach Umfang des Problems die URLs der Entwicklungsumgebung eins zu eins auf die Live URLs weiterzuleiten und eine neue, gleich von Anfang an geschlossene Entwicklungsumgebung zu erstellen. So würde man dann zumindest sicher gehen, dass alle Signale der Entwicklungsumgebung gebündelt auf die neue, auf die eigentliche Liveduell weitergegeben wird.
Das ist sicherlich mit ein bisschen mehr Aufwand verbunden, aber das wäre zumindest eine Option. Die nächste ist man sperrt die Entwicklungsumgebung einfach komplett. Das hat für Google dann zur Folge, dass sie diese Inhalte gar nicht mehr aufrufen können. Und das wird auch dazu führen, dass sie über das über eine gewisse Zeit die URLs aus dem Index nehmen. Das ist also im Grunde recht analog zur ersten Option, nur eben, dass man hier die Bereitstellung der Verlinkung nicht mehr vornimmt. Hier muss man also im Grunde darauf hoffen, dass Google die URLs von sich aus wieder aufruft, weil sie sie ja, weil sie ja keine Links mehr haben. Gegebenenfalls könnte man hier trotzdem noch eine Sitemap einreichen, aber auch das wie gesagt ist optional. Die vierte Option wäre man löscht die gesamte Entwicklungsumgebung einfach und zieht sie auf eine neue Subdomain oder auch auf eine andere externe Domain und schließt sie hier von Anfang an. In dem Fall sollten die URLs dann auch nach und nach einfach aus dem Index fallen. Aber auch hier bleibt wie bei Option eins oder drei die kleine Unsicherheit über die Rückführung der Rankings und der fehlenden Möglichkeit von Google für das Crawling. Die robots.txt ist für mich in diesem Fall übrigens deswegen keine Lösung, weil sie nur das Crawling steuert und nicht die Indexierung und dafür eigentlich auch nicht gedacht ist, dass URLs, die indexierbar sind, aber nicht gecrawlt werden dürfen, von Google trotzdem indexiert werden, sehen wir ja jeden Tag, weil Crawling in Indexierung nun mal zwei unterschiedliche Themen sind und weil diese dieser Prozess nicht simultan abläuft, ist die robots.txt für mich hier keine Option. Also man hat so ein bisschen die Qual der Wahl, wenn es zu der Indexierung einer Entwicklungsumgebung gekommen ist und daher noch einmal kurz ein paar Worte, wie man das vielleicht auch verhindern kann. Die wohl gängigsten Varianten sind der Htaccess Schutz und das IP Whitelisting. Beim HTaccess Schutz meint man einfach, dass beim Aufrufen der URL eine Passwortabfrage kommt und nur mit eingegebenen Daten gelangt man hier auf die Entwicklungsumgebung. Sonst gibt es eben beispielsweise den Statuscode 403. Das ist so das Gängigste, also forbidden. Da Google nicht hinter den Login zugreifen kann, ist das Thema hier also eigentlich abgeschlossen und sauber gelöst. Bei der IP Lösung können nur Clients auf die Domain zugreifen, die von einer freigegebenen IP auf die Webseite zugreifen. Und auch hier, da Google nicht in die IPs inkludiert ist, passiert im Grunde das Gleiche. Der nicht autorisierte User bekommt beispielsweise eine 403 ausgespielt und kann nicht auf die Webseite zugreifen. Wichtig hierbei ist nur, dass es wirklich dezidierte IPs sind, also feste IPs sind, weil sonst müsste man das beispielsweise immer ändern und das kann man nicht, wenn man remote arbeitet. Da braucht es mindestens dann irgendwie einen Tunnel ins Firmennetzwerk bzw ein VPN mit einer festen IP.
Beide Varianten haben oder helfen gleichermaßen gut, eine Entwicklungsumgebung eben nicht in den Index zu lassen, wobei in den meisten Fällen gleichzeitig auch ein NoIndex Tag ausgespielt wird. Was man aber mittlerweile auch häufiger hat, sind temporäre Entwicklungsumgebungen, Die in den meisten Fällen auf dem Index stehen und nur für kurze Zeit zu Testzwecken erstellt werden und hinterher auch wieder gelöscht werden. Das wiederum kann ein, finde ich probates Mittel sein, weil es so zumindest das permanente Vorhalten einer Entwicklungsumgebung nicht notwendig macht. Es hängt allerdings auch von der Art und Weise der Änderung ab. Bei großen infrastrukturellen Änderungen braucht es meistens schon meiner Meinung nach eine feste Entwicklungsumgebung über einen längeren Zeitraum, um sinnvolle Tests durchführen zu können. Eine Entwicklungsumgebung einfach mit der robots.txt zu sperren ist wie gesagt aus meiner Sicht nicht ideal. Das hat den Grund, dass die robots.txt streng genommen eben nur das Crawling, aber nicht die Indexierung der URLs verhindert. Das Canonical Tag zu nutzen von der Entwicklungsumgebung eben auf beispielsweise das www.Live Pendant kann theoretisch funktionieren, wenn Google sich daran hält, dass wir aber wissen, dass Canonicals es gerne mal ignoriert werden, würde ich an dieser Variante ehrlicherweise auch nicht so gerne festhalten und würde sie deswegen auch nicht empfehlen.
Die ganze Entwicklungsumgebung auf Noindex zu setzen, aber frei zugänglich zu haben, kann auch eine Option sein, wenn einem das Thema Crawling beispielsweise egal sein kann. Ja, andernfalls muss man sich bewusst sein, dass wenn man hier eine komplette Parallelstruktur ins Netz stellt, die von Google in jedem Fall auch irgendwann verarbeitet wird. Denn auf eine Sache ist Verlass Auf irgendeinem Weg wird Google diese URLs finden. Ich mag diese Variante deswegen nicht so sehr, weil man bei der Implementierung der Indexierungsregeln, die man auf der Domain hat, ein bisschen ein Problem bekommt, das zu prüfen, weil wenn alles irgendwie global auf Noindex ist, dann überdeckt das ja alles. Außerdem werden regelmäßig Tools eingesetzt, die hier dann eventuell auf Basis dieser NoIndex Regeln, Grafiken und Auswertungen anders auswerten und von daher die Daten in den Toolsets verzerren. Von daher ist diese NoIndex Regel vielleicht auch nicht immer der Best Case. Ip Sperrungen bzw das ganze Thema hatte Accessschutz und dann dahinter. Das richtige Setup an Indexierungsregeln ist für mich eigentlich schon so der best Case. So, das war’s von dieser Folge. Ich hoffe es hat euch gefallen. Wenn ja, hinterlasst mir gerne einen Daumen hoch hier. Aktiviert die Glocke, dann verpasst ihr auch nicht die nächste Folge. Wenn ihr Fragen, Anregungen oder Kritik habt, dann gerne unten rein in die Kommentare. Ich antworte bestimmt und ansonsten freue ich mich, euch auch bei der nächsten Folge begrüßen zu können. Macht’s gut.