![]() | This project page does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||
|
I was asked in the help channel about a page being noindexed, and it turns out (according to Phabricator) that new, unpatrolled pages are noindexed by default. It might be worth putting on this page, but at the very least, I wanted to put it on the talk page so people might be able to find it. --MarkTraceur (talk) 14:02, 25 October 2016 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I was reading through the latest NPP RfC and related threads and noticed something I'm apparently confused about. I figure you'd probably know :) Much has been made of the possible dangers of "bad" new articles getting indexed by search engines. Speedy tags apply {{NOINDEX}}, but is it actually the case that new articles are not indexed until patrolled? I don't believe that was true last year (last time I had a reason to notice), but I may be behind. WP:NOINDEX seems to be out of date. I tried to test it by creating an article with my sock, but was lucky enough that it was patrolled quickly. (Yet the article still isn't indexed on google, and others I created today with my main account are... unfortunately I don't have enough articles stored up for any more sampling :) Opabinia regalis (talk) 06:59, 23 November 2016 (UTC)[reply]
<meta name="robots" content="noindex,nofollow"/>
until they are patrolled (or until 90 days go by, I haven't tested that). This attribute is also applied if the article contains a deletion tag such as {{speedy}}. Note, this is similar, but not identical to the behavior that __NOINDEX__ uses. There is a configuration parameter $wgExemptFromUserRobotsControl
that prevents the INDEX, NOINDEX magic words from overriding the namespace default (which for Namesapce:0 (Article) is set to INDEX). This is to prevent vandals from NOINDEX'ing random pages out of search. The noindex meta tab is merely a request to web crawlers - Google generally honors these - but some search engine may not. Finally, being available for indexed doesn't require or "push" a notice to all of the search providers of the world - it is up to them to fetch and index a page - sometimes this is fast, sometimes it takes a long time. Hope this helps. — xaosflux Talk 14:06, 23 November 2016 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
FYI: [1]. TigraanClick here to contact me 17:50, 4 January 2017 (UTC)[reply]
I have raised a question here about permitting particular pages in user space to be indexed: Noyster (talk), 20:50, 28 February 2017 (UTC)[reply]
Suppose we were to put in https://en.wikipedia.org/robots.txt
Disallow: /wiki/User:
Would that serve as a deterrent to people's putting their resumes, etc. in userspace? St. claires fire (talk) 22:29, 12 April 2017 (UTC)[reply]
What was the reasoning behind the 30-day indexing? Is it a holdover from before NPP, as a way to stop new junk being indexed? I would think indexing when an article is patrolled should be sufficient now.
The people who care most about indexing are those who are NOTHERE and creating articles for promotional purposes. Their articles should not be indexed at all. If their stuff manages to fall through the cracks and not get seen at creation, it would in effect be "accepted" automatically after sitting around for a month, which isn't good. With the huge backlog of pages to patrol that we have now, an article not being looked at for 30 days isn't unlikely, and basically the effect is that NPP is made ineffective by there being a big backlog. Apart from promotion, other poor articles will also show up on search engines just by hanging around.
So... Do we really need that 30-day thing? If not, how can we get rid of it?
Yeryry (talk) 16:08, 13 April 2017 (UTC)[reply]
Hi. If I understand correctly from Wikipedia:Controlling search engine indexing#Biographies of Living Persons talkpage noindexing, article talkpages should be marked as noindex. However, I've noticed that /Archive
pages are still indexed in some search engines (not google) (random example) because they don't have {{BLP}} template on them. I'm not sure how to suggest fixing this, but hope someone here can determine a simple solution. Thanks, Quiddity (WMF) (talk) 00:35, 4 December 2018 (UTC)[reply]
If you are viewing a source of a Wikipedia page after logging in, it is not displaying robots file. However if you are seeing the page without login in, it shows robots file with nofollow noindex tags. Here is an example where I noticed this bug Ruslan Baisarov. When I am logged into my account I cannot robots file however in a public view, there is a file. The page is also well over 90 days and was reviewed also. Meeanaya (talk) 06:01, 22 October 2019 (UTC)[reply]
FYI: I recently noticed that an article I created that has not yet been patrolled (and thus should not be indexed) has nevertheless shown up as a knowledge panel when I just did a Google search (it's not yet in the search results themselves, though). {{u|Sdkb}} talk 03:10, 18 September 2020 (UTC)[reply]
It seems DYK noms are the latest in a long line of backend pages that are getting indexed despite not being reader-facing. I hope we do a top-to-bottom examination of our indexing practices at some point and stop displaying so many pages that aren't relevant in google searches. {{u|Sdkb}} talk 08:31, 16 May 2021 (UTC)[reply]
Is there a way to build __NOINDEX __ into templates? This is the template under consideration and the issue is that Google has started indexing the draft bios that are tagged with this template; they are all accessible from this page. Of course, we could tag them all individually but come the next election, it would be much safer if we could just build this into the template. So, is that possible? Schwede66 07:14, 27 July 2022 (UTC)[reply]