Hey there

To Quote Google on this, with the issue of ASCII and UTF encoded characters, like Arabic:

"Yes, we can generally keep up with UTF-8 encoded URLs and we’ll generally show them to users in our search results (but link to your server with the URLs properly escaped). I would recommend that you also use escaped URLs in your links, to make sure that your site is compatible with older browsers that don’t understand straight UTF-8 URLs"

So their recommendation would be to have both URLs available (the English and the Arabic) in order to support all users.  So the fact you already do this is a good thing.

The next step would be to make sure you are handling duplicate content correctly.  If the Arabic and non Arabic URLs are linking to a page with the same content - Google _should_be able to recognise this as the same page and not penalise you for duplications.  So if the Arabic URL and the "escaped URL" (ASCII/English equivalent) both go to the same page, you should be fine.  I've experienced this quite a few times with Turkish websites, for example, that also have UTF encoded characters.

However, you can eliminate the risk further by adding a canonical tag to each page.  As far as I am aware, the canonical tag will support Arabic characters and so, on each page of the site, add a canonical tag that points to that page.  For example, with the URL above, you would want to place a canonical tag like:

You can read more on canonical tags here: http://moz.com/learn/seo/canonicalization

Do be aware that for XML sitemaps, the URLs in the sitemap need to be URL-escaped - that is to say, UTF encoded URLs need to be made into their ASCII equivalent.  You can read more about that in this Google guide to using non-alphanumeric characters in Sitemap URLs.

Hope this helps.

To add to Matt's good earlier response, the TLD extension that you use (.com, .net, .info) will have a minimal impact on your ability to rank well and the site's overall SEO.  For ranking specific websites in specific countries (and regions like London etc), Google looks at a bunch of more important factors, such as server location, schema, hreflang setup, citations, NAPs and so on.

Hi Luke

Those hashtags are internal anchors and they are quite commonplace and so Google handles them quite well.

What I would test would be how the search engines are crawling this page?  What should be happening is that the search engine can see all of the text at all times.  You can test this by entering the URL into the SEO Browser Tool - enter it there and click "simple" search (as it's free).  What do you see?  Does all of the page content show up?  If so, Google will be able to see the page.

Now there are a couple of things to consider.  There has been talk that Google will no longer index "click to expand" content.  I've seen conflicting reports as to whether this has been implemented, but if it is on Google's radar it may be wise to avoid the tactic.  From what I can gather, it looks like your page might be acting this way at the moment, in which case you may want to change that.  If your website is using internal anchors (hashtags) to merely take the user from one section of the page to another (while never hiding the content) it would be fine.

Finally, if you're using Google Analytics, by default GA will register a new page visit each time a hashtag link is clicked.  Similarly, it will not show you hashtags have been clicked and show them as visited URLs.  So, for example, if someone visits www.example.com/page and clicks 3 hashtag links, that will register as 4 page views to www.example.com/page and nothing else.

However, you change that and here's a good guide on how to do so.

Hope this helps.

It certainly used to be a bigger factor.  And the annoying thing is that Google still has older videos up saying as much.

However, with so many new TLDs, server locations and CDNs in particular, I think the impact of server location has diminished quite a lot.  For example, on my UK sites I always try and use UK servers.  However, I often use cloudflare on them, which will be either US or Central Europe based.  It hasn't affected their performance.  Google alludes to this:

“Server location (through the IP address of the server) is frequently near your users. However, some websites use distributed content delivery networks (CDNs) or are hosted in a country with better webserver infrastructure; so, we try not to rely on the server location alone.”

So I wouldn't say a server's location will hinder a website's ability to rank in a certain country.  The only way that it might would be related to speed.  Obviously, the further away your user is from your server, the slower the website's response might be, and speed is considered to be a ranking factor.  However, if you get any decent hosting solution, the speed difference would also be negligible.

No problem Lee!

This is also a good article from SearchEngineLand on international SEO, including some pros and cons on different approaches.

Hi Lee

Would I be right in saying that the client would like to rank in both UK and US?

If so, this is possible.  What I would recommend is to create a new geo-location subfolder for the US site.  Something as simple as website.com/us/ would do.

From there, you would set up the US subfolder as basically its own website.  That starts with adding the right kind of hreflang schema code for the subfolder.

There is a fantastic guide here on Moz by Aleyda Solis on how to set up an international SEO structure.  You can find it here.

This hreflang generator tool, also from Aleyda, can help you generate the right code to add to the subfolder.

From there, as mentioned you're basically treating the subfolder as it's own individual site.  That means you can build new links to it, you should have unique content within it, and you can even set up its own individual GWT account - meaning you can set the geolocation settings in there too.

The benefit of this approach is that it would allow your client to keep the current site as-is, and not jeopardise it, while also setting up a site for the US audience.  Of course, you could do exactly the same thing on a new TLD - but that might be difficult as you're using the .com already (and besides, I like global sites using a .com /country/ subfolder setup)

Hope this helps, let me know if you'd like anything clarified.

Hi Ethan

In theory - yes it could.  We know that Google looks at a domain's Class-C IP level (at least - now that Google is a registrar it may extend to the full IP) when judging its quality.  If a site is in a "bad neighbourhood" - ie sitting on an IP range with a number of 'spam' sites - then theoretically it could be affected, as a kind of guilty by association.

However, in reality I have some doubts as to whether this would happen.  The fact is that the vast majority of the web uses shared hosting (particularly sme's) and so good sites are invariably always going to be mixed in with 'bad' sites.  And what's stopping me from deliberately making a bad site on your IP in order to 'poison it'?  I'm no way near that evil, but someone might be.

What I'm getting at here is that it seems extremely unlikely that there is a manageable way to differentiate these sites efficiently - which leads me to believe that having your spam site on the same IP as some 'good' sites _shouldn't _make a difference.

What you can do to reduce this risk even further would be to make sure the 'spam' site doesn't link to any properties of yours that you want to protect, to nofollow those links if feasible (not sure what CMS you're using but WordPress has a few plugins that would do this on bulk) and, if it isn't required, noindexing the site would pretty much get rid of all risk completely.

Hope this helps!

Hey there

Not sure if this is the article you read, but Yoast wrote a great article on blocking jquery and CSS and how it might affect your SEO.

The recommendation was not to block them with robots.txt.  This is reiterated by a Google-r at the recent SMX conference has said:

“We recommend making sure Googlebot can access any embedded resource that meaningfully contributes to your site’s visible content or its layout”

I'd recommend that you unlock these.

Hope this helps.