Location of your server isn't really important - check https://www.seroundtable.com/seo-geo-location-server-google-17468.html: "For search, specifically for geotargeting, the server's location plays a very small role, in many cases it's irrelevant. If you use a ccTLD or a gTLD together with Webmaster Tools, then we'll mainly use the geotargeting from there, regardless of where your server is located. You definitely don't need to host your website in any specific geographic location -- use what works best for you, and give us that information via a ccTLD or Webmaster Tools."

Similar message here: https://support.google.com/webmasters/answer/182192?hl=en:

• Server location (through the IP address of the server). The server location is often physically near your users and can be a signal about your site’s intended audience. Some websites use distributed content delivery networks (CDNs) or are hosted in a country with better webserver infrastructure, so it is not a definitive signal.

Specifically on CDN's - John Mu indicated
"At any rate, while moving to a CDN may result in small temporary fluctuations, making your site faster will frequently help your site much more. Some studies have shown that the faster your site is, the longer visitors will stay, and that's generally a good thing :-). As I mentioned above, if you're seeing significant changes in ranking, then I'd look for the issues elsewhere" (https://www.seroundtable.com/google-cdn-13117.html)

Dirk

No personal experience with it - but seen already some cases on the Q&A where it generated problems. In one specific case all traffic outside Ireland was shown a default language page - inside Ireland the full content was available. None of the content was indexed by Google until the ip blocking was removed.

The note on the page you mention already gives a hint:

IMPORTANT: We continue to support and recommend using separate locale URL configurations and annotating them with rel=alternate hreflang annotations.

If your website has pages that return different content based on the perceived country or preferred language of the visitor (i.e., you have locale-adaptive pages), Google might not crawl, index, or rank all of your locale-adaptive content.

You can try it but you run a huge risk that your content will not be indexed or only partially indexed. Better to use the hreflang solution - as propose by Google.

Dirk

To add to the previous comment - crawl delay is ignored by Googlebot. Check http://tools.seobook.com/robots-txt/

It can be used to limit the speed for the bots - it is however not part of the original robots.txt specification. Since this value is not part of the standard, its interpretation is dependent on the crawler reading it

Yandex: https://yandex.com/support/webmaster/controlling-robot/robots-txt.xml#crawl-delay

Didn't find more info for Bing (they mention it here but do not provide additional info: https://www.bing.com/webmaster/help/how-to-create-a-robots-txt-file-cb7c31ec

If you want to limit the speed for Google bot you have to do it in Webmastertools.

Dirk

Maybe Google is desperately trying to find a page which is replying within in reasonable delays... Time to first byte is horrible: http://www.webpagetest.org/result/151104_SQ_WXJ/1/details/

Apart from the speed issue - the 301 as proposed by Justin is the best solution;

Dirk

Point 6 seams to be the most important one - make sure they update all the logo's (most of the results I get seem to be affiliated with your company - so this shouldn't be to difficult to do).

Example: http://drellen.com/realself-reviews/ - the logo is changed in the body - but the bigger logo is still the old one.

On your site - rename your logo to real-self-logo.png & make the alt "Real Self Logo" to make it very obvious that the image = your logo

Dirk

Hi

Google is being nice & is doing exactly what you ask it to do.

Example: http://www.customlogocases.com/custom-motorola-phone-cases-printed-logo/ - in the source you put:

rel="canonical" href="http://www.customlogocases.com/custom-motorola-phone-cases-printed-logo/?limit=all"/>

So - you ask google to show http://www.customlogocases.com/custom-motorola-phone-cases-printed-logo/?limit=all in the search results rather than http://www.customlogocases.com/custom-motorola-phone-cases-printed-logo/

Update the canonical & remove the limit=all & the problem will be solved.

Dirk

There is a very useful & detailed post on site migration on Moz - I used on two previous migrations and it worked great (no traffic drop at all) - check https://moz.com/blog/web-site-migration-guide-tips-for-seos

Dirk

Don't have hard evidence - but from my personal perspective: My browser is set to be-nl (Belgium)- when I'm in the Netherlands (nl-nl) I am automatically redirected to google.nl & all the results I get are from the Netherlands (even for international sites were Dutch Belgian versions exist). Browser language will have an impact - but in my opinion proximity will be more important.

Dirk

According to Google you should put your site in quarantaine (status 503) and make it available again when it's cleaned (in your case - relaunched). Source: https://support.google.com/webmasters/answer/2600719?hl=en.

Personally, I would also consider the option to clean your current site: 3/4 weeks is a very long time and it could have a negative impact on your rankings.

Dirk

We did something similar in the past. Changing the servers won't make any difference as long as the front-end part isn't changing. Google doesn't care if your site is running on one or multiple servers, or if two parts of the sites are running on different technology, as long as the user experience is not affected.

If you are changing your URL structure at the same time - there are some things you will have to check. There was a post on Moz a few years ago on site migrations that could help. Basically you will have to check that all your current url's are properly redirected to the new ones and that performance of the new site is ok.

Dirk

If the markup passes the test it's valid markup & meets Google's guidelines. It would seem a bit ridiculous for Google to develop a test if the results of the test were not valid.

Never heard that markup needs to be put in one place. Most of the time the markup is inserted within your HTML so you will have several blocks of markup (unless you use the JSON-LD markup).

Dirk

Hi

You can check the implementation in Webmastertools https://developers.google.com/structured-data/testing-tool/ - or in a tool like https://webmaster.yandex.com/microtest.xml

I checked a branch page - for Yandex some of the fields are not correct (url / local address / local phone missing) - but most of it seems ok. For Google everything was ok.

You could check the other pages as well using these tools.

Dirk

It is a "faux pas". The problem with the solution you propose is that the canonical url you are pointing to doesn't exist (domain.com/awesome-page has status 302 = temporarily moved to another location). Check http://googlewebmastercentral.blogspot.be/2013/04/5-common-mistakes-with-relcanonical.html  - best practices

• A large portion of the duplicate page’s content should be present on the canonical version.
• Double-check that your rel=canonical target exists

With the canonical you indicate that you prefer that domain.com/awesome-page is shown in the search results rather than get.domain.com/awesome-page - Google will however not put pages with 302 status in the search results

Not sure if it's possible - but the best solution would be to maintain both pages & put a canonical on unbounce.If that is not possible - just leave it as it is. The moment you stop working with unbounce you 301 these pages to the corresponding pages on the main domain.

Dirk

Unfortunately Google is not always using the meta description when showing your site in the SERP's - check this article: https://moz.com/blog/why-wont-google-use-my-meta-description. Basically in your case Google decided that the price of the training is more relevant than the content you provide in the meta description. Try rewriting your meta description - or just accept leave it like it is (if click rates are ok)

You might want to consider to translate the alt texts on your images - they're still in Dutch (which is also the reason why you see these Dutch words appearing in the snippet.

Also note that Google doesn't really like content which is "hidden" under tabs - https://www.seroundtable.com/google-hidden-tab-content-seo-19489.html - you can still use anchors - but it's better to show all the content upfront.

Dirk

Great - just checked the robots.txt with web-sniffer & shows a 200 status now so crawl shouldn't be an issue.

Dirk

To remove the trailing slash - check http://stackoverflow.com/questions/21417263/htaccess-add-remove-trailing-slash-from-url & try one of the answers proposed there. Than add the 2 lines from the 2nd example in my first answer.

Dirk

Not sure what you want to achieve with these lines - but both url's are still accessible.

If you want to redirect www to non-www use this:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^www.(.)$ [NC]
RewriteRule ^(.)$ http://%1/$1 [R=301,L]

(http://stackoverflow.com/questions/234723/generic-htaccess-redirect-www-to-non-www)

Other way round:

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www.
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]

(http://stackoverflow.com/questions/12050590/redirect-non-www-to-www-in-htaccess)

Dirk

Your robots.txt renders in a browser - but from technical perspective it generates a 403: Forbidden (check http://www.cartronix.com/robots.txt with web-sniffer.net)

Moz will not crawl if your robots.txt is returning a 403 (see answer from Chiaryn Miranda / Moz on https://moz.com/community/q/without-robots-txt-no-crawling

Quote: "The only commands from the http responses that we consider to block our crawler from accessing a site would be a 403: Forbidden error or a 5xx error."

Dirk

Hi,

You might want to try this solution:

Redirects domain.com/file.php to domain.com/file

RewriteCond %{REQUEST_FILENAME} !-d                      # is not directory
RewriteCond %{REQUEST_FILENAME}.php -f               # is an existing php file
RewriteCond %{REQUEST_URI} ^(.+).php$                    # request URI ends with .php
RewriteRule (.*).php$ /$1 [R=301,L]                                 # redirect from file.php to file

Source: http://stackoverflow.com/questions/1992183/how-to-hide-the-html-extension-with-apache-mod-rewrite (2nd answer)

Dirk

Hi,

In the example you give - only the first part is coming from Wikipedia. The other info could come from Wikipedia - but it could as well be collected from other sources across the net. You can't control the information which is displayed - you could use the feedback function (bottom right) to correct the information if there are mistakes - but there is no guarantee that Google will add/update the information.

Dirk