![\"moving](\"https:\/\/alienroad.com\/wp-content\/uploads\/kb-gorsel\/g-88270323fcad.jpg\")
\n<\/p>\nWednesday, April 16, 2008<\/p>\n
\n Planning on moving your site to a new domain? Lots of webmasters find this a scary process. How do
\n you do it without hurting your site’s performance in Google search results?\n<\/p>\n
\n \n<\/p>\n
\n Your aim is to make the transition invisible and seamless to the user, and to make sure that \n Let’s cover moving your site to a new domain (for instance, changing from Here are the main points:<\/p>\n \n We’ll admit it, moving is never easy – but these steps should help ensure that none of your good Wednesday, April 16, 2008 Planning on moving your site to a new domain? Lots of webmasters find this a scary process. How do you do it without hurting your site’s performance in Google search results? Your aim is to make the transition invisible and seamless to the user, and to make sure that Google knows […]<\/p>\n","protected":false},"menu_order":86015,"template":"","meta":{"footnotes":""},"ar_kb_kategori":[665],"ar_kb_etiket":[],"class_list":["post-23970","ar_kb","type-ar_kb","status-publish","has-post-thumbnail","hentry","ar_kb_kategori-blog"],"_links":{"self":[{"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/ar_kb\/23970","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/ar_kb"}],"about":[{"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/types\/ar_kb"}],"version-history":[{"count":0,"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/ar_kb\/23970\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/media\/26588"}],"wp:attachment":[{"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/media?parent=23970"}],"wp:term":[{"taxonomy":"ar_kb_kategori","embeddable":true,"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/ar_kb_kategori?post=23970"},{"taxonomy":"ar_kb_etiket","embeddable":true,"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/ar_kb_etiket?post=23970"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n Google knows that your new pages should get the same quality signals as the pages on your own
\n site. When you’re moving your site, pesky 404 (File Not Found)<\/code> errors can harm the user experience
\n and negatively impact your site’s performance in Google search results.\n<\/p>\n
\n www.example.com<\/code> to www.example.org<\/code>). This is different from moving to a
\n new IP address; read
\n this post<\/a> for more information on that.\n<\/p>\n\n
\n 301<\/code> Redirect<\/a>
\n to permanently redirect those pages on your old site to your new site. This tells Google and
\n other search engines that your site has permanently moved.\n <\/li>\n
\n search results. When you’re satisfied that the move is working correctly, you can move your
\n entire site. Don’t do a blanket redirect directing all traffic from your old site to your new
\n home page. This will avoid 404<\/code> errors, but it’s not a good user experience. A
\n page-to-page redirect (where each page on the old site gets redirected to the corresponding page
\n on the new site) is more work, but gives your users a consistent and transparent experience. If
\n there won’t be a 1:1 match between pages on your old and new site, try to make sure that every
\n page on your old site is at least redirected to a new page with similar content.\n <\/li>\n
\n about doing this in two phases: first, move your site; and second, launch your redesign. This
\n manages the amount of change your users see at any stage in the process, and can make the
\n process seem smoother. Keeping the variables to a minimum also makes it easier to troubleshoot
\n unexpected behavior.\n <\/li>\n
\n external and internal links to pages on your site<\/a>.
\n Ideally, you should contact the webmaster of each site that links to yours and ask them to
\n update the links to point to the page on your new domain. If this isn’t practical, make sure
\n that all pages with incoming links are redirected to your new site. You should also check
\n internal links within your old site, and update them to point to your new domain. Once your
\n content is in place on your new server, use a link checker like
\n Xenu<\/a>
\n to make sure you don’t have broken legacy links on your site. This is especially important if
\n your original content included absolute links (like
\n https:\/\/www.example.com\/cooking\/recipes\/chocolatecake.html<\/code>) instead of relative
\n links (like ...\/recipes\/chocolatecake.html<\/code>).\n <\/li>\n
\n least 180 days.\n <\/li>\n
\n Then create and submit a Sitemap<\/a>
\n listing the URLs on your new site. This tells Google that your content is now available on your
\n new site, and that we should go and crawl it.\n <\/li>\n
\n crawl errors<\/a>
\n regularly to make sure that the 301<\/code> errors from the old site are working properly, and that the new
\n site isn’t showing unwanted 404<\/code> errors.\n <\/li>\n<\/ul>\n
\n web reputation falls off the truck in the process.\n<\/p>\n