I have a restaurants directory Rails app in which I need to categorize the content (restaurant description pages) by cities. The cities are stored in the database. The questions that I have:
What is the Rails way of doing this? Is it best to add a scope in routes as for ex. the language locale? For ex.: example.com/en/new-york/restaurants...
Is it better to translate, transliterate or leave the city names as-is provided that the content is targeted for the locals. For ex.: example.com/moscow vs example.com/moskva vs example.com/москва in terms of "Rails-wayness" and SEO friendliness?
In terms of SEO, is it better to use subdomains (new-york.example.com) or subdirectories (example.com/new-york).
I would appreciate if you could share your experience about this matter!
You probably don't want the locale/language to be embedded in the URL.
For SEO purposes you probably want to pick one version and go with it all the time. That way you're aggregating all of your "link juice" to one URL. Some search engines will penalize you for having the same content at multiple URLs.
This is a good question, and I'm not entirely sure. I'd be kind of surprised if either one makes a huge difference. (It wouldn't be the first time I've been surprised...)
Related
Let's say I have a website that has 2 languages, one uses Latin and the second one Cyrillic transcriptions in URLs.
For example:
example.com/link
example.com/ссылка
My question is which is more user and SEO friendly, if I leave them as is or if I add the language prefix, so they'd become
example.com/en/link
example.com/ru/ссылка
I understand that such subdirectories should be used if I have languages that are similar and then the user wouldn't be confused, but does that also apply in my case?
It's better to use the second one for better SEO results.
example.com/en/link
example.com/ru/ссылка
Google likes the tree-like structure. Of course you can use the main language without prefix.
Also it's better to have all languages in one domain:
domain.com/en
domain.com/ru
not on subdomains like this
en.domain.com
ru.domain.com
Wish you luck.
What is considered the best strategy for URLs of translated websites? Something I see happen frequently is:
http://example.com/english-slug.html
http://example.com/de/english-slug.html
http://example.com/fr/english-slug.html
This has the (minor) advantage that a user can manually switch to another language by modifying the URL. The disadvantage seems to be that the URL consists of a slug in the wrong language for every page not in the default language. That would cause a SEO penalty, I think.
The alternative would be to translate the slugs as well and optionally omit the language identifier as well:
http://example.com/english-slug.html
http://example.com/deutscher-slug.html
http://example.com/slug-francois.html
Some languages do not really lend themselves to be 'sluggified', such as Russian, Chinese and Arab. You'll end up with transliterations that make little sense.
I think you should use language tags and translated slugs:
http://example.com/en/hello-world
http://example.com/de/hallo-welt
Why language tags? To avoid collisions.
Sometimes you might want to have the same slug for different languages (for example, "team" in English as well as in German).
Why translated paths? For better usability.
Not all users understand the "default" language, and depending on its script, they might not even be able to type/remember/dictate the slug. (It doesn’t make sense in the first place to use human-readable slugs that only part of your users are able to understand.)
Yes, it would be a "(minor) advantage that a user can manually switch to another language by modifying the URL". But it’s unlikely that users or search engines would expect this to work (see my related answer on Webmasters). So you would gain little (URL hacking for advanced users) and lose much (bad usability for users using the non-default language).
That said, it would still be possible to enable this URL hacking feature in most cases: When users change the language tag de (in /de/hallo-welt) to en (/en/hallo-welt), you could check if it exists (if yes, show it), and if not, check if there exists a slug "hallo-welt" in any language, find its English translation and redirect to it (from /en/hallo-welt to /en/hello-world).
Another way is setting the language as a query string parameter, such as:
http://example.com/hello-world?hl=en
http://example.com/hallo-welt?hl=de
for example Google Flights web site uses this method.
The best solution, if you can afford it, is to send the document with the right name, that means, using the right word on each language.
Of course each document should be sent with the respective language setting on the headers.
For storing them, you can use folders and let the web server choose the right document according to the language preference; or you can use server side technology, like PHP, perl, etc to send the document and adjust the URL.
In any case, you have to have a default language to be sent when you don't have the requested language.
If you can't or don't want to send document with the right name, using subdomains is the best next option. This option, is not as common as adding the language after the domain, and that means, that people may not be used to it, although, it has some advantages, for instance;
Each language behaves like a whole new URL/site (almost).
People feel like visiting a dedicated site, not a subsection where the second language is relegated and may fail at any moment (some content may not be translated).
Some people are not familiar with their two letter representation of language, but everybody knows how his language is called and spelled.
It generates cleaner URL's.
It is believed that having subdomains increases appearance on SERPs (I don't have knowledge of this and it may have changed).
It's easier to have different layouts if you want to.
It's easier to set different servers according to language.
Of course subdomains have some disadvantages, like:
A bit more work to set properly from the server perspective.
Less collaboration from the part towards high ranking.
Some people may not expect it but expect a subfolder.
Next would be the subfolder option, as you show on the question. This is the recommended way if your main perspective is SEO since all the relevance of the domain stays on that same domain and each language helps to a common "pot" of ranking.
My perspective when choosing a solution, is never SEO, under any circumstance. Whatever ranking I get is due to the content itself and the best use I can give to technology. But I understand that my point ov view is not the most common.
One thing to consider also, is that you should provide some kind of explanation or help the user so he can take actions to change to the preferred language. It may be using icons, a tooltip, or any other method that works for your design and verbosity.
One thing to avoid, and you didn't ask for it, but is related; is using language autodetection. Lots of times, the user is in a different country or using a version of a browser that has a different language from what he can understand and the autodetction just makes a big mess. Offer the default version and a clear way to change it.
What is the optimal SEO strategy for storing a blog?
1) In a directory: www.example.com/blog
2) In a separate domain: www.exampleblog.com
3) In a sub-domain: www.blog.example.com
With a directory, the repetitions earned by the blog are directly transferred to the main domain (www.example.com). With a separate domain, any links to my site would count as backlinks.
I'm leaning towards option 1. What other pros and cons should I consider?
This is comprehensive, Sub-domain versus sub-directory (via Webmasters SE). It was updated in November 2012. Look at this answer too, as it specifically describes, with a huge chart, what effect sub-folders (meaning sub-directory in this context) versus sub-domains have on SEO, and how use of reverse proxy can affect blog SEO. The gist of it is that a sub-domain is preferable to a sub-directory.
EDIT
I may have mis-read the question. If the choice is between
mywebsitename.com/blog
versus
mywebsitenameblog.com
then I would definitely recommend using the sub-directory. This is why:
If you use an entirely different domain name, even if it is your website's domain with the four letters blog concatenated, it will be confusing to users, as no one does that!
You will need to pay for a second domain and that costs more money.
You'll be doing something that is inconsistent with typical website naming conventions, which I'd avoid if I were concerned about SEO and were developing an e-commerce website. I don't know if it will negatively affect SEO ranking, but it won't help, as it will be an entirely different domain name, without any of the positive reputation or credibility of your primary domain name.
It will be four characters longer, which is never good, as it will be less convenient, more difficult to remember, etc.
Better yet, use a sub-domain of your primary website for your blog. To summarize, you should do the following, in order of best to worst:
blog.mywebsitename.com
mywebsitename.com/blog
mywebsitenameblog.com
There is slight difference depending on which search engine is going to look at and add or subtract value to your blog on basis of this decision.
Read this blog post from Matt Cutts. or Watch this video for summary
If you go for another domain then search engine expect it to be separate content and not much relation in terms of your main domain rank.
I would install the blog in sub-directory called blog and stop worrying about actual juice from search engines as it may vary from one to another.
I have set up a simple Rails app based on Post, Comment example from the default documentation. -> http://edgeguides.rubyonrails.org/getting_started.html
What would be the appropriate way of localizing existing content from these Posts ?
If I assume that Post has a :title and "content, and I would like this content to be entered not only in English, but also in German and Dutch, then how would I achieve this if I want the end result to look similar to this :
http://0.0.0.0:3000/en/posts.json to get all posts in English and respectively,
http://0.0.0.0:3000/de/posts.json for German?
I havent found a gem yet, that would support such multilangual content.
I have seen doe, many existing ways to do so, mostly in applications like Wordpress or Drupal, which are not rails based.
I guess the preferred way would be either storing EN and DE posts in seperate tables (but then how to add new languages?), or to place all translations within the same database table, but seperate translations in a different way, but how to get them easily out in json in the right language?
I am really confused and puzzled why such a "common" problem, is not solved in Rails by default, or maybe I am simply looking in the wrong place.
Globalize3 will do what you want to do. It stores all translations for a particular model in a separate table, with a locale column identifying what the language of a particular translation is. This makes it possible to add new languages without having to migrate the database, so the approach is very scalable.
There are other gems for translating content as well, e.g. Traco is one that I know of, but this one stores the translations in the same table as the model, so when you add new languages you have to migrate each model table. I personally prefer the Globalize3 approach, although it makes the gem itself more complicated internally.
My site, Rap Genius, explains rap lyrics. I want to create a new site, Rock Genius, that explains rock lyrics – otherwise it'll be the same (same layout, same DB schema; like Serverfault is to Stackoverflow)
What's the best way to do this?
Approach 1: Fork the code
Fork the Rap Genius code, change the relevant parts (e.g., "Rap" -> "Rock"), create a new database and go to town.
Pros: Can get it working quickly
Cons: It'll be somewhat painful to add a feature to both applications. Also it'll be impossible to give Rap Genius access to Rock Genius' data at the DB level
Approach 2: Keep it a single application
Whenever a request comes into my application, check the domain. If it's rapgenius.com, set the SITE_NAME constant to "rapgenius". Create a genre field on user-facing entities (songs, blog posts, etc) and update my queries to use the correct genre based on the SITE_NAME
Create a layer of abstraction above user-facing strings to that I can write <%= welcome_message %> instead of Welcome to Rap Genius! and have welcome_message() take SITE_NAME into account
Pros: Lots of flexibility
Cons: Lots of work!
Thoughts?
The second approach sounds better to me.
You've already highlighted the main pros and cons - it will definitely be more work, but will be much friendlier to maintain. Is there any chance of a third, fourth, fifth site? If so, there's no question that this is the right way to go.
You'll likely also be able to share user accounts, reputation, and any other kind of community based functionality more easily.
It might be worth looking at Rails i18n stuff for 'translating' static text, based on the domain name. That way you could avoid writing helper methods for every string you want to display.
Then you should be able to 'franchise' the site really easily - add translations of static strings, a handle for the new domain, and maybe some site specific images or CSS and you're done!