Welcome to WebmasterWorld Guest from 22.214.171.124
Forum Moderators: ergophobe
Jump to the information you want right from the search snippets
2009-09-25 - [googleblog.blogspot.com...]
We generate these deep links completely algorithmically, based on page structure, so they could be displayed for any site (and of course money isn't involved in any way, so you can't pay to get these links). There are a few things you can do to increase the chances that they might appear on your pages. First, ensure that long, multi-topic pages on your site are well-structured and broken into distinct logical sections. Second, ensure that each section has an associated anchor with a descriptive name (i.e., not just "Section 2.1"), and that your page includes a "table of contents" which links to the individual anchors.
Anyone remember all those topics I started about Fragment IDs that just went in one ear and out the other? Well, some of you were on board but the general audience just didn't quite grasp the concept of targeting at this level. Here are some historical topics discussing Fragment IDs...
Be Specific, Use Fragment Identifiers
On page targeting for users.
2008-04-25 - [WebmasterWorld.com...]
Axioms of Web Architecture
2007-03-02 - [WebmasterWorld.com...]
Anchor Naming Conventions
2004-03-08 - [WebmasterWorld.com...]
I could probably dig up a few more that go back to the late 90s but I don't think there is a need to. The message is quite clear. Google have, and will continue to look at document structure and the use of semantic markup to further refine their relevancy algorithms. Named anchors have been part of the HTML Specification at least as far back as HTML 2.0...
NAME - gives the name of the anchor, and makes it available as a head of a hyperlink.
So, what say ye now? Time to go back and start adding all those Fragment IDs? Don't you wish you would have done it way back then? Ya, I'm rubbing it in a little, you know me. ;)
The biggest problem, afaik, is that you can't see in you analytics if they entered directly to a section or not. So, when having multiple anchored sections in a page, how would you know what's the best place to put your ads?
Even cleverer people than that use both: <h2 name="blueWidgets" id="blueWidgets">Blue widgets</h2>
No, one or the other. If I were a Search Engineer and detected stuff like that and there were other signals, I'm going to ding you for it.
Did you know that one of the most common HTML/XHTML validation errors has to do with Fragment IDs?
W3C: "An "id" is a unique identifier. Each time this attribute is used in a document it must have a different value. If you are using this attribute as a hook for style sheets it may be more appropriate to use classes (which group elements) than id (which are used to identify exactly one element)." [Validator.W3.org...]
I'm currently monitoring 628 websites as of 2009-09-30. There are 1,767 "ID Already Defined" errors amongst those website documents. If I were to look closely at those, which I have, many of them are user generated errors via cut and paste routines. They may have downloaded some sort of plugin and decided that they wanted it here, here and there, 3 instances. And of course since they don't know much about HTML, and don't realize what they just did with that cut and paste routine. :(
If you run your site through the validator and then choose the option to "Group Error Messages by Type", scroll towards the last group of errors and you may find the "ID X Already Defined" group.
W3C Markup Validation Service
[Validator.W3.org...]ID X already defined
An "id" is a unique identifier. Each time this attribute is used in a document it must have a different value. If you are using this attribute as a hook for style sheets it may be more appropriate to use classes (which group elements) than id (which are used to identify exactly one element).
An example I used in a recent article...Here's a working example of how multiple IDs can disrupt document functionality...
* Choose Option 1 - This Radio Button 1 has a label and Unique ID associated with it. Click this list item for testing.
Code Example Unique ID 1
<label for="Radio1"><strong>Choose Option 1</strong><br />
<input type="radio" value="Selected" name="Radio" id="Radio1" /> This Radio Button 1 has a label and Unique ID associated with it. Click this list item for testing.</label>
* Choose Option 2
This Radio Button 2 has a label and Unique ID associated with it. Click this list item for testing.
Code Example Unique ID 2
<label for="Radio2"><strong>Choose Option 2</strong><br />
<input type="radio" value="Selected" name="Radio" id="Radio2" /> This Radio Button 2 has a label and Unique ID associated with it. Click this list item for testing.</label>
If the above two Radio Buttons had the same ID assigned to them (id="Radio1") they would not function. In this example, the first Radio Button 1 (id="Radio1") would be permanently selected and the user could not select Radio Button 2 (id="Radio2"). This is just a very basic example of how having IDs that are not unique can break your documents.
I wonder how Google would handle multiple instances of the same Fragment ID in a document? Is it going to use the first or last reference?
Also, protocol states that Fragment IDs are client side functionality and dereferenced by User-Agents. Does this new feature from Google mean that the protocol needs to be revised to reflect the fact that UAs do reference Fragment IDs? Or at least Googlebot does?