: Many websites miss the HTML id or name attributes (no support for fragment URI's), what to do about it? I like the idea that HTML header elements have the id attribute. It allows to share

@Frith620

It is impossible to tell why this is less popular but we can make a few guesses:


Dynamically loaded content doesn't work with fragments because the content is not there and a fragment does not cause the browser to perform another HTTP request (in Chrome we just set the position of the scrollbar).
The HTML is not less tidy by adding the IDs but the page might be since without some links that point to the fragment, users generally have no way to get the URL with fragment. This is why the share link is needed in answers on Stack Exchange. You clock on it and it gives you a short URL to the appropriate answer.
Headers are important to websites. When you have a fragment, you skip much of the content which for advertising-revenue sites is not good. The trend is to put banner ads high up lately and even into the website header, so fragments would diminish revenue street for many sites.


There is no other way to point to a specific portion of a page unless the implementer designed one. If you look at StackExchange you will notice than answer links are not initially fragments but they do get turned into fragments when loading the link. This leverages browser support for fragments but it could be simulated by having Javascript read the parameter and even scroll the right element into view.

Vote Up Vote Down

@Megan663

The ID scrolling attribute using # links is very useful and you're right, it's probably underutilized. There are some things to consider however. If you're using the ID attribute for this purpose, then you'd want to include navigational # links on the page. And adding all of these links can cause for clutter. Wikipedia has them in their contents div, similar to that of a glossary. But not every site wants to dilute the content on their page by adding glossary style id links.

On top of that, historically, Google doesn't index # links in their search results. It would be high beneficial if they did. Many times when someone is searching for long tail question they are lead to a page that is mostly unrelated to the question with the answer hidden deep within the contents of the page. And it can be difficult to find the answer without reading all of its contents or using control+F for search.

Google has begun indexing # links from Wikipedia realizing just how useful this is. Though I don't think that Google has taken the time to do that for most sites.

Stackoverflow might not be using id links in their page, but they have now gotten indexing for specific answers. When you search Google for stackoverflow answers you'll often see snippet links for specific answers on the page. This was likely done with rich snippets or schema structure.

If you want portions of your page to be indexed by Google so that users can quickly navigate to that part of the page with a simple click from the SERP, you should take a look at rich snippets and schema. This can do that for you.

There are also other ways to navigate users to a page through URLs that would potentially be unadvised. For instance, you can have example.com/page and example.com/page/long-tail-keyword with a rel=canonical to example.com/page. When a user visits example.com/page/long-tail-keyword it can 302 redirect the user to example.com/page#keyword. You could also use file_get_contents on example.com/page#keyword in example.com/page/long-tail-keyword.

Other methods would be to use javascript and jquery that scrolls to the portion of the page that you want the user to see with the window.onload command.

Vote Up Vote Down