Hi,

If you have a .com and a .co.uk then it helps to have an IP address in the countires you are targeting. .com hosted in the US in this aspect.

Duplicate content is definitely going to be an issue. To address this you will have to re-write your content with a flair of the regions you are targeting and where you are based in that country.

You can make use of a seperate blog which will help towards faster crawling of your sites and also help in generating different content. Bear in mind you will also need to use of a seperate link building strategy specific to the country you are targeting.

Hope this helps.

iDeaTurf Consulting

Why don't you try us out? Our integrated marketing solutions cover SEO as well.

Hi there

This internationalisation / SEO challenge is something we're focusing on right now for this site. We have a US office/business in New York and want to create a version of the site that is more relevant to US users by surfacing the more US-focused content etc. but without damaging our search rankings. 

My take is that domain names, and where you host the site make very little difference at all for search rankings. We moved our hosting from the UK to the US about 18 months ago and it hasn't made the slightest difference to our US search rankings. It's all about the content and your inbound link profile - you might be hosted anywhere in the world (and we're now 'in the cloud' so nowhere and everywhere) but it's about how Google figures out for whom you are most relevant. 

Below is quite a bit more detail on our approach (not yet done). There is some important technical stuff in there about what redirects to use etc. The bottom line is that you should be able to avoid duplicate content issues but you can't choose to rank on two URLs with the same content - unfortunately you can't split 1 page into 2 and end up ranking on both in the short term.

Phase 1: Introduce localised URLs

We will split the Econsultancy site into two separate localised sites, one at http://econsultancy.com/uk and the other at http://econsultancy.com/us, duplicating all existing content across both sites.

Each existing non-localised URL will dynamically redirect (HTTP 302) to a corresponding localised URL. Visitors whose contact address or IP places them in the UK content region will be redirected to the UK version of the URL; likewise visitors from the US content region will be redirected to the US version. For example, a US visitor to http://econsultancy.com/blog will be redirected to http://econsultancy.com/us/blog. 

Both localised versions of a given page will have a <link rel="canonical"> tag pointing to that page's non-localised URL so that Google will treat this as the official URL for both localised pages and concentrate their PageRank into one search result. This means that Google will effectively only pay attention to the content on one of the localised versions of the page, which is acceptable since that content will be identical between localised versions.

We will set up separate UK and US sitemaps and register these in Google Webmaster Tools as being targeted at the UK and US respectively. This will tell Google about all of the new localised URLs, although these URLs shouldn't show up in Google search results as long as we have the <link rel="canonical"> tags in place.

As far as possible we will ensure that all internal links are updated to reflect the version of the site which is currently being viewed. For example, all links to reports within http://econsultancy.com/uk/blog should use URLs beginning http://econsultancy.com/uk/reports. This may involve automatically rewriting URLs which appear in CMS content (e.g. blog posts).

The purpose of this phase is to gently introduce the new localised URLs to Google and our customers without impacting our search rankings. Link-building campaigns can begin to use the /uk and /us URLs; customers who link to us from blogs and Twitter will increasingly link to localised versions of URLs instead of the non-localised versions.

Phase 2: Differentiate localised content

We will work incrementally to differentiate the US site content from the UK site content. For example, we may rebuild http://econsultancy.com/us/training to better reflect our US training offering.

Once the UK and US versions of a particular page have different content, we will remove the dynamic redirect from the corresponding non-localised URL and replace it with a permanent redirect to the UK version of the page. We will also remove the <link rel="canonical"> tags from the localised versions of the page. This will allow the UK page to retain its existing PageRank and effectively introduce the US page as new content on our site which will need to accumulate its own independent rank. (Any inbound links to the US version of the URL established during Phase 1 will contribute to the rank of this new page.)

For example, all visitors to http://econsultancy.com/training will be redirected to http://econsultancy.com/uk/training, and the latter URL will begin appearing in Google search results; anybody who wants to see the new US training page will have to explicitly visit http://econsultancy.com/us/training rather than be redirected there automatically.

When we introduce a page which exists only on the UK or the US version of the site, we will add a permanent redirect to this page on the corresponding non-localised URL.

For example, if we introduce a page at http://econsultancy.com/us/training/faculty which has no corresponding UK version, we will set up a permanent redirect from http://econsultancy.com/training/faculty to http://econsultancy.com/us/training/faculty.

In the CMS we will provide control over which pieces of content appear on which localised site. We will introduce checkboxes on managed content (e.g. reports) which allow staff to specify whether that content should appear on the UK site, the US site, or both. Content appearing on both sites will allow (but not enforce) two different descriptions, two different sets of attached files etc in order to present a different appearance on each site.

Some filtering may occur automatically and/or by default where we have the data to support it.

For example, we are able to only show UK events on http://econsultancy.com/uk/events by default, with the option of overriding this for events which we consider suitably international (e.g. Peer Summit). We will choose sensible defaults for browse/search filters across the site, e.g. the country filter on http://econsultancy.com/us/jobs will default to United States, although jobs in other countries will still be visible if the filter is changed.

We will try to avoid introducing a site-wide mechanism for switching between UK and US versions of the site, in favour of using contextual in-page links to achieve this where necessary. For example, on the UK training page: "Not in the UK? Please see our USA training offerings."

The purpose of this phase is to introduce new US-focused content without compromising the search rankings of existing pages.

@John 

My sense is that the where the site is hosted is a very weak signal to Google for local SERPS. The domain extension is much more important but even more important are factors like language/content (is the content of the site in the relevant language?) and the link profile of the site. 

Many sites (including this one) are increasingly in the cloud (in our case, on Amazon) even most ISPs are now migrating their hosting services into the cloud and providing edge serving etc. to optimise speed by country and so on. But the point is that the sites aren't really anywhere geographically. 

I can recommend Greenlight for this type of work. I'm an ex-employee, so am probably biased, but they do manage this type of project well. They built, managed and optimised a full domain portfolio for hotels.com when they were branching out from the US into Europe. They understand the strategy behind this type of work, so going the opposite way (from UK to US) should not be a problem for them.

And if you speak to Ian, tell him he owes me a pint...!