Das WordPress Blog unter einer neuen Domain

bueltge.de [by:ltge.de] wird von Frank Bültge geführt, administriert und gestaltet. Alle Inhalte sind persönlich von mir ausgewählt und erstellt, nach bestem Gewissen und Können, was die Möglichkeit von Fehlern nicht ausschließt.

Kommentare

  
  1. Frank, bei Punkt 1 muss ich dir leider vehement widersprechen.

    Ein Spiderverbot per robots.txt sorgt zwar dafür, dass die Suchmaschinen draußen bleiben, leider bleibt das oft auch so nach Entfernen dieser Einschränkung (bei Google zum Beispiel bis zu 90 Tage lang). Wer also "Disallow: /" nutzt macht sich schon im Vorfeld mit großer Wahrscheinlichkeit die Chance kaputt mit dieser Domain in nächster Zeit gut gefunden zu werden.

    Viel besser ist es den Zugang zu der Domain per Passwortabfrage (.htaccess) zu verhindern. Dieser lässt sich dann später einfach entfernen und hat keine Auswirkungen auf das zukünftige Verhalten der Suchmaschinenbots.

    Ansonsten wie immer schöner Artikel und Anleitung.

  2. @Jan Piotrowski: Vielen Dank! Das ist mir nicht bekannt und so sollte ich das ändern und lieber per .htaccess sperren. Danke !

  3. Vorher war ich ein wenig zu faul direkt die Quellen rauszusuchen, als Beleg für den Sachverhalt habe ich es aber doch getan:

    http://www.google.com/support/webmasters/bin/answer.py?answer=35302&hl=de
    http://www.google.com/support/webmasters/bin/answer.py?answer=61062&hl=de

    Content, der mithilfe dieses Tools entfernt wurde, bleibt mindestens 90 Tage aus dem Google-Index ausgeschlossen, unabhängig davon, ob unser Crawler während dieses Zeitraums darauf zugreift.

    Man kann zwar auch die Wiederaufnahme beantragen, aber auf die Idee muss man als gewöhnlicher Webmaster erstmal kommen. Deshalb wie gesagt lieber per .htaccess. Auch dazu noch fix der passende Link: http://www.drweb.de/htaccess/zugriffsschutz_1.shtml

  4. Jan Amundsen sagt:

    Gute Tipps. Evtl. ziehe ich mit meiner Domain noch mal um. Hab mir ne neue registriert, will aber meinen jetzigen Webspace behalten. Da streite ich noch mit meinem Hoster 😉

    Werde deine Tipps dann aber berücksichtigen.

  5. Rob Vegas sagt:

    Habe erst gestern Dein Plugin gefunden und alle alten Links endlich durch einen neuen Pfad ersetzen können. Diese Hilfe wird sicherlich vielen Bloggern helfen, wobei ein eigenes Plugin dafür toll wäre 😉

    Bitte umziehen von /Domain/ auf /neueDomain/ 😉

  6. Ralf sagt:

    Google per .htaccess auszuschließen ist genauso blödsinnig wie die robots.txt. Ich hatte mal Google aus versehen per .htaccess gesperrt (erst 403 - forbidden, dann 404 - not found). Ich glaube Google ist heute noch sauer auf mich.

    Ich würde einfach eine index.htm anlegen in der der typische "Baustellenschild-Inhalt" hinterlegt ist (Hier entsteht demnächst eine neue Domain schaufelndes Männchen-Gif).
    Die index.htm hat den Vorteil das man in den meta-Tags ein revisit angeben kann und somit recht genau bestimmen kann wann Google&Co wiederkommen sollen. Das andere Inhalte als die index.htm gecrawlt werden, davor muss man keine Angst haben. Die SuMas können ja nur Seiten entdecken, die auch verlinkt sind.
    Ein Problem gibt es allerdings: Ist der Webserver so eingestellt das erst index.php ausgeliefert wird, dann funktioniert das ganze natürlich nicht (sofern eine index.php vorhanden ist). Unter Umständen kann man die Reihenfolge der auszuliefernden Dateitypen in der .htaccess festlegen (sofern der Hoster dies zulässt). Damit wäre es auch möglich eine start.htm anstatt eine index.htm anzugeben, falls man index.htm für irgendwelche Testzwecke benötigt. (weitere Infos: DirectoryIndex)

    Ich bin mir nicht sicher in wie weit sich ein Redirect in der .htaccess SEO-Technisch auswirkt (doppelter Content). Aber auch dies wäre dann ja ggf. eine Möglichkeit. Man schickt einfach alle Sumas per Redirect auf die alte Domain. Das hat natürlich den Nachteil das man ggf. die eine oder andere SuMa vergisst oder Crawler/Besucher zufällig auf die Domain aufmerksam werden.

    Ich denke die Lösung mit der index.htm(l) ist aber die einfachste.

  7. @Ralf: Danke dir für die Infos.

    Die index.htm hat den Vorteil das man in den meta-Tags ein revisit angeben kann und somit recht genau bestimmen kann wann Google&Co wiederkommen sollen.

    Das gefällt mir eh sehr gut - auf die einfachen Sachen kommt man oft nicht.

  8. Leider wird das so nicht funktionieren Ralf. Eine index.htm verhindert zum Beispiel nicht, dass Deeplinks oder Feeds gespidert werden. Und an das Metatag revisit halten sich Google und Co sowieso nicht.

    Natürlich hast du Recht, die von dir angesprochene Methode über die .htaccess 403 forbidden oder 404 not found zu liefern ist natürlich mindestens genau so schlecht wie eine robots.txt die den Zugriff verbietet - alles sorgt dafür, dass die Domain langfristig geblockt wird.

    Einen 401 Authorization Required hingegen wird von Googles Bot erfahrungsgemäß neutral behandelt.

  9. Robert @TalkPress sagt:

    Meine liebste Methode, die Suchmaschinen während der Bauphase von einer Indizierung der Site abzuhalten, ist die Antwort mit dem Status 503 ('Service Unavailable').

    Der vom RFC 2616 vorgegebene Anwendungsfall deckt sich genau mit der Wahrheit: "The server is currently unable to handle the request due to [...] maintenance of the server."

    Damit verschreckt man den Spider meiner Erfahrung nach nicht ernsthaft, sodass nach Inbetriebsetzung eine zügige Aufnahem der neuen Domain in den Suchindex gewährleistet ist.

    Für angemeldete Benutzer mit WordPress- (oder Textpattern)-Logincookie unterdrücke ich diesen Header, damit verhält sich die Site ganz normal, sodass man im Hintergrund schon fast wie live an der Site mit Design und Inhalt arbeiten kann.

  10. Stimmt, das ist auch eine elegante Lösung, Robert. Und die Harmlosigkeit bezüglich Google und Co. kann ich definitiv bestätigen. Lust den Code mit uns zu teilen?

  11. Wishu sagt:

    Ach Frank, ich könnte dich küssen ^^
    Ich habe vor im Laufe der Woche mit meinem Blog umzuziehen und schon nach eine Anleitung gesucht. Es kann ja immer mal sein, dass man auf etwas achten muss.
    Auf jeden Fall interessiert mich ebenfalls, wie man Google nun jetzt am besten aussperren sollte ohne dass er bockig ist ^^

    Gruß
    Wishu

  12. Jan, ich hab das ganze 503 Service Unavailable-Handling mal in ein kleines Plugin eingestrickt. Liegt hier zum Herunterladen und Testen herum.

  13. @Robert @TalkPress: Ähnlich habe ich es in dem Plugin !Wartungsmodus gelößt, leider schon sehr lange her. Da das aber bei einem Umzug nicht per Plugin so einfach geht, zumindest so lange WP nicht installiert ist, reicht quasi eine index.php mit den header-Infos siehe PHP.net.

    header("HTTP/1.0 503 Service Unavailable");
    header("Retry-After: 3600");
    
  14. markus sagt:

    Weiß jemand von euch, wie man alte einzelne Beiträge auf ein neues Blog umzieht? Alles einzeln direkt aus der Datenbank exportieren mag ich nicht... 😉

  15. @markus: Im Grunde bleibt dir nur die DB oder der XML export, den man den händisch auf die entsprechenden Beiträge kürzen muss.

  16. markus sagt:

    Danke für den Tipp mit dem XML-Export, das kannte ich soweit gar nicht.

  17. autopoiet sagt:

    Vielen Dank für den Beitrag. Von .de zu .com in drei Minuten, die dank deines "!Wartungsmodus"-Plugins sogar hinreichend deklariert waren...

    Top!

  18. Martin sagt:

    Hi,

    warum verwendet ihr nicht die .htaccess oder gleich in die httpd.conf folgendes rein. Dann setzt ihr einen Redirect 301 auf die neue Domain und zieht die ganze Domainpower mit:

    RewriteEngine on
    RewriteBase /

    RewriteCond %{HTTP_HOST} ^www.altedomain.de$ [NC]
    RewriteRule ^(.*)$ http://www.neuedomain.de/$1 [R=301,L]

    LG,
    Martin

    Options SymLinksIfOwnerMatch

  19. Ralf sagt:

    Martin, weil der von Frank in Punkt 8 vorgeschlagene Redirect in der .htaccess wesentlich eleganter ist und die Suchmaschinen dadurch mitbekommen das die Domain umgezogen ist 😉

  20. Dirk M. sagt:

    Mal eine Frage: Ich habe unter http://www.xxx.com/de eine WordPress-Installation, die einfach auf http://www.xxx.de umgezogen werden soll. Die Datenbank ist unabhängig von diesen Domains und ziehlt auf xyz.your-server.de ab.

    Würde es reichen, einfach die WordPress-Adresse und die Blog-Adresse zuvor bei der alten Installation von http://www.xxx.com/de auf http://www.xxx.de abzuändern, dann die Daten zu kopieren und auf dem neuen Webspace einzufügen (im Prinzip der gleiche Server)?

    • @Dirk M.: ja, die DB hat ja damit nichts zu tun direkt, aber Inhalte der Db könnten betroffen sein. Daher solltest du eventuell Suchen/ersetzen in der SQL-Datei durchführen. Ansonsten kannst du die Def. der Konstanten, siehe Beitrag oben, in der neuen wp-config.php vornehmen, so musst du nicht die Einstellungen im Backend von WP ändern.

  21. ich wollte nur kurz ein Dankeschön hier lassen, ich musste einen Blog umziehen, neue DB Version, neue Domain, neuer Server ... mit diesem Beitrag im Hinterkopt hat alles geklappt

  22. Sigema sagt:

    Hallo,
    Auch ich bin sehr dankbar für den Beitrag oben. Insbesondere als auffiel das Umlaute und div. Sonderzeichen nach dem DB Export nicht nur bei mir kryptisch werden. In etwa so:
    ü = ü
    Ü = Ãœ
    ö = ö
    Ö = Ö
    ä = ä
    Ä = Ä
    á = á
    à = "à"
    â = â
    é = é
    è = è
    ß = ß
    "" =  (nix bzw. doppeltes Leerzeichen)
    ° = °

    Leider hat auch das durchlaufen des Scriptes nicht geholfen. Mir blieb nur per Copy&Paste im Export alles zu ersetzen, z. B. mit &uuml. Was dann wiederum, importiert, im PHPMyAdmin nicht umgewandelt wurde.

    Gibt es irgendeine Einstellung die ich übersehen haben, einen Fehler den ich gemacht haben könnte? Zur Info:
    - im alten WP ist das Plugin o42-clean-umlauts installiert
    - ich habe der Export in die neue leere Datenbank importiert, da ich bei einem vorherigen Importversuch, nach Installation mit install.php Probleme mit verschobenen Cat-Zuwweisungen hatte.

    Es wäre wirklich ganz ganz dufte wenn ich hier Hilfe fände 🙂

    Liebe Grüße,
    Sigema

    • @Sigema: nein, ist soweit OK, wenn aber die alte DB so ist, dann kann man nur via Script oder per Suchen/Ersetzen die Zeichen korrigieren. Für letzteres gibt es Plugins und für die Umstellung auf UTF-8 gibt es ebenso Plugins.

  23. Michael sagt:

    Hi! Vielen Dank für die Beschreibung. Das hat bei mir auch soweit funktioniert. Ich habe jetzt allerdings das Problem, dass ich keine automatischen Updates mehr bei wordpress machen kann. Klicke ich das Feld an, dann muss ich ja Nutzername und Kennwort meines Servers angeben. Dort nimmt er aber nicht die Kennungsdaten des neues Servers (neue Domain liegt auf anderem Server) und bringt eine Fehlermeldung, dass diese Daten falsch sind. Wenn ich aber die alten Server-Kennungsdaten eingebe, dann funktioniert das automatische Update wohl zwar ohne Fehlermeldung, aber dort soll das Update ja nicht ausgeführt werden.
    Ich hoffe, ich konnte verständlich machen, wo das Problem liegt. Hast Du vielleicht spontan eine Idee, warum er die neuen Kennungsdaten als falsch zurückweist? Mit welchen Daten gleicht er das intern ab? Die wp-config habe ich zumindest mit den neuen URL - so wie oben beschrieben - versehen...
    VG!
    Michael

    • @Michael: die Daten, die ich hier nenne, haben dabei keinen Einfluss. Du musst beim automatischen Update die FTP-zugangsdaten hinterlegen, die vom Webspace geliefert werden oder die du selbst definiert hast.

  24. Sascha sagt:

    Auch ich möchte innerhalb der kommenden 2 Wochen mit unserem Blog von http://www.klosterblog.wat-lo.com auf http://www.theravadablog.de umziehen. Beide Domains sind innerhalb eines Webpakets gehostet.

    Meine Frage:
    Könnte hier nochmal jemand kurz auf das wieder einspielen des Datenbankbackups eingehen.
    Ich stehe vor folgendem Problem, mein 1&1 Hostingpaket lässt nur eine Datenbank zu, d.h. nach dem Backup muss ich die alte Datenbank löschen.

    Muss ich dann quasi eine neue erstellen und mittels eine import Funktion die Daten einspielen?

    Danke,
    Sascha

  25. Sascha sagt:

    @ Frank
    So etwas in der Art hatte ich gestern im Anschluss an Deinen Artikel auch noch im Netz gefunden, macht im Grunde ja auch Sinn.

    Wie muss ich dann aber weiter vorgehen? Kannst Du mir kurz unter die Arme greifen?
    Ich muss wohl auf jeden Fall die Daten, die unter der alten Domain auf dem Server liegen via FTP downloaden und der neuen zuordnen, sprich uploaden, richtig?
    Muss ich sonst noch etwas tun?

    Danke!
    Sascha

    • Wenn sich nur die Domain ändert, dann muss man wohl nichts tun, wenn der Provider der gleiche ist. Aber das ist unterschiedlich. Mache in jedem Fall per FTP ein Backup und ebenso von der Datenbank, schadet nicht.

  26. Sascha sagt:

    Ja, es ändert sich lediglich die Domain. Gleicher Provider (1&1), gleiches Hosting Paket, gleicher Server.

    Muss ich dann nicht irgendwie die URLs der Beiträge anpassen? Sie würden innerhalb der Datenbank ja noch auf die alte Adresse bezogen sein oder?

  27. Sascha sagt:

    Der Provider (1&1) ist der gleiche, das Hosting Paket ist das fleiche und der Server wohl auch.

    Wenn ich aber nur die Daten die ich via FTP von der alten Domain ziehe unter der neuen hochlade, dann passen doch die Beitrags URLs nicht mehr, oder?

    Wenn ja, wie passe ich sie an? Ich hab mal Dein Search&Rename installiert, kann aber als Newbie nicht all zu viel damit anfangen.

  28. Sascha sagt:

    @Frank:
    Ich habe nun gestern die Blogdaten via FTP von der einen auf die andere Domain verschoben. Danach war der Blog unter der neuen Domain erreichbar, jedoch waren alle URLs noch mit der alten Adresse versehen. Also habe ich die wp-config.php mit den neuen Adressdaten versehen, was zur Folge hatte, dass die URLs entsprechend der neuen Domain (automatisch) geändert wurden. Nun noch Feedburner und ReCaptcha auf die neue Domain eingestimmt und es sieht so aus, als wenn alles problemlos gelaufen sei.
    Abschließend habe ich noch eine .htaccess mit der 301er Meldung im Webspace der alten Domain verankert.

    Kann ich es nun riskieren, die Daten der alten Domain zu löschen oder muss noch etwas beachtet werden?

    So weit vielen Dank für Deine Hilfe!

    • Du musst aber trotzdem URLs in der Datenbank ändern, wenn es denn welche gab. Da die wp-config dort nicht gezogen wird, dass ist pur content.

  29. Sascha sagt:

    Könntest Du mir bitte erklären wie ich herausbekomme ob URLs welche die alte Domain beinhalten in der Datenbank vorhanden sind, wie ich sie finde und wenn vorhanden ändern kann?
    Vielen Dank!

  30. Sascha sagt:

    Danke Frank!

    Nun habe ich via MySQL und dem von Dir genannten Code die Datenbank nach URLs der alten Domain durchsucht und habe einige in versch. Tabellen (wp_ak_twitter, wp_comments, wp_links, wp_options, wp_postmeta, wp_posts, wp_statz, ) gefunden.

    Ist es nun ratsam die alten URLs mittels dem Button "Bearbeiten" (MySQL) händisch in die neue Domain-URL zu ändern? Wäre allerdings einiges an Arbeit.

    Oder kannst Du mir kurz erklären, wie ich in Search&Rename vorgehen muss, ich steige bei dem Tool nicht so ganz durch, da ich mit SQL normalerweise absolut nichts zu tun habe.

    • Du kannst direkt via SQL ändern, mal am Beispiel der Tabelle posts: UPDATE wp_posts SET post_content = REPLACE(post_kontent, 'alte_url', 'neue_url');. Allerdings geht das einfacher mit dem besagten Plugin: Suchen & Ersetzen.
      Aber das Plugin bedient nur Tabellen von WordPress; du hast auch Tabellen von Erweiterungen, die du dann nur per SQL ändern kannst.

  31. Sascha sagt:

    Ich hatte es gegen Mittag mit Search&Replace versucht. Ursprünglich bekam ich 62 Treffer angezeigt, was auch der Abfrage über phpMyAdmin entsprach. Nach dem S&R durchgelaufen war wurde mir 0 angezeigt. phpMyAdmin zeigt mir jedoch nach wir vor Treffer an (nicht nur in den Tabellen der Erweiterungen, sondern auch in denen, die eigentlih von S&R bereinigt wurden.

    Nutze ich den manuellen Weg mit dem von Dir o.g. Befehl, so bekomme ich jeweils folgenden Fehler angezeigt: #1054 - Unknown column 'post_kontent' in 'field list'

  32. Peter sagt:

    Nicht zu vergessen: Neuer Code für Google Analytics und Webmastertools einfügen. Neue Sitemap erstellen lassen und anmelden.

  33. Chaim sagt:

    Hi. Ich wollte einfach mal Danke sagen.
    Ich bin grade mit meinem Blog umgezogen und besonders das Suchen&Ersetzen Plugin war ein guter Hinweis.
    Danke

  34. Michael sagt:

    Danke für die Tipps, konnte die echt gut gebrauchen beim Umzug meines Blogs!

  35. Martin sagt:

    Von mir auch ein großes Dankeschön. Mir hat das diese Woche auch weitergeholfen bei der Arbeit...

  36. Robert sagt:

    Falls WordPress nicht grade so erreichbar ist "domainname.tld/unterverzeichnis/" kann man sich auch einige Tipparbeit beim Umzug sparen, wenn man die 2 Konstanten dynamisch setzt:

    define('WP_SITEURL', "http://".$_SERVER['HTTP_HOST']);
    define('WP_HOME', WP_SITEURL);

  37. Melanie sagt:

    Hallo Frank,
    ich habe mit Begeisterung dein WordPress Buch gelesen und bin begeistert. Jetzt habe ich es schon *fast* alles verstanden, nur die Permalinks wollen bei so manchen Provider einfach nicht laufen.
    Lieben Gruß, Melanie

  38. Norbert sagt:

    Ich hatte vor 1 Jahr mal eine WordPress Seite auf freepsace gelegt nun war es an der Zeit auf ordentlichen Space umzusteigen. Mit diesem Artikel ist mir das auch Problemlos gelungen, vielen Dank dafür!

    Gruß Norbert

  39. Ramona sagt:

    Da ich nur bestimmte Kategorien umziehen will, wollte ich das mit XML-Import/Export machen, auch wegen mangelner PHP/SQL-Kennntisse. Blöd nur, dass die Attachments fehlen und die Pfade nicht stimmen. Hast du dafür auch eine Lösung irgendwo schon beschrieben?

    • @Ramona: die Attachments kann WP beim XML Import/export mitnehmen; beim Import kann man dies "anhaken". Sollten dabei Fehler auftreten, dann muss in der DB die URLs angepasst werden, geht mit dem Plugin Search&Replace. Alternativ lade die Bilder per FTP runter/hoch und passe mit dem Plugin die Pfade nach dem SQL Import - einfach via Adminer - an.

  40. Paul sagt:

    Nicht vergessen eine neue Sitemap und eine neue Robots.txt zu erstellen. Passiert mir häufiger mal und hat verheerende(!) Auswirkung auf das Ranking in den Suchmaschinen.

  41. Ramona sagt:

    Vielen Dank, lieber Frank! Angehakelt war alles, aber anscheinend gab's ein Problem. Ich werde vorgehen, wie du es beschrieben hast. Wäre übrigens mal einen Artikel wert, so richtig ausführlich mit Beispielen. Wenn man im Web sucht, gibt es jede Menge Rat Suchende. Aber ich weiß ja, du müsstest erst geklont werden, damit du ein paar Minuten mehr Zeit hast 😉 Danke auch für deine vielen anderen tollen Plugins!

  42. Ben Kempel sagt:

    Ich betreibe ein großes Artikelverzeichnis mithilfe eines WordPress Plugins und habe mir den Stress selbst angetan vor kurzem. Danke für deinen Artikel, er hat mir auf jeden Fall weitergeholfen! Für Laien für mich selbstständig wäre das eine Qual mit viel Potenzial zu Schäden!

  43. Zafer sagt:

    Super Artikel, Bravo..

    Zafer aus Mallorca

  44. gavin sagt:

    hat leider nicht funktioniert der umzug. komme über die domain http://www.xxx.de/wp-admin.php
    zwar rein aber die seite wird nicht dargestellt. bitte um hilfe. wäre super!

  45. mx sagt:

    hallo frank! danke erstmal für den hilfreichen beitrag, ich bin auch gerade beim umziehen.

    ich hätte eine frage zu der index.php mit der header()-Funktion: bedeutet das, dass ich diesen header einfach in das bestehende index.php der neuen wp-installation zu beginn reinkopiere? sorry, absoluter laie 🙂 reicht dies aus um google temporär zu blockieren?

  46. Alex sagt:

    Hallo,
    habe nach deiner Anleitung meinen Blog umgezogen. Hat auch alles wunderbar funktioniert, bis auf die Bilder... Nach dem Umzug werden die Bilder nicht dargestellt und die Bild-Quelle (im Artikel und Bildeigenschaften) zeigt noch immer auf die alte Domain.
    Hat jemand ne Idee, woran das liegt?

    Vielen Dank und Grüße und natürlich schöne Weihnachten
    Alex

Trackbacks

  1. [...] Schlag geändert worden! Das Plugin heisst “Search & Replace” und hat meine ganze Datenbank nach dem angegebenen Text durchsucht und durch den neuen URL Pfad ersetzt. Kinderleicht und wieder [...]

  2. [...] Den Beitrag findet ihr hier: Das WordPress Blog unter einer neuen Domain [...]

© 2016, since 2005 bueltge.de [by:ltge.de] · Theme is built by ThemeShift