Suchmaschinen daran hindern eine Staging-Seite zu indizieren

Wenn man an einer Webseite arbeitet, egal ob diese bereits live gegangen ist, oder es sich um ein neues Projekt handelt, man sollte dabei immer eine Kopie der Seite in einer Staging-Umgebung haben. Aber man möchte ganz sicher nicht, dass diese Seite von einer Suchmaschine indiziert wird. In diesem Beitrag möchte ich euch ein paar Wege vorstellen, wie man eine solche Indizierung verhindern kann.

Methode 1: Die Standard-Einstellung nutzen

Im Dashboard der Seite navigiert ihr zum Punkt “Einstellungen | Lesen”. Dort findet ihr die Option “Sichtbarkeit für Suchmaschinen” in könnt hier die Checkbox “Suchmaschinen davon abhalten, diese Website zu indexieren” aktivieren. Dies erstellt dynamisch eine sogenannte “robots.txt” Datei, die Suchmaschinen mitteilt, dass eure Seite nicht indiziert werden soll. Wie der Hinweis “Es ist Sache der Suchmaschinen, dieser Bitte nachzukommen” allerdings ausdrückt ist dies nur eine Anweisung an Suchmaschinen dies nicht zu tun, manche werden die Seite vielleicht dennoch indizieren.

Methode 2: Verhindern der Indizierung durch die Serverkonfiguration

Die erste Methode funktioniert eigentlich ziemlich gut. Es gibt nur ein großes Problem damit. Diese Einstellung wird in der Datenbank gespeichert und kann einfach überschrieben werden? Wie? Nun, es kommt oft vor, dass man sich bei der Arbeit an einer Staging-Seite mal einen aktuellen Stand der Live-Datenbank importiert. In dieser ist die Einstellungen natürlich nicht aktiviert. Denkt ihr immer daran, das dann sofort nachzuholen? Vielleicht vergesst ihr es mal.

Daher kann man die Indizierung auch über die Serverkonfiguration verhindern und gefahrlos eine Live-Datebank importieren. Hierzu fügt ihr einfach folgende Zeilen in die Konfiguration ein:

Header set X-Robots-Tag "noindex"
Header merge X-Robots-Tag "noarchive"

Das könnt ihr in der .htaccess Datei der Staging Seite machen. Das ist auch der beste Weg, wenn man die globale Konfiguration der Servers nicht bearbeiten kann. Aber auch hier besteht die Gefahr, dass man vielleicht versehentlich die .htaccess Datei mit der Version der Live-Seite überschreibt.

Falls ihr einen eigenen Staging-Server habt und nicht möchtet, dass irgendeine Seite dieses Severs indiziert wird, dann fügt die beiden Zeilen z.B. in eine globale Konfiguratoinsdatei wie /etc/apache2/apache2.conf oder eine ähnliche Datei ein.

Methode 3: Verwendet ein Wartungsplugin

Durch den Einsatz eines Wartung (oder englisch “Maintenance”) Plugins kann man auch verhindern, dass die Staging-Seite indiziert wird. Damit wird oft ein Passwort vor die gesamte Seite geschaltet oder man muss sich einloggen, um die eigentliche Seite zu sehen. Damit kann man auch anderen Zugriff auf die Seite geben, aber eben nicht jedem. Diese Methode hat leider ebenfalls das zuvor beschriebene Problem, denn der Zustand der gerade aktiven Plugins wird auch in der Datenbank gespeichert und importiert man eine Live-Datenbank, muss man daran denken, das Plugin danach wieder zu aktivieren.

Methode 4: Verwendet eine “Basic Authentication”

Mit der “Basic Authentication”, oder auch “htaccess Schutz” genannt, könnt ihr die gesamte Seite ohne ein zusätzliches Plugin schützen. Bei einem Apache-Webserver fügt man hierbei ein paar Zeilen in die .htaccess Datei und alle, die die Seite aufrufen, müssen zuerst einen Benutzernamen und ein Passwort eingeben. Diese Methode ist also sicher, wenn man die Live-Datenbank importiert, aber wenn die .htaccess Datei mit der Version der Live-Seite überschreibt, muss man den Schutz erneut einrichten. Daher bietet es sich auch hier an, die Einstellung global (pro Seite) in der Serverkonfiguration zu hinterlegen.

Fazit

Es gibt viele verschiedene Wege um zu verhindern, dass eine Staging-Website durch Suchmaschinen indiziert wird. Welche Methode auch immer ihr verwendet, ihr solltet immer prüfen, ob dieser Schutz noch funktioniert, wenn ihr etwas von einer Live-Seite importiert habt. Man kann zwar eine indizierte Seite aus einer Suchmaschine löschen lassen, ihr müsst dann aber jeder Seite über deren URL in jeder einzelnen Suchmaschinen über die individuellen Werkzeuge manuell löschen lassen.

WordPress-Domain und Dateipfade in der Datenbank aktualisieren

Im letzten Blogbeitrag habe ich euch gezeigt, wie ich WordPres Websites auf einen andern Server migriere. In Schritt 7 bin ich auf die Übersetzung der Domain in der Datenbank eingegangen. Dies ist aber nicht die einzige Ersetzung, die man eventuell machen muss. Daher soll es im heutigen Beitrage darum gehen, welche anderen Ersetzungen eventuell noch notwendig sind.

Schauen wir uns also noch einmal die grundlegendste Ersetzung an. Mit diesem Befehl wird die Domain in allen Tabellen ersetzt, die den Präfix der aktuellen WordPress Installation haben:

wp search-replace "https://staging.example.com" "https://example.com" --all-tables-with-prefix

Dieser Befehl ersetzt die Domain in allen Spalten in allen Tabellen einer WordPress-Datenbank, auch wenn diese als serialisiertes PHP-Objekt gespeichert sind.

Zusätzlich sollte auch der Dateipfad auf dem Server ersetzt werden, da dieser von einigen Plugins verwendet wird:

wp search-replace "/home/staging.example.com" "/home/example.com" --all-tables-with-prefix

Weitere alte Domains suchen

Nach der Durchführung dieses Befehls sollten die meisten Domains bereits ersetzt sein. Man kann aber auch sehr einfach prüfen, ob es den alten Wert noch gibt. Auch hierbei hilft uns die WP-CLI:

wp db search "https://staging.example.com"

Weitere Ersetzungen

Leider gibt es sehr viele Plugins, die komplexe Daten in anderen Formaten speichern. Daher ist es empfehlenswert, auch folgende Ersetzungen durchzuführen, sofern die Suche zuvor noch Ergebnisse geliefert hat.

SuchmusterErsetzungBemerkung
http://example.comhttps://example.comNeue Domains ohne SSL
http://staging.example.comhttps://example.comAlte Domains ohne SSL
//staging.example.com//example.comprotokol-relative Pfade
https:\/\/staging.example.comhttps:\/\/example.comJSON-Objekte (ausführen für alle vorherigen Muster)
@staging.example.com@example.comE-Mail-Domains (optional, da nicht immer gewünscht)
staging.example.comexample.comGefährlich!
Ersetzungsmuster bei Domainumstellung

Es sind einige Varianten zu beachten. Für die ersten vier Ersetzungen sollte man zusätzlich alle Slashes “escapen”, falls Objekte als JSON-String gespeichert wurden. Die E-Mail-Adressen sind optional, da auf dem neuen System eventuell keine E-Mails versendet werden sollten (z.B. bei Übertrag von Live zu Staging) oder falls diese im Frontend ausgegeben werden und man nicht möchte, dass hier eine andere Domain zu sehen ist.

Die letzte Ersetzung scheint die beste zu sein, da sie alle vorherigen umfasst. Aber sie kann potentiell auch zu schwierig zu findenden Problemen führen, da der Domainname bespielsweise in Bildnamen vorhanden sein könnte, die dann auf einmal nicht mehr angezeigt werden. Man sollte also am besten niemals nur den Domainnamen ersetzen.

Weitere Maßnahmen

Oft werden in Themes, Plugins oder auf dem Server Caches eingesetzt. Oft haben diese eigene Mechanismen, um diese zu leeren.

Fusion Builder (z.B. Avada Theme)

Unter “Avada/Themename | Theme Options | Performane | Reset Fusion Caches” über den gleichnamigen Button “Reset Fusion Caches” alle Dateien im Cache löschen.

Autoptimize

In der Adminbar findet man einen Eintrag “Autoptimize” und am Ende einen Link “Delete Cache”.

PageSpeed

Den PageSpeed-Cache kann man nur über den Server leeren. Nachdem man sich zu diesem verbunden hat, muss man folgenden Befehl ausführen:

touch /var/cache/pagespeed/cache.flush

Es kann ein paar Sekunden dauern, bis der Cache vollständig geleert ist. Nachdem er leer ist, entfernt man die Datei einfach wieder:

rm /var/cache/mod_pagespeed/cache.flush

Weitere Infrormationen zum partiellen Leeren des Caches findet ihr in der PageSpeed Dokumentation.

Eine WordPress-Installation in weniger als 5 Minuten migrieren

Ich arbeiten an WordPress Projekten immer lokal. Bei vielen Projekten gibt es zusätzlich einen Staging-Server. Die Migration einer WordPress-Installation ist also eine sehr häufig vorkommende Aufgabe für mich. Daher ist ein guter Prozess hier sehr wichtig.

Einfache Migration ohne Plugins

Wenn ich eine Seite migriere, dann verwende ich immer die WP-CLI. Die einzige Voraussetzung hierfür ist ein SSH-Zugang zum Zielserver. Mein Migrationsprozess unterteilt sich in wenige Schritte:

1. Dump der Quelldatenbank

Eine WordPress-Installation besteht aus zwei Teilen, der Datenbank und dem Dateisystem. Um einen Dump der Datenbank zu erstellen, muss nur der folgende Befehl im Hauptverzeichnis von WordPress (dem “document root”) ausgeführt werden:

wp db export
Success: Exported to 'wp_project-staging-2020-04-05-a2aa75c.sql'.

Der Dateiname startet mit dem Namen der Datenbank, gefolgt vom aktuellen Datum und einem zufälligen hexadezimalen Hash. Das ist sehr praktisch für den zweiten Schritt.

2. Packen aller Dateien auf der Quelle

Jetzt sind wir soweit, alle Dateien auf dem Quellserver zu packen. Das erledigen wir einfach mit zip, gzip oder einem anderen Tool:

zip -r wp_project-staging-2020-04-05-a2aa75c.zip .

Als Dateinamen verwenden wir einfach den gleich Namen wie beim Datenbank-Dump und ändern hierbei lediglich die Dateiendung von .sql zu .zip im Befehl. Das “schützt” den Dateinamen davor, einfach erraten werden zu können. Wenn man die Datei einfach nur dump.zip nennen würde, könnte sonst jeder einfach die Datei runterladen.

3. Übertragung der Datei auf den neuen Server

Jetzt ist es an der Zeit, die Datei auf den neuen Server zu übertragen. Das kann man über verschiedene Wege tun. Ein sehr einfacher ist die Verwendung von curl, wget oder ähnlichem:

wget https://staging.example.com/wp_project-staging-2020-04-05-a2aa75c.zip

Wenn man die Dateien von einem lokalen System überträgt, wird man vermutlich FTP verwenden, da man die Datei ja nicht per curl/wget von einer lokalen Domain laden kann.

4. Entpacken der Datei im Ziel

Der nächste Schritt ist sehr nahe liegend. Wir müssen die Datei im Ziel entpacken. Hat man eine ZIP-Datei verwendet, führt man einfach folgenden Befehl aus:

unzip wp_project-staging-2020-04-05-a2aa75c.zip

Wenn man die Dateien in Schritt 2 im Hautpverzeichnis gepackt hat, dann sollten die Dateien auch wieder im Hauptverzeichnis auf dem neuen Server einpackt werden und nicht in einem Unterordner.

5. Aktualisierung der Konfiguration

Bevor wir das Projekt auf dem neuen Server nutzen können, müssen wir die wp-config.php aktualisieren. Vermutlich nur alle Werte, die mit DB_ anfangen.

6. Import der Datenbank

Nun können wir die Datenbank importieren. Wenn die Datenbank auf dem neuen Server noch nicht existiert, kann sie entweder über das Verwaltungsprogramm der Hosters angelegt werden, oder ebenfalls mit einem einfachen WP-CLI Befehl (sofern der Datenbank-User dazu die Berechtigungen hat):

wp db create

Sobald die Datenkbank erstellt ist, können wir den Dump ähnlich zu Schritt 1 importieren:

wp db import wp_project-staging-2020-04-05-a2aa75c.sql

7. Aktualisierung der Domain in der Datenbank

Wie ihr vermutlich wisst, speichert WordPress alle Domainpfade als absolute Pfade in der Datenbank. Daher müssen diese ersetzt werden. Das funktioniert mit einem Plugin, aber noch einfacher über die WP-CLI:

wp search-replace "https://staging.example.com" "https://example.com"

Dies ist die einfachste Ersetzung. In manchen Fällen müssen aber noch andere Ersetzungen durchgeführt werden. Das werde ich in einem zukünftigen Beitrag behandeln.

Fazit

Die Migration eines WordPress-Projekts sollte so einfach und schnell wie möglich sein, gerade dann, wenn man diese Aufgabe sehr regelmäßig erledigt. Mein Ansatz benötigt nur 2 Befehle auf dem Quellserver und 4-5 auf dem Zielserver. Der Teil, der in der Regel die meiste Zeit benötigt, ist das Packen, Übertragen und Entpacken, welches länger dauert, je größer das Projekt ist. Für ein kleines Projekt mit nur wenigen Inhalten dauert es aber jeweils oft weniger als 10 Sekunden.

Ich hoffe, diese kleine Anleitung konnte euch helfen, damit eure nächste Migration genau so schnell und einfach geschieht wie bei mir. Falls ihr einen anderen Ansatz habt, der auch sehr praktisch ist, hinterlasst gerne einen Kommentar hierzu und stellt ihn vor.

Vielen Dank an die WordPress-Community!

Die letzte Woche war hart. Ich meine so richtig hart. Erst vor zwei Wochen habe ich an dieser Stelle allen Organisationsteam gedankt, die Konferenzen absagen mussten. Nun befinde ich mich in genau der gleichen Situation.

Die Absage des WordCamp Europe 2020

Am Donnestagabend vorletzte Woche hatte ich ein Telefonat mit Tess und Jonas, den anderen beiden Global-Leads des WCEU 2020 und mit Rocío, unserer Mentorin, sowie mit Andrea, die das globale WordPress-Community-Team leitet.

Wir haben über einen Zeitplan für die nächsten Wochen und Monate gesprochen und uns einen Plan gemacht, um das WordCamo Europe in Porto im Juni diesem Jahres durchführen zu können. Am 5. März sahen die Dinge noch ganz gut aus. Es gab nur wenige Fälle in Portugal und nur Italien hatte in Europe mit sehr vielen Fällen zu kämpfen. Wir beschlossen also, mit der Planung des Events im Juni weiterzufahren und waren optimistisch, dass es noch stattfinden könne. Wir haben uns bis Anfang April für eine Entscheidung Zeit lassen wollen.

Die letzten Tage

Nach diesem Meeting wurden die Dinge mit jedem Tag schlechter. Konferenzen in Europa wurden abgesagt. Am 9. Märze traf es eine große Joomla Konferenz in Lissabon, die nur eine Woche vor dem WordCamp Europe 2020 in Porto stattfinden sollte.

Am 11. März hat das globale Community-Team Empfehlungen herausgegeben, dass alle Veranstaltungen bis einschließlich 1. Juni abgesagt oder verschoben werden sollten. Da das WCEU 2020 vom 4. – 6. Juni geplant war, also nur bis ein paar Tage zuvor.

Schließlich hatten wir letzten Donnerstag, nur eine Woche nach unsere “Krisensitzung” eine Videokonferenz mit allen Organisatoren, in der wir beschlossen haben, dass wir das WordCamp Europe 2020 absagen und auf das Jahr 2021, ebenfalls in Porto, verschieben werden.

Danke an unserer Communtiy

Die Reaktionen, die auf unserer Ankündigung folgten, waren überwältigend. Wir haben viele empathische Nachichten auf Twitter und anderen Kanälen erhalten. Viele liebe Menschen aus der WordPress-Community haben mich direkt angeschrieben und gefragt, wie es mir geht und Hilfe angeboten.

Darum liebe ich diese Communtiy. In guten und in harten Zeiten unterstützen und helfen wird uns gegenseitig. Das ist auch der Grund, wieso das Organisationsteam positiv in die Zukunft schaut und noch intersiver am WordCamp Europe 2021 in Porto arbeiten wird.

Vielen Dank WordPress-Community ❤

Vielen Dank die Organisationsteams!

Ich hatte für diese Woche einen anderes Thema für den #projekt26 Beitrag geplant, aber die Ereignisse der letzten Wochen haben mich dazu veranlasst über etwas anderes zu schreiben.

WordCamp Asia 2020

Der Februar ist vorüber und es war ein sehr ereignisreicher Monat für mich. Oder sollte ich eher sagen, er war es nicht? Ich habe mich sehr auf keine erst Asienreise gefreut, meine Teilnahme am WordCamp Asia in Bangkok in Thailand. Es war vom 21. – 23. Feburar geplant und ich hatte Flug und Hotel schon vor Wochen geplant sowie Urlaub eingereicht (da Teilnahmen an WordCamps nicht Teil meines Jobs sind). Ich habe mich auch auf ein paar schöne warme Tage mit vielen alten und neuen Freunden gefreut. Aber am 12. Februar bekam ich dann überraschend die traurige Nachricht, dass das WordCamp Asia abgesagt werden musste.

Ich hatte großes Glück und konnte mein Hotel und meinem Flug kostenfrei stornieren. Daher habe ich meine gesamte erste Asienreise für dieses Jahr abgesagt.

CloudFest 2020 Hackathon

Diesen Monat vom 14. – 16. März werde ich meinen ersten echten Hackathon besuchen. Dieser wird nicht nur für Mitglieder der WordPress-Community, sondern für viele andere tolle Menschen aus anderen OpenSource-Communities veranstaltet, sowie Firmen, die sich auf das Thema Hosting spezialisiert haben. Aber auch an dieser Konferenz werde ich nicht teilnehmen, dann das CloudFest musste ebenfalls abgesagt werden.

WordCamp Retreat Soltau 2020

Vor zwei Jahren habe ich eines der besten WordCamps besucht, auf denen ich je als Teilnehmer dabei sein konnte. Es war keine normale Veranstaltung, auf der man sich für einen “Arbeitstag” zu Vorträgen und Workshop traf. Stattdessen verbrachte man 24 Stunden für über mehrere Tage mit allen anderen Teilnehmenden im selben Hotel und konnte neben Vorträgen auch an anderen Aktivitäten teilnehmen. Dieses Jahr war es vom 30. April bis zum 3. Mai geplant. Es war geplant, da auch diese Veranstaltung vor einer Woche abgesagt und auf das nächste Jahr verschoben wurde.

Danke Organisationsteams!

Falls ihr euch nun wundert, wieso ich mich dafür bedankte, dass diese Veranstaltungen abgesagt wurden, dann ist der Grund ganz einfach. Selbstverständlich bin ich sehr traurig darüber, dass ich an an diesen Events nicht teilnehmen kann … zumindest nicht dieses Jahr. Alle Organisationsteams haben aber angekündigt im nächsten Jahr die Veranstaltung erneut zu organisieren. Viele davon am gleichen Ort und ungefähr zur gleichen Zeit.

Ich habe bereits vier WordPress Konferenzen in Berlin organisiert und stecke gerade zum vierten Mal mitten in der Organisation des WordCamp Europe. Ich weiß, wie viel Zeit, Energie und Leidenschaft in die Organisation eines solchen Community-Events fließt. Ich kann mir nur vorstellen, wie schwer es für alle Beteiligten gewesen sein muss, diese Veranstaltungen abzusagen (es gab auch noch weitere).

Mit der Absage einer Veranstaltung ist die Arbeit aber nicht getan und man kann nicht einfach aufhören zu arbeiten. Man muss sich mit den ganzen Nachwehen einer solchen Absage beschäftigen, sämtliche Verträge kündigen und so vielen Menschen wie möglich eine Rückerstattung ermöglichen. Man wird außerdem mit vielen negativen Rückmeldungen zu kämpfen haben, denn nicht alle werden verstehen, wieso die Absage unausweichlich war (wie z.B. “es gab doch gar keine Corona-Infektionen in dem Gebiet”). Allen Personen, die an der Organisation und harten Entscheidung zur Absage beteiligten waren, gilt unsere Unterstützung.

Wenn es euch also wie mir geht und eine Veranstaltung, an der ihr teilnehmen wolltet, wurde abgesagt, dann nehmt euch bitte einen Moment und sendet ein Vielen Dank an das Organisationsteam, denn sie haben es sich mit ihrer Entscheidung sicher nicht einfach gemacht und diese schwierige Entscheidung im besten Interesse der Gesundheit der Community, sowohl der pysischen, als auch der psychischen, gemacht. Und bitte unterstützt sie dadurch, dass ihr auch im nächsten Jahr wieder teilnehmen werdet. Vielleicht ja sogar durch freiwillige Mithilfe auf der Veranstaltung als Volunteer. Damit erhalten ihr den besten Einblick darin, mit wie viel Leidenschaft alle daran arbeiten für uns allen ein tolles Event zu veranstalten!

Danke Ogranisationsteams ❤