If you are reading this, that might mean that you have opened this question (or maybe previewing the question). If you have indeed opened this question, when you click on the question title it links you back here...

Why do sites like facebook, google and even stackexchange do this? What kind of impact does it have to the user experience?

  • 3
    Considering I just did this in order to share another question, I thought I'd mention I used it for right-click -> copy link. It's a bit more accessible than the "link" anchor tag under the question as it's a bigger target.
    – GotDibbs
    Commented May 23, 2012 at 1:48
  • I swear we had this same question...but for the life of me I can't find it
    – Ben Brocka
    Commented May 23, 2012 at 2:10
  • I can't think of a good reason. Likely just an oversight.
    – DA01
    Commented May 23, 2012 at 2:49
  • 1
    @DA01: But there is a hover effect when you mouseover the title, so surely it must be intentional?
    – F21
    Commented May 23, 2012 at 3:15
  • Because you may arrive at this page from a link to a specific answer or even comment and by providing the title as a link you have an easy way to change to the "whole" page and possibly bookmark that instead of "just" an answer. Commented May 23, 2012 at 8:06

6 Answers 6


Typical users aren't going to expect a headline title to link anywhere, so there's potential for confusion there, but for power users this link gives additional functionality. On balance I'd say this isn't an anti-pattern as such because of the additional functionality it provides.

  • Clean URL: clicking on the title will give a parameter-free version.
  • Canonical URL: if there are multiple ways to get to the same document (potential issues with a site's IA aside), a link may provide a method to get to the canonical version more easily.
  • Right click to retrieve URL: most browsers allow you to copy a url, or open a link in a new tab, or a number of other things from the right click menu. Middle clicking opens the same page in an additional tab in many browsers.
  • Reloading the page: Why not just hit F5, you ask? Good question. But from personal observation of users a number of people refresh pages by clicking a same-page link.


I've found a similar question from webmaster.stackexchange, which has some interesting rationales, including links back to the original from mirrored articles, and the ability to perform "safe refreshes", which don't resubmit POST data.

For contrast, Wikipedia has some guidelines on self links (interestingly, this formatting only applies to the articles themselves and the "Read" link is a self link). They seem to believe that self links are likely to cause confusion - and in the context of Wikipedia's linking pattern, where they're liable to turn up half-way through the article, this makes sense.

  • Over on codereview.stackexchange.com I often click my mouse wheel on the title to open it in a new tab, which I then put on another screen so that I can look at the code in the original post whilst typing up my answer. So it can sometimes be a great power user feature. Also I don't see any harm in a link like this. If I see a page title that is clickable, I would only assume that it goes to the page I am currently on, where else could it go? Commented Jul 15, 2016 at 18:59

I don't know why these links exist on Stack Exchange. But we see them on many sites … maybe just a bad UI tradition.

There is one use case: People may have been found to this page per newsletter. The URL will then look like:


That's not the URL you want to see in your bookmarks. To get the clean URL you have to remove the parameters manually – or take the link from the head line. The headline is also easier to drag with a mouse than the URL.

Besides that I consider redundant links a rather poor UX: Selecting the title may lead to an unintentional click, and a keyboard user gets an extra, useless step on her way through the site.

I have written a small WordPress plugin to remove redundant links some time ago (doesn't work very good) because in WP, like in many other CMS, these links exist just because the underlying code is rather inflexible or nobody has asked your question.


I can only talk for myself, as I am a great fan of that: Links to the pages themselve enable you to easily post them on Social Networks, Instant Messengers and E-Mails. URL often contain unnecessary parameters, or worse: sometimes even parameters that reveal personal information about you. That can pretty much suck when you post stuff in public Chats/Forums/Blogs.

Another thing is HTTP Post: especially when you are on such user-content-driven sites like Stackexchange, you often do POST-operations. Pressing F5 after a POST operation gives you this ugly and annoying browser window: "Do you really want to reload and post..?" If you accidentally click "OK", you posted your stuff twice with even more annoying consequences.

Fortunately a lot of Websites employ the POST-Redirect-GET-Scheme (or completely javascriptized posting) so on good pages like Stackexchange you don't have that problem.

Anyways, it makes navigation and sharing of User driven Web content much more predictable for the user. Meaning less stress and more fun.

(Sometimes I wished Google would provide links to their searches. Particularly after they introduced that instant search, rendering the browser URLs more or less useless. Pretty cumbersome when you are a fan of sharing hyperlinks.)

EDIT: last but not least: sometimes the URLs on top of the browser are not valid for an infinite amount of time. (cf. "Permalinks") And in the age of Web apps it becomes preferrable to not see your Address bar so often. On small screen devices the user may not want to see that extra waste of space as less often as possible.


I think this feature supports three desirable aspects of the site:

Linkability: An article should provide a link where it can be found. This can have additional benefits such as being a permalink or a link without any navigational parameters, as pointed out in other answers. Ultimately, though, it is a way for the reader to determine the URL of a page (for finding the up-to-date version again, for passing on the link to others, ...) as opposed to the current URL of the file they might be reading.

If the article is read in its original location, the browser's address bar may serve as an alternative way of retrieving that URL. However, relying on the address bar is a design mistake IMHO - for all we know, the page might be displayed in a frame/iframe of sorts, or the browser might be running in some kind of weird kiosk mode that does not allow the user to access the address bar. Moreover, all the other URLs to in-article resources (e.g. on Stack Exchange, links to single answers or comments) can be obtained by finding the appropriate links on the page, so getting the article's own URL via a link, too, seems fitting.

Testability (of links): My main point above has been retrieval of the URL. Now, there would be several ways to do that - the URL might also be written verbatim or in a text box, ready for copy-and-pasting. However, by providing an actually clickable link, the URL that users might copy via the context menu is testable right away. It only takes a single click to verify the link really does point to the desired resource, before copying that URL to some other destination.

Consistency: If the title of an article is a link to the article on some pages of a website, it surely should be a link to that article on all pages of that website. Anything else would be inconsistent and thus confusing.


You can often reach a page via a link to a topic within the page (with an address with the '#' character in it e.g. http://www.site.com/pagelink#topiclink).

In some sites the address bar does not change when you visit internal pages.

In both of the above cases, if you want to send a link to the top of a specific page or bookmark it, then you need a link to the top of that page (in the first case you can edit the url yourself if you want).


From examining this website, I can see why the title link here does it. Looking aat the page source code I see the link is in the (class="question-hyperlink"). That is here at the top for the article, but it is the same link and class when the article excerpt is displayed in the question page. Each Question has its own div with the link, excerpt and other special items.

Doing it this way for this site and one like it reduces the amount of rework and site code. Another good reason would be if someone decides to copy an article they will get the link as well, so if they post it to another board or in a newsletter etc. someone can follow the link to the original article.

That's fine for articles, but in the case of nav menus, I prefer a standard whereby buttons are disabled for the current page and either hidden or ghosted. It is more work to do so, and many people working in the industry are lazy and probably should be doing something else for a living, so you should be prepared to see almost anything.

  • "in the case of nav menus, I prefer a standard whereby buttons are disabled for the current page and either hidden or ghosted" - why? Because you like losing the ability to copy a direct link to the current page, as if it had been opened from the nav menu, when the address bar is not available for one reason or another? Commented Apr 10, 2017 at 20:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.