A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.
To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).
Talk:RelExtensions: Difference between revisions
| Line 17: | Line 17: | ||
shortlink has also been proposed (on the blagosphere) as shorter and shorturl | shortlink has also been proposed (on the blagosphere) as shorter and shorturl | ||
== On canonical-domain, canonical-wwwnone, and canonical-first == | |||
Responding to your summary on the last reversion: | |||
Two were analogous services, as noted, not the exact services. The concepts were discussed by Google and were justified there. | |||
For canonical-wwwnone, for the concept underlying it, Google says this at the linked page under "Set your preferred domain": | |||
"Setting your preferred domain tells Google which version of your site's URL (http://www.example.com or http://example.com) you prefer. | |||
"If you set your preferred domain as http://example.com, we'll treat links to http://www.example.com exactly the same as links to your preferred domain." | |||
Since Google supports this by requiring the site owner to tell Google through a tool apparently not on the website owner's site, I proposed a method apropos to all search engines that wish to implement it. | |||
For canonical-domain, while the same Google page supports only intradomain canonicalization, it does support that (see under "Specify the canonical link for each version of the page"). I extended their concept to interdomain canonicalization, because many institutions have multiple domains for identical content or the same website. An owner of one website with multiple domains who wants to do well in search engine results would likely prefer that all external inbound links point to one domain but can't ask everyone else to edit their links without risking links being deleted and a lowering in search results, and just asking everyone is a bunch of work. My proposal reduces the workload and eliminates that risk while raising site credibility that helps with positioning in search engine results. | |||
Examples of domains that probably share sites (although I didn't drill down to check beyond the home pages and didn't have the plugin to view the home page/s on the first pair): <http://esbnyc.com/> and <http://empirestatebuilding.com/>, which might redirect, and <http://www.networksolutions.com/> and <netsol.com>, as I typed it, which redirects. | |||
While redirection is an easy solution, the site owner might prefer to display a message to users of one domain and not the other as part of educating the general public about the preferred domain (as used to be the case at yaho.com (one "o")). In that case, canonical-domain would inform search engines who wish to implement it while allowing the site owner to educate the part of the public that types the wrong name. For example, in New York City the agency that intervenes for abused children is still widely known by initials that have been abolished for 40 years (I heard it in conversation on the 15th of this month). | |||
However, I do see one defect with my proposal. Where a rel link works, a rev link can usually be expected to work, and rev for canonical-domain could be used to steal traffic from a competitor or other site. So I will add that rev must be meaningless. | |||
I will do the same for canonical-wwwnone, since I understand that it's possible, albeit unusual, to have separate websites for www and bare forms of the same domain, depending on the host's architecture, which means it's possible, albeit very unlikely, that the two websites could be under separate managers, and perhaps separate owners, who bitterly compete. So I will add that rev must be meaningless for that keyword, too. | |||
For canonical-first, I did not cite Google. Because it is possible to have a canonical set of pages and one noncanonical page in situations where the keywords alternate and print wouldn't be technically adequate or semantically apt, and the canonical set of pages might not fully occupy a directory, it might be more convenient to have canonical-first as shorthand. That's easier because only one page needs coding rather than two or more. Because it is shorthand, however, it is more dispensable, if people would like to reject it. I'm putting it back for the time being, i.e., for decision, since it seems to have been removed on the basis of the Google position, but I hadn't asserted that Google supported it. I will also add that rev must be meaningless for this keyword, too. | |||
Thank you. | |||
[[User:Nick|Nick]] 20:10, 20 September 2009 (UTC) | |||
Revision as of 20:10, 20 September 2009
Memorandum of understanding
This Web page and associated Web services, if any, are provided with the understanding that providing them is cheap and relatively reliable, and that the URIs for these resources will not change after HTML5's completion, unless circumstances outside of the administrator's control force such a change.
Organisations that believe these pages to be of vital importance are encouraged to put aside funds for the defence of this page should the need arise.
--Hixie 23:40, 10 December 2007 (UTC)
XFN noise
Could XFN relations be separated? I'm under impression that they inflate the list.
- I think that they should be removed, or moved to a microformat list where they would be named eg
xfn.friend. I also want to emphasize that I dislike XFN as it implies to complex relation, that can be hard to resolve. For example "the maintaner of that document had that relation to the maintaner of the referenced document when the document was last edited/created" is not a good example of a relation. If we assume one knows the maintainer of the current document, how is one to know who the maintainer of the referenced document is? Someone could also be confused by the name of the relation and think that the current resource if a friend of the author…
Re: shortlink
shortlink has also been proposed (on the blagosphere) as shorter and shorturl
On canonical-domain, canonical-wwwnone, and canonical-first
Responding to your summary on the last reversion:
Two were analogous services, as noted, not the exact services. The concepts were discussed by Google and were justified there.
For canonical-wwwnone, for the concept underlying it, Google says this at the linked page under "Set your preferred domain": "Setting your preferred domain tells Google which version of your site's URL (http://www.example.com or http://example.com) you prefer. "If you set your preferred domain as http://example.com, we'll treat links to http://www.example.com exactly the same as links to your preferred domain."
Since Google supports this by requiring the site owner to tell Google through a tool apparently not on the website owner's site, I proposed a method apropos to all search engines that wish to implement it.
For canonical-domain, while the same Google page supports only intradomain canonicalization, it does support that (see under "Specify the canonical link for each version of the page"). I extended their concept to interdomain canonicalization, because many institutions have multiple domains for identical content or the same website. An owner of one website with multiple domains who wants to do well in search engine results would likely prefer that all external inbound links point to one domain but can't ask everyone else to edit their links without risking links being deleted and a lowering in search results, and just asking everyone is a bunch of work. My proposal reduces the workload and eliminates that risk while raising site credibility that helps with positioning in search engine results.
Examples of domains that probably share sites (although I didn't drill down to check beyond the home pages and didn't have the plugin to view the home page/s on the first pair): <http://esbnyc.com/> and <http://empirestatebuilding.com/>, which might redirect, and <http://www.networksolutions.com/> and <netsol.com>, as I typed it, which redirects.
While redirection is an easy solution, the site owner might prefer to display a message to users of one domain and not the other as part of educating the general public about the preferred domain (as used to be the case at yaho.com (one "o")). In that case, canonical-domain would inform search engines who wish to implement it while allowing the site owner to educate the part of the public that types the wrong name. For example, in New York City the agency that intervenes for abused children is still widely known by initials that have been abolished for 40 years (I heard it in conversation on the 15th of this month).
However, I do see one defect with my proposal. Where a rel link works, a rev link can usually be expected to work, and rev for canonical-domain could be used to steal traffic from a competitor or other site. So I will add that rev must be meaningless.
I will do the same for canonical-wwwnone, since I understand that it's possible, albeit unusual, to have separate websites for www and bare forms of the same domain, depending on the host's architecture, which means it's possible, albeit very unlikely, that the two websites could be under separate managers, and perhaps separate owners, who bitterly compete. So I will add that rev must be meaningless for that keyword, too.
For canonical-first, I did not cite Google. Because it is possible to have a canonical set of pages and one noncanonical page in situations where the keywords alternate and print wouldn't be technically adequate or semantically apt, and the canonical set of pages might not fully occupy a directory, it might be more convenient to have canonical-first as shorthand. That's easier because only one page needs coding rather than two or more. Because it is shorthand, however, it is more dispensable, if people would like to reject it. I'm putting it back for the time being, i.e., for decision, since it seems to have been removed on the basis of the Google position, but I hadn't asserted that Google supported it. I will also add that rev must be meaningless for this keyword, too.
Thank you. Nick 20:10, 20 September 2009 (UTC)