If I have a commercial site belonging to a Japanese company which will use Katakana or Kanji (non ASCII characters) for the keyword they wish to obtain good search results in google, does it still matter to put the closest english word on the site DNS Name?
like:
if the search word is "homepage" in Katakana: ホームページ
Will the the DNS name have an impact on the results?
Is it better, does it have any effect having a DNS Name which includes "homepage"?
Thanks,
Ric
What name will bring higher hit counts is kind of an art, not a science.
Since the IDN (International Domain Names) support is still weak in a lot of tools I would think that a Japanese DNS name would bring less hits than an English one.
On another side, in my experience the content and proper tagging of the content is way-way more important than the domain name itself to attract traffic.
DNS international domains are translated to unreadable ascii, so I guess it doesn't make sense to use it for SEO.
Related
Some people will reply that domain names are not case-sensitive. In the new Unicode world this is no longer true.
(Source)
I thought one of the steps in the Unicode > Punycode conversion was a "normalisation", which rendered domain names lower case.
For old-fashioned ASCII-based domain names, Yes, domain names have been and continue to be case-insensitive.
To quote RFC 1035, DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION:
Note that while upper and lower case letters are allowed in domain names, no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical.
For example, all of these represent the same domain:
example.com
Example.com
EXAMPLE.COM
EXampLE.com
In modern DNS, we now have Internationalized Domain Names (IDN) which allows Unicode characters. The problem is that defining upper- and lowercase can be tricky in some languages and character sets beyond ASCII (Unicode is a superset of US-ASCII).
The intent of domain names is to be case-insensitive, but there may be complications with particular characters in particular scripts of particular human languages. So there is no simple YES or NO answer to your question.
If using non-ASCII domain names, you should read:
Internationalized domain name on Wikipedia
Domain Name System (DNS) Case Insensitivity Clarification Official spec (IETF RFC 4343)
WRONG: URLs are still case insensitive, even for IDN.
CORRECTION:
The question was about IDN: "Are IDN domain names case-sensitive?"
My initial answer is wrong, and does not clearly answer the question.
It brings URLs into the mix.
The domain name part (IDN) of a URL is case-insensitive.
The other elements might be case-insensitive or not. It depends on many things, and in general is not predictable.
For instance the path part would normally depend on the OS or even the file system hosting the site (on MacOS you can format the drive as case insensitive or not)
But these days you can have some of these paths "hooked" to answer RESTfull APIs.
So it depends on how the "hook" is done.
Similar for other elements (user, password, parameters, parameter values)
I am building a small application for an english speaking client in Japan. As part of the app, users need to be able to enter their address. Unfortunately, I can't find any reference for how addresses are usually handled in an online form.
I know that there are different combinations of wards/prefectures/cities; do these all usually have their own field in a database? Is it standard for all of that to go into a general "city" type of field? What's the standard UI for this sort of thing?
The Universal Postal Union has compiled info on address formats in different countries. See also an unofficial guide to postal addresses.
But as a rule, internationalization of software typically means that for postal addresses, you avoid imposing any specific format. Instead, you would use a free-form text input area, of sufficient size. There are often many forms of addresses used in a country (and Japan is no exception), and normally you need not enforce any specific format – instead, you expect people to know their own address and how to enter it so that postal services can understand it.
it depends on what you have to do with the address:
if you have to:
check for obligatory fields
validate fields, or
query for city, prefecture, postal code, etc.
then you should use separate fields. UI: a form with text-inputs (and maybe even menus).
do not use more fields than necessary, so if you don't have any of the mentioned needs, just use a text-field (UI: textarea).
The first part of a Japanese address is easy: Todofuken will either be 2 or 3 characters, followed by either "都","道","府" or "県". Where it gets tricky is the rest of the address since smaller areas don't always divide their cities neatly.
What I've seen to make this easier is using the postal code to render the address. The bad news is that I haven't seen any of this in Ruby but I have seen it in other languages so hopefully this will help.
This site is only in Japanese, but maybe you can download the code and check it out:
http://www.kawa.net/works/ajax/ajaxzip2/ajaxzip2.html
There's also this add-in for Excel that converts addresses. The code may be helpful to you:
http://office.microsoft.com/ja-jp/excel-help/HP010077514.aspx
Hope this helps.
Currently I have a site developed in cakephp that has the following type of URL's:
http://www.travelenvogue.com/clubs/page/accommodations/1-Ritz_Carlton_Club_Bachelor_Gulch
I have heard that because our most valuable keywords "Ritz Carlton Club Bachelor Gulch" are so far to the right of the beginning of the URL that they may not be helping us for SEO purposes. My first question is if this is accurate?
Secondly, my programmer told me he could change it for less time/money to:
Ex:travelenvogue.xxx/1-Ritz_Carlton_Club_Bachelor_Gulch/accommodations
(with the 1 before the keywords)
or (for more significantly more time/money) to:
Ex:travelenvogue.xxx/Ritz_Carlton_Club_Bachelor_Gulch/accommodations
Is the URL without the 1 in front of the keywords much more helpful than the one with the 1 in front of the keywords.
Any help is appreciated, I'm so confused! :)
The problem with rewriting the urls in backwards order like this is that it makes less sense to humans, especially since CakePHP's pretty-url structure is designed to conform to the accepted informal standard.
Here are Google's own recommendations: http://www.google.com/support/webmasters/bin/answer.py?answer=76329&hl=en
A site's URL structure should be as simple as possible. Consider organizing your content so that URLs are constructed logically and in a manner that is most intelligible to humans (when possible, readable words rather than long ID numbers). For example, if you're searching for information about aviation, a URL like http://en.wikipedia.org/wiki/Aviation will help you decide whether to click that link. A URL like http://www.example.com/index.php?id_sezione=360&sid=3a5ebc944f41daa6f849f730f1, is much less appealing to users.
The thing to remember is that Google are good at picking up keywords from your URLs and from your pages. So long as your pages and URLs follow a semantic, logical structure, there is very little to worry about.
Edit: As an addendum to the above - the 1 is redundant as far as both users and search engines are concerned, since it doesn't add any keyword value and is apparently some kind of identifier. It's the sort of thing that should be separated from the keywords somehow (usually by using a directory structure - http://example.com/accommodations/1/hotel-name ). Probably too late to change it now if it's a mature app, though. It would be better if it were a real keyword, say a particular country name or a location group or similar.
Yes it is right. More your main keyword close to the root folder more points it will get in Search engine.
This is not the only SEO thing.
in On page optimisation. your main keyword must be present in following.
Page title
H1 Tag
URL(in domain if possible)
In Image alt tag)
in Links on your home page.
meta keywords and description. (still some search count it)
first sentence of each paragraph
end of page.
you keyword must be sparse 20% in the whole page content in different places.
on off page optimisation, How popular you site with your keyword is on other sites.
Generally, there is more SEO weight for the page higher in the site hierarchy. For example, in order from good to bad.
www.mysite.com/page1
www.mysite.com/sub/page2
www.mysite.com/sub/sub/page3
Exactly how much weight depends the search engine. But keep in mind there are other factors.
In my opinion, the 1 before the title would not hurt you any more or less than the other example.
I will say the best would be: travelenvogue.com/1-Ritz_Carlton_Club_Bachelor_Gulch
In the end, SEO can be a bit of black magic. That is to say this particular optimization doesn't mean your page will appear ahead of another page that is under several sub directories. So you will have to decide time and budget.
in my app i need to open a website with the corresponding TLD for that country. Lets say google.com, google.de, etc...
But i don't know which country codes the're specifically using in NSLocale's dict. Can i assume that the lowercase version of NSLocaleCountryCode can be appended as TLD?
Regards, Erik
From Locales Programming Guide:
The region code is defined by ISO
3166-1
ISO 3166-1 is not equivalent to top level domains, at least not in all cases. For instance: .co.uk ≠ GB
On the other hand, there are only six or so exceptions. See the Wikipedia entry.
I am looking for url encoding tips for SEO compliant site.
I have a list of variables I need!
hypen = used to split locations, Leeds-UK-England
space = underscore for where spaces occur
hypen = plus sign used in some british locations (stafford-upon-avon)
forward slash = exclamation used in house for names of things.
Are the ones chosen bad or good? Are there any better ones, I'm pretty sure I need all the data, in order to decode the url's properly.
My "SEO" gave me a list of things which are bad, but not good. I've searched these and google seems to give the same type of results.
Cheers, Sarkie
Google used not to recognise underscores as word separators - see this article from 2005. This has entered into received wisdom and most of the 'experts' and articles you will find on SEO will still be recommending this.
However, last year this changed: underscores are now recognised as word separators so it opens things up for URL design. This now allows using dashes as dashes and underscores as spaces which some consider more natural. I've not found many people who have caught up with this, including SEO consultants I deal with professionally.
As to a good system for your use case, I would recommend asking around some non technical people (colleagues, friends, family, etc) to see what they like.
Hyphens for spaces is the usual and preferred method.