We basically have 2 sites ( Java /JSP / Apache Webserver) :
something.ca & something.com
The .ca is canadian content, and the .com is american content.
We need users to be redirected based on the ip addreess.
We want US users to get the .com site and Canadian users get the .ca site.
What is the best way to do this (at a webserver level or otherwise ) ?
Please elaborate.
In my web surfing experience, most websites - UPS.com for example - ask the user to select their country site rather than trying to figure it out themselves. They remember the selection in a cookie. Much depends on how voluntary your use case requires this redirection to be.
On the implementation side, I'd use a filter that would check the setting and fire a redirect if need be.
I've used GeoIP from Maxmind and it works well. They have a free version GeoCountry Lite That's 99.3% accurate. the Java API is here I would follow google's practice of having a link back to the original version if you do the redirect.
Check out GeoDirection. It may handle what you want through javascript.
http://www.geobytes.com/GeoDirection.htm
Another option would be to grab the culture from the browser environment settings and map those cultures to countries in your application. Depending on what you are actually trying to do this may not work for you as this will not give you the user's physical location, but will get you their preferred culture. So if a Canadian travels to the US they will still get the Canadian site unless they changed their browser settings for some reason.
There are a lot of IP geolocation APIs out there - I don't know if there's anything good out there that you don't have to pay for:
Using culture settings is an option, but doesn't work in some cases. What if you have a German user in the US who likes his dates etc. displayed in the format he's comfortable with? Doesn't change the fact that he's in the US.
I think that's one of the reasons why most companies simply ask the user and then store that information in a cookie (UPS, FedEx and most major airlines do that). Check out www.lufthansa.com. They actually ask for location and language(to account for countries with more than one official language like Switzerland).
Related
Recently I made my site to reroute the url, based on the language set in the visitors browser. So if a Swedish visitor came to the site, he was rerouted to mysite.com/sv, and an english visitor to mysite.com/en.
Soon after I released this, my Google rank just plummeted. So how did I go wrong here? Is there some common practice to auto-redirect of visitors based on their locale that doesn't hurt SEO, or do I need to set some kind of HTTP code for this to be approved by search engines?
The penalty you've acquired is for cloaking.
Short answer: Don't do redirects yourself - instead use hreflang codes and canonical links, then let the person's Google settings decide.
A Swedish person searching on google.com wants the English version, even if their browser is Swedish. Google does checks where it uses different user agents from different locations to test if you're serving the same content they see to everyone else. When this differs, your site gets flagged for attempting to hide it's true content - hence 'cloaking'.
More here: https://support.google.com/webmasters/answer/66355?hl=en
I currently have a website running under a German domain .de (www.mysite.de)
I'm adding now Internationalization support for English and French languages.
The I18n will be handled by a different URL structure for SEO purpose
www.mysite.de/en will handle english related content
www.mysite.de/fr will handle french related content, and so on
My first question is if from a SEO prospective I should move the German related content under its own path as well (www.mysite.de/de)?
If this is the case, then should I do a 301 Permanent Redirect to the www.mysite.de/de when someone comes to www.mysite.de.
Online I can see different examples.
apple.com for example handles US traffic and apple.com/fr the french one for example.
spotify.com has a 302 Temporary Redirect in place that forwards you to a specific language site like spotify.com/us for US
I know that Google lets you specify somehow the language target associated to a specific URL in your site with something called 'Search Console geotargeting'. This is allowed just for gTLD domains so I can not do it with mine as it uses specific German country domain (.de). I'm wondering if there is something I would need to configure on Google side using the webmaster tool or if hreflang metatag will be enough to signal that for example all pages under /fr are for French related searches
Proper implementation of hreflang is enough in your case.
My first question is if from a SEO prospective I should move the
German related content under its own path as well (www.mysite.de/de)?
Not necessarily. It's a matter of setting correct paths in hreflangs.
I'm wondering if there is something I would need to configure on
Google side using the webmaster tool
Just make sure you don't configure your site for german audience only, leave it to international.
I am designing a pretty big website that will target it's industry on a global level. The site is detecting IP address countries in order to serve content relative to the visitor's country. Basically alot of content will be restricted to visitors in a given country.
The concern I have is that Google doesn't seem to pay too much attention to IP based content, as I read here. They seem to think Google might implement better support for crawling IP based content but aren't sure when and the article is dated Nov 2011.
As a result, I have been considering ways to have Google crawl the site's IP content by country codes like us.site.com or site.com/us still detecting the visitor's country by IP and redirecting to the appropriate location. Im not sure if it's just because I am a little strange at times, but I seem to feel that the subdomain us.site.com seems tidier.
Considering that Google spider ALSO seems to ignore subdomains when there is considerable duplicate content (which may be the case because alot of the content is internationally available), what would you guys recommend?
Should I
Stop being so darn OCD about us.site.com and use site.com/us?
Use subdomains because perhaps while the spider ignores duplicate
content on sub-domains, it won't if there are more unique results?
What about lists of results on my site? Like a category page?
Take a gamble and stick to IP detection only, not using country
codes in the URL and hope for the best that Google will recognise
different content being served on different IP ranges
Thanks in advance
Ok, so i found this which is so far the best explanation I have found, any pointers please feel free to comment
I'm looking for the best URL schema to use for a web app that has multiple versions, namely several languages and a simplified version for use by mobile phones - both aspects can be combined, so there's an English regular and mobile version, a German regular and mobile version, etc.
Goals (in order of importance):
User-friendliness
Search engine friendliness
Ease of development
Aspects to consider:
How should the URLs look like?
How should the user navigate between versions?
How much logic should there be to automatically decide on a version?
I'll describe my concept so far below, maybe some of you have better ideas.
My current concept:
When a new user arrives, the app decides, based on cookies (see below), the Accept-Language: header and the user agent string (used to identify mobile browsers) which version to show, but does not reflect this in the URL (no redirects)
It defaults to the non-simplified English version
There are prominently displayed icons (flags, a stylized mobile phone) to choose other versions
When the user explicitly chooses a different version, this is reflected both in a changed URL and a browser cookie
The URL schema is / for the "automatic" version, /en/, /de/, etc. for the language version, /mobile/ for the simplified version, /normal/ for the non-simplified one, and combinations thereof i.e. /mobile/en/ and /normal/de/
mod_rewrite is used to strip these URL prefixes and convert them to GET parameters for the app to parse
robots.txt disallows /mobile/ and /normal/
Advantages:
The different language versions are all indexed separately by search engines
Cookies help, but are not necessary
There'S a good chance that people will see the version that's ideal for them without having to make any choice
The user can always explicitly choose which version he wants (this makes the /normal/ URL necessary)
Each version has an URL which will display exactly that version when passed to others
/mobile/ and /normal/ are ignored by search engines; they would only be duplicate content.
Disadvantages:
Requires heavy use of mod_rewrite, which I find rather cryptic
Users could send their current URL to someone and that person, when visiting it, could end up seeing a different version, which could cause confusion
There is still duplicate content between / and /en/ - I can't disallow / in robots.txt - should I trust the search engines not to penalize me for exact duplicate content on the same domain, or disallow /en/ and accept that people coming to / via a search engine may see a different version than what they found in the search engine?
I suggest subdomains, personally.
I wouldn't include the mobile at all - use the useragent to determine this, and possibly a cookie incase the user wants to view the full site on their mobile (think how Flickr and Google do it). But for languages, yes - primary language at http://mydomain.com/, secondary languages at i.e. http://de.mydomain.com/ or http://fr.mydomain.com/
I am unclear why you would want to incorporate any kind of what you call versioning information, such as accept-language or user-agent, specific designation in the URL scheme. The URL scheme should be indicative of the content only. The server should investigate the various request headers to determine how to retrieve and/or format the response.
I am using an IP location lookup to display localised prices to customers depending on whether they are visiting from the UK, US or general EU and defaulting to the US price if the location can't be determined.
I could easily force the system to believe I'm from a specific country for testing but still there is no way of knowing for sure that it's displaying correctly when a visitor from abroad accesses my site. Is the use of some proxy the only viable way of testing a site like this? If so how would I go about tracking down one that I can use to test my site from various countries of origin?
You should be able to achieve that by using proxies. http://www.proxy4free.com/page1.html has a bunch. That site just came from a Google search; I've never used proxies like this before though, so there may be better sites out there.
This is not about how to test, but rather how you identify your visitors.
Instead of using IP-lookup to determine their geographical location, you should instead grab the information about the locale they use from the useragent string.
F.instance, I'm a norwegian, and when I go to useragent.org I see that my browser sends "nb-NO" as the language my machine uses.
You can easily use that to customize currency, dates etc on your site.
If the website is indexed in Google's cache, you can visit the google with the proper URL address. ex. http://www.google.co.uk/
And see if it's displaying properly in the cache.
#Frode:
Checking system locale in iseragent string might be misleading.
I go to Canada, and set my system locale as French. So it might show the user EU prices as opposed to showing US price. Many such cases are possible where locale wont give accurate info about the end users desired "price class" in this particular application mentioned.
=AD
If you want to use geo-ip location to detect a user's language, using a proxy probably is the best way to do so.
There are a lot of lists of open proxies on the web, mostly listed with the countries. Google has quite a lot of search results on this topic. Of the top results, I have used SamAir to test some stuff before.
Searching for a working open proxy with an acceptable speed in the correct country can be a tedious task. Also keep in mind that you should not use any these proxy servers to submit any sensitive data, because you never know who runs them. This could be a kinda trustworthy ISP (ie. not from GB ;D), a honeypot to collect data, or an illegal open proxy hosted by some trojan.