Das Umziehen des Blog auf einen neuen Provider hatte ich schon vor geraumer Zeit erklärt, Hinweise und Problemlösung sind auch dort zu finden. In diesem Zusammenhang hat sich nicht viel geändert, der Ablauf kann noch immer so durchgeführt werden, auch wenn der Artikel nun schon ein wenig in die Jahre gekommen ist.
Trotzdem steht aber bei dem einen oder anderen ein ganz anderes Problem - der Umzug eines bestehenden Blog zu einer neuen Domain. Dies kann verheerende Auswirkungen auf die Besucherzahlen haben, wobei es nicht um diese Aspekte gehen soll, und die neue Domain macht den Umzug nicht ganz so einfach – oder doch? Wie man mit wenigen Schritten und einfachen Abläufen das Blog auf eine neue Domain umzieht, darum wird es im folgenden gehen.
Bevor es um den eigentlichen Umzug geht, sollte man natürlich ein Backup aller Dateien und Daten in der Datenbank machen, sollte eigentlich nicht mehr erwähnt werden.
- Die neue Domain versorgt ihr als erstes mit einer
robots.txt, die mit nur wenigen Zeilen Inhalt auskommt:
User-agent: *
Disallow: /
Nun könnt ihr ungestört arbeiten und Suchmaschinen nehmen noch keine Notiz von euch.
Update: Jan weist in den Kommentaren darauf hin, dass diese Lösung nicht so gut ist, denn Google indiziert dann die Seite bis zu den kommenden 90 Tagen nicht. In diesem Fall rate ich lieber zu einer Sperrung der neuen Domain via .htaccess-Zugriffsschutz – wie das geht, auch dazu habe ich bereits einen Artikel erstellt. Den passenden Generator findet ihr hier.
Update II: Noch besser ist eine index.php, die mit der Funktion header() ausgestattet, den Besucher Suchmaschine nur hinhält und zum Wiederbesuch bewegt.
<?
header("HTTP/1.0 503 Service Unavailable");
header("Retry-After: 3600");
?>
Weiteres zum Thema findet mal in den Kommentaren.
- Im Anschluss werden die Dateien und die Datenbankdaten des alten Blog unter der neuen Domain eingespielt.
- Die Datei
wp-config.php muss bearbeitet werden. Dazu die Datei im Editor eurer Wahl öffnen und die folgenden Daten ergänzen. Dabei ergänzt ihr die Datei um zwei Konstanten, die nun die neue Domain und das neue Installationsverzeichnis von WordPress definieren.
define('WP_SITEURL', 'http://www.example.com');
define('WP_HOME', 'http://www.example.com/blog');
Tipp:
Die Definition der beiden Konstanten empfiehlt sich auch für jeden anderen Blog, denn damit erspart sich WordPress die Anfrage an die Datenbank und man kitzelt wieder einiges an Zeit für die Performance aus der Installation. Die korrekte Definition ist unbedingt zu prüfen, denn schon ein falsches / kann dem Leser den Besuch verwehren!
Sind die beiden Konstanten definiert, dann ist das daran zu erkennen, dass im Bereich der Einstellungen von WordPress die beiden Felder deaktiviert sind, siehe Screenshot.
- Nun startet die Installation von WordPress mit den gleichen Datanbankdaten. Die neuen Adressen werden aus den beiden Konstanten gezogen.
Ein Hinweis: sollte ein Plugin oder Modifizierung zum Cachen aktiv sein, dann dies bitte deaktivieren.
- Nachdem das neue Blog läuft, installiert das Plugin Suchen & Ersetzen, welches eich dabei hilft, die alten Beiträge nach der alten URL zu durchforsten und mit der neuen URL zu ersetzen.
- Nun gilt es, alle Eigenschaften des Blog zu prüfen, möglichst sorgfältig und gründlich.
- Ist alles OK? Dann kann die am Anfang angelegte
robots.txt gelöscht bzw. auf einen neuen Stand gebracht werden. Suchmaschinen bekommen nun Zutritt.
- Das alte Blog verseht ihr mit einer
.htaccess-Datei, die folgenden Inhalt trägt:
Redirect 301 /blog/ http://www.example.com/
- Nun könnt ihr die alten Dateien und die Datenbank des Blog löschen.
- Sollte eine Account bei Feedburner aktiv sein, so muss dieser mit der neuen Domain versehen werden. Ansonsten werden eine Reihe von Abonnenten keine News mehr bekommen.
Im Grunde war es das schon. Ist also gar nicht so schwer, wie es anfangs scheint. Viel Erfolg beim Umzug.
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.
@Jan Piotrowski: Vielen Dank! Das ist mir nicht bekannt und so sollte ich das ändern und lieber per .htaccess sperren. Danke !
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
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
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.
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/
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.
@Ralf: Danke dir für die Infos.
Das gefällt mir eh sehr gut - auf die einfachen Sachen kommt man oft nicht.
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.
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.
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?
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
Jan, ich hab das ganze
503 Service Unavailable-Handling mal in ein kleines Plugin eingestrickt. Liegt hier zum Herunterladen und Testen herum.@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");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...
@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.
Danke für den Tipp mit dem XML-Export, das kannte ich soweit gar nicht.
Vielen Dank für den Beitrag. Von .de zu .com in drei Minuten, die dank deines "!Wartungsmodus"-Plugins sogar hinreichend deklariert waren...
Top!
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
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
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.phpvornehmen, so musst du nicht die Einstellungen im Backend von WP ändern.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
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 ü. 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.
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.
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
@Sascha: wenn die DB im gleichen Webspace liegt, wie die alte, und sich nur die Domain ändert, dann kannst du doch wieder nutzen.
@ 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.
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?
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.
@Sascha: die URLs in der Datenbank müssen angepasst werden, wenn es denn welche gibt. Lese mal die Anleitung, dort steht es drin.
@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.
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!
Du kannst via SQL recht gut suchen:
SELECT * FROM wp_posts WHERE post_content LIKE 'http://alte_url%';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.
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'
Nicht zu vergessen: Neuer Code für Google Analytics und Webmastertools einfügen. Neue Sitemap erstellen lassen und anmelden.
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
Danke für die Tipps, konnte die echt gut gebrauchen beim Umzug meines Blogs!
Von mir auch ein großes Dankeschön. Mir hat das diese Woche auch weitergeholfen bei der Arbeit...
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);
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
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
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.
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.
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!
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!
Super Artikel, Bravo..
Zafer aus Mallorca
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!
@gavin: prüfe die Domains, definiere sie via Konstante - damit kannst du einfacher spielen.
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?
@mx: nein; erzeige eine neue, dann kannst du die dann einfach löschen, wenn der Umzug fertig ist.
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
@Alex: ja, du musst die DB-Einträge ebenso ändern; dazu nimm das Plugin Search & Replace und ersetze die alte Domain mit der neuen Doamain.