Last modified: 2011-03-13 18:06:36 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T8545, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 6545 - Mark redlinks with rel="nofollow"
Mark redlinks with rel="nofollow"
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
http://www.psconclave.com/wiki/Main_Page
: easy, patch, patch-need-review
: 19065 (view as bug list)
Depends on:
Blocks: 17004
  Show dependency treegraph
 
Reported: 2006-07-04 15:15 UTC by Elliot Goodrich
Modified: 2011-03-13 18:06 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Implements rel="nofollow" on 'new' links (583 bytes, patch)
2007-10-04 21:13 UTC, Robert Leverington
Details

Description Elliot Goodrich 2006-07-04 15:15:43 UTC
I would like to see rel="nofollow" tags on links that point to editing and
history pages, as otherwise (unless using short URLs and blocking /w/ with
robots.txt) you can't stop search engines indexing those unwanted pages.
Comment 1 Brion Vibber 2006-07-04 16:29:11 UTC
Bug 2585 is likely more appropriate.
Comment 2 Elliot Goodrich 2006-07-04 17:17:03 UTC
I know this is similar, however the search engines will still try to crawl those
pages, and therefore creating extra work for the server, increased bandwidth etc.

On everypage there are at least 2 links that you should not follow (if a SE),
the edit and history, then you need to add all the nonexistant page links to
that list, and all the section edits, and the SE could end up following more bad
then good links.

Quote from the other page...
"Search engines DO care. They won't index pages sent with a 404 (or at least they
shouldn't)"

This would just be an extra measure to stop unwanted indexing. On Google
sitemaps using robots.txt to disallow the w/ directory also leads to thousands
of results on the "URLs restricted by robots.txt" page, making it hard to
diagnose incorrect URL blocking.

(sorry if I sound stroppy, I'm smiling really :P)
Comment 3 Brion Vibber 2006-07-04 17:17:41 UTC
Meh, could be done.
Comment 4 Robert Leverington 2007-10-04 21:13:03 UTC
Created attachment 4214 [details]
Implements rel="nofollow" on 'new' links

This patch adds rel="nofollow" to all red links. Has undergone basic testing, I see no way this could cause problems.  After searching all files I have identified one which also uses class="new" - Skin.php - although it uses it in a preg_match in a way which would still match with rel="nofollow" appended.
Comment 5 Rob Church 2007-10-04 21:17:11 UTC
Note that rel="nofollow" does NOT mean, "don't follow this link", it means, "don't assign the target weight in any kind of ranking algorithm", e.g. Google PageRank.

Edit pages and page histories ought to be emitting appropriate "noindex" meta-tags, which will prevent them being indexed by robots.txt-compliant robots.
Comment 6 Robert Leverington 2007-10-04 21:18:54 UTC
Just to clarify, is that a WONTFIX or should I wait for someone with more authority.
Comment 7 Rob Church 2007-10-04 21:26:47 UTC
No, I'm just commenting that rel="nofollow" doesn't *mean* what you think it means, and that the requested change ought to be redundant with our existing code.
Comment 8 Robert Leverington 2007-10-04 21:31:17 UTC
Ok, I guess there are two elements to the decision of accepting this patch or not. It is mainly redundant so in some cases might add a few bytes to a page increasing bandwidth and page load times, on the other hand some search engines might do what the tag says on the front of it rather than what is intended. Also some search engines may not understand the meta tags, having both doesn't appear to cause any harm.
Comment 9 Andrew Garrett 2009-03-05 00:10:00 UTC
Is this still of interest now that bug 2585 has been fixed?
Comment 10 Brion Vibber 2009-06-22 23:49:18 UTC
*** Bug 19065 has been marked as a duplicate of this bug. ***
Comment 11 mac.med02 2009-10-02 18:52:03 UTC

*** This bug has been marked as a duplicate of bug 2585 ***
Comment 12 Robert Leverington 2009-10-02 18:58:22 UTC
This is not a duplicate.

Resolution should be WONTFIX if it is not going to be implemented, and made explicitly by someone with the relevant jurisdiction.
Comment 13 mac.med02 2009-10-02 19:03:14 UTC
Is it not a duplicate? As far as I can tell, the bug opener wanted to block search engines from crawling through redlinked URLs. As Rob Church says above, rel=nofollow does not do this. Bug 2585 makes redlinks a 404, effectively stopping search spiders. To me, that sounds like it fixes the problem. And btw, I am just as entitled as anyone to share my opinion here. There are different levels of authority on-wiki, yes (admin, crat, etc.) but this is a open forum for discussion, and I am permitted to form my own opinion. If I was incorrect marking it as a duplicate, I'm sorry and I accept that blame, but I dislike the implication that I am not allowed to mark it as such.
Comment 14 Robert Leverington 2009-10-02 19:33:46 UTC
Sorry, that perception was not intentional; generally marking bugs as WONTFIX is done only be senior developers, and I wanted to make that clear.

In any case this bug was about the specific implementation of the desired feature, rather than the result.  For what it's worth I would support closing this bug as WONTFIX at this point.
Comment 15 Chad H. 2010-01-16 14:38:26 UTC
(In reply to comment #9)
> Is this still of interest now that bug 2585 has been fixed?
> 

Bug 2585 got reverted, but that's neither here nor there. These two bugs can be implemented independently of another. Although, solving that is another way of getting at the desired result: not having the bot index the edit page.

(In reply to comment #8)
> Ok, I guess there are two elements to the decision of accepting this patch or
> not. It is mainly redundant so in some cases might add a few bytes to a page
> increasing bandwidth and page load times, on the other hand some search engines
> might do what the tag says on the front of it rather than what is intended.
> Also some search engines may not understand the meta tags, having both doesn't
> appear to cause any harm.
> 

But it doesn't really have any added benefit. It just adds more bytes to the page. We already serve noindex,nofollow on the edit page itself, so serving it along with the link to the edit page would be redundant at best. As Rob pointed out in comment #5, the tag doesn't tell the bot to not follow the link. In all likelihood, the bot is probably loading the link anyway unless you're blocking it somewhere else; a noted workaround from the OP anyway.

WONTFIX.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links