Description from merged task:
[[Special:Wantedpages]] show many links to pages "requested" via expressions like "{{#ifexist:}}". Query the existence of a page doesn't make it "wanted", sometimes its the exact opposite; we use this expression for filtering pages we DON'T WANT.
This affects the experience of editors that uses Special:Wantedpages to find articles or pages to work, and finds this special page full of noise.
E.g.
https://en.wikipedia.org/wiki/Special:WantedPages
https://fr.wikipedia.org/wiki/Spécial:Pages_demandées
Original (2007) description
i've traced it down to the line $parser->mOutput->addLink( $title, $id ); that was added by tstarling in revision 19892 on Mon Feb 12 10:24:23 2007 UTC with the reason "Register a link on #ifexist. Otherwise this breaks cache coherency.."
i can find no logical reasoning for this change. all it is doing is checking if the target exists, and outputting one of two user supplied text blocks. and that is all it should do. it is not making a link to target, nor does it display a link to target anywhere in the scope of this functions code so why does the target need to be added to the link list?
granted, i do not have a complete grasp of the internals of the parser nor the cache systems, but the feedback noise on special:whatlinkshere renders the page useless.
See also:
T18584: prop=links not include links from transcluded templates
T17735: Non-clickable links (from #ifexist) should be flagged in pagelinks
T12857: #ifexist: produces an entry in links list
T33628: When #ifexists target page is created/deleted, does not update links tables
T73637: mw.title.exists "pollutes" pagelinks table
This card tracks a proposal from the 2015 Community Wishlist Survey: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey
This proposal received 11 support votes, and was ranked #62 out of 107 proposals. https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Miscellaneous#Error_categorization_by_.23ifexist_bug
Detailed explanation
This detailed explanation was prepared by @Huji in 2020 in the hopes that it would increase the likelihood of this (and T33628) being fixed.
When {{#ifexists:TargetPage|...|...}} is called, the parser adds a link from the Source Page to the Target Page on the pagelinks table. This is because if the status of the Target Page changes from nonexistent (i.e. red link) to existing (i.e. blue link) or vice versa, MW parser needs to have a way to know which pages' cache needs to be purged. The way parser finds pages that need to be purged is by crawling the pagelinks table for all pages linking to the Target Page, and invalidating their cache. This has a few side effects.
Side Effect #1: even though the #ifexists command above doesn't really create a hyperlink from Source Page to Target Page, the pagelinks table thinks that such a link exists; this "fake" link will be reflected on on Special:WhatLinksHere/Target_Page or Special:WantedPages which is undesirable.
Side Effect #2: because parser always uses the pagelinks table in the above process, when Target Page is a file or a category, the data about this "fake" link is actually stored in the wrong table (pagelinks as opposed to imagelinks or categorylinks). Now, that is not all bad; if the right type of link was being created, we would see something similar to Side Effect #1 occurring with even more places (e.g. a category would not only list all pages in it, but also, all pages that check the existence of the category). But, when only one table is used to keep track of #ifexists calls, T33628 happens which is *undesirable*.
Side Effect #3: because Special:WhatLinksHere/Target_Page shows a list of pages that check the existence of Target Page, it allows for tracking all pages that may check the existence of a particular page, e.g. through a template. This is helpful, for example, when you are editing a template; in preview mode, you can see a list of outgoing links from the template, and that would include a link to Target Page (which the template only checks the existence of), and if that is, say, a missing template subpage, you will see a red link and realize that it is missing. This effect is *desirable*.
Ideally, we want to do away with the undesirable effects, while maintaining the desirable one.