Wikipedia talk:Manual of Style/Layout

Works cited

Is there consensus about what goes in a "Works cited" section? I'm running across newspaper articles elevated to this section as in Stephen Miller and several other new GA candidates. I am happy to have books listed under Works cited, and, maybe separately, a list of journal articles. I'm not so happy about seeing the everyday media and press put there. -SusanLesch (talk) 22:41, 16 October 2025 (UTC)

I see no reason why a bibliography, which is pretty much the same thing as a works cited section, shouldn't include all the sources. Looking at Chicago Manual of Style 18th ed. p. 811, there is a sample bibliography page that includes websites, journals, and books. The only reason for a distinction I can think of is that since books are long, there is a greater likelihood that material from different pages will be cited at different points in the Wikipedia article. So the short description of the work (author & date), plus the page number can go in the notes and the full information in the "Works cited". But the same situation can come up with a long journal article. Jc3s5h (talk) 00:29, 17 October 2025 (UTC)

Some articles use a citation style where works that can be cited to a single footnote (like newspaper articles) use footnotes, but works where additional information is needed (like specific pages in book cites) and where that information varies from footnote to footnote are cited with short footnotes and later bibliography entries. So in that case it would only create unnecessary indirection to move the newspaper citations to the bibliography. —David Eppstein (talk) 00:59, 17 October 2025 (UTC)

Yeah, it depends on the citation style used in any given article. Some put everything cited in the "Works cited" or "References" section, others don't. Either is fine as long as the treatment of sources is somewhat consistent. Gawaon (talk) 07:29, 17 October 2025 (UTC)

While it is good that journalists may appear more important, I agree with David Eppstein that this practice introduces unneeded complexity, as he says, unnecessary indirection. The reader consulting sources (bottom up) is unable to determine any source for any statement without considerable backtracking effort. What is the benefit in tying up the press in knots? Wikipedia used to have functioning footnotes connecting source to statement by number in one click. -SusanLesch (talk) 14:43, 17 October 2025 (UTC)

It's not a new idea. Help:Shortened footnotes was created in September 2011, and the concepts that it describes are even older - Template:Sfn dates back to June 2009 (I started using it a few weeks later, on 22 September 2009 to be exact); but even that was just the latest of a series of increasingly-refined methods for making shortened footnotes. For example, this edit, describing the broad technique using a mechanism that is somewhat primitive by today's standards, was made on 28 October 2007. That's nigh on eighteen years ago. --Redrose64 🌹 (talk) 22:13, 17 October 2025 (UTC)

Thank you all for your replies. I guess this is just one of those (to me, maddening) areas where Wikipedia hasn't and won't make a decision either way. So, yes, no consensus, to answer for the archive. Best wishes. -SusanLesch (talk) 00:01, 19 October 2025 (UTC)

Well, the consensus is WP:CITEVAR, as in any editor at each separate article gets to make up their own rules. So maybe it's worse than just "no consensus", in some editors' views. WhatamIdoing (talk) 01:21, 19 October 2025 (UTC)

WP:CITEVAR explains the intricacies of citations, with only tenuous connection to MOS layout or infrastructure. I think we're all familiar with the task of executing in a different citation style than the one to which we're accustomed. -SusanLesch (talk) 14:40, 19 October 2025 (UTC)

Two people complained separately on the editor's talk page about poor use of {{sfn}}. Maybe I titled this thread incorrectly. -SusanLesch (talk) 20:57, 10 November 2025 (UTC)

RFC: Piped links in "See also" sections

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.

---

Should the following (or similar guidance) be added to MOS:SEEALSO?

"See also" sections are purely for navigation; the titles of target articles should be unobscured, so readers know if they have already visited them exactly where the link will take them.

• Do not link to redirects; use the exact name of the destination article instead, disambiguation parentheticals included.
• Do not use piped links. Links to a specific section should use {{section link}}.

(I would propose adding this above the {{annotated link}} paragraph, unless someone has strong feelings it should go elsewhere.) -- Beland (talk) 09:46, 4 December 2025 (UTC)

(Edited per suggestion below, adding underlined and deleting struck text. -- Beland (talk) 06:01, 5 January 2026 (UTC))

Previous discussion, which triggered this RfC: https://en.wikipedia.org/w/index.php?title=Talk:Saint_Valentine%27s_Day_Massacre&oldid=1325650068#See_also_-_List_of_organized_crime_killings_in_Illinois
Mitch Ames (talk) 08:17, 6 December 2025 (UTC)

 Courtesy link: Wikipedia talk:Manual of Style/Layout § c-Mitch Ames-20251206091700-Beland-20251204094600 FaviFake (talk) 06:18, 5 January 2026 (UTC)

• Oppose. Go with piped links and, if necessary, use a brief annotation. - SchroCat (talk) 09:52, 4 December 2025 (UTC)
• Mostly support As Wikipedia generally avoids forcing a style I oppose forcing (un)piped links. However, I was unaware that template existed and do think it should be preferred. Support working the rest into the prose though; there's no harm in adding clarity about it being for navigation and not obscuring links. Then just: The "See also" section should not include redirects... ~ Argenti Aertheri^(Chat?) 17:00, 4 December 2025 (UTC)

  What sort of style variation were you in favor of keeping? It seems like hatnote and further info and main article templates and whatnot now all automatically change # to § in section links. (Which makes sense to me; consistency makes it easier for readers to understand what the § means.) Or are you saying it's fine to have § as the universal style but allow achieving it with a piped link rather than a template? -- Beland (talk) 18:04, 4 December 2025 (UTC)

  The latter. Given #section has been standard HTML since forever, we shouldn't suddenly ban editors from using it. Reader side though we should have a consistent "look", so suggest to editors multiple ways to achieve that "look". ~ Argenti Aertheri^(Chat?) 22:46, 6 December 2025 (UTC)

  Aha, thanks for clarifying.

  Even with this guideline, editors are still allowed to add links like [[Name of article#Name of section|Name of article § Name of section]]. It's just that someone might come by and change it to use {{section link}} instead. Personally, I actually probably wouldn't bother. This notation is still a major navigational improvement over piped text that obscures the destination, and readers can't tell the difference between this and the template method anyway.

  I do think {{section link|Name of article|Name of section}} is better, because it reduces the possibility of a typo in the display text (the link would show up as red and be corrected, or show up on a bot broken section link scan), is less typing, and makes the wikitext easier to read. It also has the advantage that if we decide to change how section links are displayed (for example to match a Mediawiki UI change), we wouldn't have to go around making changes to gjillions of articles; we could just change it in one place.

  That's why I personally use the template method and would recommend it and teach that to new editors, but if people are allergic to that idea, as a compromise we could note both methods. -- Beland (talk) 23:36, 6 December 2025 (UTC)

  I don't think we're really disagreeing, but I've been typing href="#section" since the 90s, the convention is older than Wikipedia. (And probably many of our editors!) ~ Argenti Aertheri^(Chat?) 00:06, 7 December 2025 (UTC)

  Heh, I've also been coding HTML since the 1900s. 8) Much of the point of wikitext is to avoid editors having to learn HTML, though it does still surface the # as anchor marker convention in a lot of places. -- Beland (talk) 01:39, 7 December 2025 (UTC)

  It's called a URL fragment, and that syntax dates back to the earliest days of the WWW - see for example rfc:1630#page-7 from June 1994, although I believe that it goes back to 1990. Wikipedia uses that syntax for linking to sections because it's being used for exactly its design purpose. --Redrose64 🌹 (talk) 12:15, 7 December 2025 (UTC)

• Oppose. Not seeing a benefit to this proposal - disambiguation parentheticals in particular are not something typically necessary to display, and increasing the number of templates in an article unnecessarily has its own drawbacks. Nikkimaria (talk) 02:24, 5 December 2025 (UTC)

  What drawbacks are there to the reader of an extra template on the page? Mitch Ames (talk) 09:23, 6 December 2025 (UTC)

  Some templates are hidden in some mobile views, leading to surprising gaps in articles. PamD 09:56, 6 December 2025 (UTC)

  I just checked on my phone, and the {{section link}} in Atlantic Ocean#See also works fine. The {{annotated link}} in Anatomy#See also also works fine. -- Beland (talk) 10:25, 6 December 2025 (UTC)

  They slow loading and can potentially even break the page. Nikkimaria (talk) 15:31, 6 December 2025 (UTC)

  We're generally told not to worry about performance outside of expensive parser functions, which as far as I can tell these templates don't use. As I understand it, there's no difference as far as the PEIS limit is concerned between using a template and writing out the expanded text that the template would have produced. Either way, if the page is too big, it will have to be trimmed or split. Currently there are no articles exceeding the 2 MB limit. -- Beland (talk) 19:56, 6 December 2025 (UTC)

• Support, for these guideline-based reasons (taken from the original discussion):
  • MOS:LINKCLARITY: The article linked to should correspond as closely as possible to the term showing as the link – {{section link}} shows the article title and section directly and verbatim, i.e. more closely than any piped link or equivalent redirect.
  • WP:TRANSPARENCY: Keep piped links as transparent as possible – {{section link}} shows the article title and section more transparently than any piped link or equivalent redirect.
  • WP:TARGET: when the target page is displayed, it is likely that the top of the page will not be shown, so the user may not see the helpful "(redirected from...)" text or the display text of the piped link that they clicked. {{Section link}} shows the reader exactly where they are going before they click the link.
  While pipes and redirects are useful tools in the body text of an article to preserve the grammatical structure and flow of a sentence or avoid the unsightly Article#Section name in the display text, those requirements do not apply to "See also" because there is no "grammatical structure and flow of a sentence" to disrupt.
  Mitch Ames (talk) 09:15, 6 December 2025 (UTC)

  There is no difference in clarity or transparency between Atlantic Ocean#Toponomy and Atlantic Ocean § Toponomy, so none of these are reasons to use the section link template. And as LINKCLARITY makes clear, the link target and the link label do not have to match exactly, as long as the linking is intuitive - I would argue that Name of the Atlantic Ocean is the more intuitive option, as it doesn't require a reader to understand the word "toponomy". Nikkimaria (talk) 20:26, 6 December 2025 (UTC)

  Using two different symbols to mean the same thing makes it twice as hard for new readers to learn Wikipedia's convention for linking to sections. "#" is more often used to mean hashtag, which could be quite confusing for new readers coming in from social media.

  It's true that "Name" is easier to understand than "Toponomy", but if an article has chosen a hard-to-understand section title, I think a better solution is to change the title to be more understandable. Then the benefit of comprehensibility is enjoyed by readers navigating inside the article, not just readers who encounter links from other articles. Picking a better title also maintains consistency between link text and destination text. I've retitled this section as Atlantic Ocean#Names.

  I find piped links that obscure the title of the destination article and section frustrating when I'm navigating related articles. For example, say I read the article Atlantic Ocean for the first time and want to find out more about the history of the names of oceans. Let's say I end up on another article which has a "See also" link that goes to Atlantic Ocean#Names but has the link text "Name of the Atlantic Ocean". Atlantic Ocean shows up as a purple visited link, but "Name of the Atlantic Ocean" will show up as a blue unvisited link because I haven't visited that specific section URL (unless I clicked on a section link in the article TOC). My typical reaction is, "Oh, there's a whole third article I haven't read yet! I should read it and add a link to it from the first article so other people can also find it!" But then clicking through I find that it's not a new article at all, merely a section of the article I've already read. This disappointing and time-wasting mismatch of expectation and result is unnecessary, given (as Mitch Ames points out), there's no need to try to shoehorn the link text into the grammatical structure of a sentence. -- Beland (talk) 23:22, 6 December 2025 (UTC)

  There is no difference in clarity or transparency between Atlantic Ocean#Toponomy and Atlantic Ocean § Toponomy — The lack of spacing around # makes the text harder to read. As well as the space before §, {{Section link}} inserts a non-breaking space after it to give better layout on narrow screens. Mitch Ames (talk) 00:39, 7 December 2025 (UTC)

  ... intuitive ... — Whether something is "intuitive" can be very subjective; the whole point of displaying the exact article and section name is that intuition is not required, because the information is explicitly presented.

  Name of the Atlantic Ocean ... doesn't require a reader to understand the word "toponomy — WP:SEEALSO already says:

  provide a brief annotation when a link's relevance is not immediately apparent, when the meaning of the term may not be generally known

  Using your example: Atlantic Ocean § Toponomy – Name of the Atlantic Ocean

  (Although as Beland points out, changing the unclear section name in the linked article may be the better solution.) Mitch Ames (talk) 01:02, 7 December 2025 (UTC)

  (Replying to both of you). As already noted above, the hash symbol has an established history for linking to sections - I would argue one more likely to be familiar to readers than the more esoteric section sign. It is not always feasible to adjust a section heading exactly as one may prefer for linking from another article, which is why though I agree that Whether something is "intuitive" can be very subjective, I disagree that displaying the section name will always be more intuitive than any alternative. Ultimately I think these issues are best left to navigate based on the specific of the case, and so continue to oppose the proposal. Nikkimaria (talk) 02:08, 7 December 2025 (UTC)

  Is there a good example of where using the section title from the target article would not be the most intuitive, but the section title can't be changed to make it so? -- Beland (talk) 02:15, 7 December 2025 (UTC)

  One example would be linking to a subsection - eg if you see North America § Central America you might draw a very different conclusion about what that's about compared to a piped link, and changing that heading in a way that would be useful for this purpose would almost certainly fall afoul of MOS:NOBACKREF. Nikkimaria (talk) 03:19, 7 December 2025 (UTC)

  Excellent point! I was thinking maybe an annotation would fix that without causing navigational confusion, but maybe showing the hierarchy above that section would be better. For example:

  North America § Geography § Geology § Central America

  or just:

  North America § Geology § Central America

  if editors find that clear enough? -- Beland (talk) 03:48, 7 December 2025 (UTC)

• Change to explanatory sentence: I suggest this change to the proposed explanatory sentence:

  ...the titles of target articles should be unobscured, so readers know if they have already visited them exactly where the link will take them.

  Mitch Ames (talk) 09:17, 6 December 2025 (UTC)

  I'm open to that change; we could also give both reasons? -- Beland (talk) 09:22, 6 December 2025 (UTC)

  We could list both reasons, but I think we should put "know where the link will take them" first, because it is more important (per the 3 guidelines I cited). Mitch Ames (talk) 09:29, 6 December 2025 (UTC)

  Works for me. -- Beland (talk) 10:22, 6 December 2025 (UTC)

• Support, especially with the wording change suggested by Mitch Ames above. As it largely seems to formalize the current best practices that most "See also" sections already follow, it's a reasonable addition to ensure consistency and clarity. Gawaon (talk) 03:34, 7 December 2025 (UTC)
• Oppose with reasons similar to Nikkimaria's: this ought to be left to specific cases; one size doesn't fit all. -- Michael Bednarek (talk) 06:39, 7 December 2025 (UTC)
• Oppose. Piped links can be helpful for hiding disambiguators that are irrelevant to the topic, and in describing the intended see also content in cases where it is not the main topic of the linked article. This sort of rigid prescriptivism does not belong in the MOS. See also WP:CREEP. —David Eppstein (talk) 07:57, 7 December 2025 (UTC)
• Comment I always thought that MOS:SEEALSO's Editors should provide a brief annotation when a link's relevance is not immediately apparent implied that the actual page title should be displayed, akin to MOS:DABPIPE's piping and redirects should generally not be used.—Bagumba (talk) 08:34, 7 December 2025 (UTC)
• Oppose on the grounds that parenthetical disambiguators can be irrelevant and distracting, depending on the situation, and a one-size-fits-all approach is not going to be helpful. Sometimes it's the redirect which will have a name whose relevance is more obvious; a link whose blue text is relevant is simpler to read than a link plus an annotation. Stepwise Continuous Dysfunction (talk) 08:49, 7 December 2025 (UTC)
• Support. Disambiguators should be listed and not hidden with a pipe. I find the complaint that they can be distracting rather weak. If they're fine on disambiguation pages and in page titles, they're fine in "See also" sections too. And I agree with the clarity in navigation that the proposal is aiming to achieve. If there are any special cases that really have some kind of overriding reason to do something special, we're not robots and can use our common sense, as with any MOS guideline. The appeals to CREEP are also misplaced. Every time someone advocates for a some extra bit of guidance, people get all up in arms about CREEP, but this sort of guidance is exactly what the MOS is here for. –Deacon Vorbis (carbon • videos) 17:43, 10 December 2025 (UTC)
• Support – per Deacon Vorbis's excellent explanation and the policies that support this change.
  I also support explicitly recommending the use of the § character (whether it be through a template or though a piped link) over the raw # character, for all of these reasons. FaviFake (talk) 16:55, 17 December 2025 (UTC)
• Oppose - The primary premise for this change is wrong: "See also" sections are not purely for navigation. "See also" sections are a part of the article, which people can read to learn about related topics that may be of interest to them. Thus, readability is a priority, and as others have said, requiring disambiguation parentheticals to be visible just adds clutter to the page and results in a worse user experience. The other suggestions aren't as bad, but this is a solution in search of a problem. — Preceding unsigned comment added by Danbloch (talk • contribs) 05:08, 18 December 2025 (UTC)

  'See also' sections are not purely for navigation — According to MOS:SEEALSO, a "See also" section is a useful way to organize internal links to related or comparable articles". The section does not give any information about the subject of the article, thus it is only a navigation aid, to other articles.

  people can read to learn about related topics — They do not typically learn about the related topics by reading "See also". They learn of the existence of related topics, then learn about those topics only after following the links other articles. The "see also" link provides navigation to those other articles.

  readability is a priority — This is true, but "readability" depends on context. In the main article body text, readability is about the flow of the sentence in which the link in embedded - which we do not disrupt with disambiguators or visible section symbols, for example. In body text there is no need for disambiguators or section symbols because the body text itself gives the context. However in "See also" there is no body text to disrupt the flow of, or give context. Instead readability is about clearly and unambiguously telling the reader where the link goes - because the link target is the only purpose of the "See also" entry. The simplest and most direct way is display the link target, with no pipe and using {{section link}} if appropriate. Mitch Ames (talk) 12:20, 18 December 2025 (UTC)

  Upon reflection, I think it's true that the "See also" section sometimes tells readers something about other topics, but mostly for navigational purposes - just enough to know if they should click on the link. When it's not obvious, this involves pointing out how the target topic is related to the topic of the article. I just think this is better done by adding an annotation than by obscuring the title of the target.

  Danbloch, I'm surprised you don't see readers experiencing unwanted visits to articles they've already read as a problem? -- Beland (talk) 17:06, 18 December 2025 (UTC)

  @Beland: All I can rely on is personal experience. Visits to already-read articles from "See also" happen to me rarely if ever, and when they do I say "Oh darn" and click the back button. If I thought a link was misleading I would presumably fix it.

  Note that I don't have strong feelings about this guidance on redirects or piping in general, just the disambiguation parentheticals. There may be cases where these avoid confusion, in which case they should be included, but this is usually not the case. Danbloch (talk) 17:41, 18 December 2025 (UTC)

  Disambiguation parentheticals are only used for articles which are not about the primary meaning of a word, so wouldn't they always reduce confusion? -- Beland (talk) 17:44, 18 December 2025 (UTC)

  It's usually clear from context which of multiple meanings is meant. Danbloch (talk) 19:31, 18 December 2025 (UTC)

• Comment: The discussion at Wikipedia talk:Manual of Style/Linking#appearance of section links might be of interest to you. Regards, CapnZapp (talk) 12:16, 6 January 2026 (UTC)

  Three discussions about the same issue seems a bit much. Since you've said you didn't know the RfC existed before creating the new MOS thread, would you mind if it were closed per WP:MULTI? FaviFake (talk) 14:01, 6 January 2026 (UTC)

  They are about different, though related, topics though. Section links to not just appear in "See also" sections. Gawaon (talk) 14:14, 6 January 2026 (UTC)

  Right. Thanks! FaviFake (talk) 19:15, 6 January 2026 (UTC)

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.

Annotated links

Gawaon, the sentence I removed directly contradicts the guidance one sentence earlier, as I explained in my edit summary. It was also added with practically no discussion, so it shouldn't be in here. Just because some people like to do it doesn't mean there should be a "oh hey you can do this bad idea" in the MOS. Please reinstate the removal.

To reiterate, editors are advised to give a bit of context of how the "see also" entry relates to the current topic, but short descriptions are only meant to help quickly identify/disambiguate article topics, and they provide no such context, especially since that context will very often vary from one article to another.

On top of all that, short description content is hosted at the target article, and page content shouldn't be split up across many locations like that. –Deacon Vorbis (carbon • videos) 03:36, 11 December 2025 (UTC)

Where do you see a contradiction? I'd interpret the advice as "Editors should provide a brief annotation when a link's relevance is not immediately apparent, when the meaning of the term may not be generally known, or when the term is ambiguous", but whether they write it manually or adopt the short description via {{anl}} is left to them. Gawaon (talk) 06:07, 11 December 2025 (UTC)

It seems you are concerned that short descriptions are not as helpful as bespoke annotations. Fair point. But is it enough of a difference to not offer the easier short description option, which is more likely to achieve the goal of providing more annotations (albeit, not more ideal ones)? See Perfect is the enemy of good. - Butwhatdoiknow (talk) 17:57, 11 December 2025 (UTC)

This should be removed again. It's not that widely used and it's frankly a bad practice. Usually, no explanation is necessary, just a simple, clean link. If there's an explanation required, then write it, as a human. Short descriptions can be redundant, they can be overlong, they can hide on Wikidata and be changed by random passerby. They're a bad idea and if any guidance is added at all on annotated link, it should be to discourage the use of them. SnowFire (talk) 15:42, 7 January 2026 (UTC)

MOS:ALSO

Can category links be in See also, e.g. Judicial reform#See also? HKLionel TALK 12:35, 5 February 2026 (UTC)

Pretty sure I've seen it elsewhere. I'd say it falls under "a matter of editorial judgment and common sense." Gråbergs Gråa Sång (talk) 16:44, 5 February 2026 (UTC)

Then how should I arrange category links? For Category:United States federal judiciary legislation, do I ignore the namespace prefix and treat the first letter as U, or do I treat it as C and put it at the front? Thanks, HKLionel TALK 00:04, 6 February 2026 (UTC)

I vote for (c), none of the above. Put it at the end of the list after all of the article links. - Butwhatdoiknow (talk) 00:51, 6 February 2026 (UTC)

Funny how in my case it happens to be so, makes sense as well. HKLionel TALK 00:59, 6 February 2026 (UTC)

MOS:NOTSEEALSO, wording

Just noticed it says "As a general rule, the "See also" section should not repeat links that appear in the article's body." My emphasis.

Is this meant to be read that links in the lead doesn't "count" here and are generally fine to repeat in the See also section? Gråbergs Gråa Sång (talk) 16:41, 5 February 2026 (UTC)

No, at times "body" can refer to all textual sections in an article, lead included. That's one of them. Yeah, I know that can be confusing, but it's as it is. General rule of thumb: if the lead isn't mentioned separately, it's considered part of the body. Gawaon (talk) 17:11, 5 February 2026 (UTC)

Makes sense to me. Gråbergs Gråa Sång (talk) 17:18, 5 February 2026 (UTC)

Why would something be linked in the lead, not linked in the body, but be a useful see also? Do you have an example? HJ Mitchell | Penny for your thoughts? 17:18, 5 February 2026 (UTC)

If the question was meant for me, no, I don't have an example, I asked because the wording struck me as ambiguous. I tend to weed See also if I see the need, and wondered if I'd missed something. Gråbergs Gråa Sång (talk) 17:26, 5 February 2026 (UTC)

Mentions of legacy Table of contents

The page makes a reference to the legacy WP:TOC and it also appears in the sample article layout. Could someone provide an up-to-date sample image? I'm concerned being bold and removing the text mention may make things extra confusing if the image isn't updated at the same time. Apologies for the WikiImp behavior, I just don't feel experienced enough to be best placed to handle this. Arandomfolk (talk) 13:36, 18 February 2026 (UTC)

Seeking input on a Further Reading section

Anyone interested in MOS and Further Reading Sections is welcome to weigh in on the one at Sigmund Freud. Discussion is at Talk:Sigmund_Freud#Revisiting_the_Freud_Page Cas Liber (talk · contribs) 06:30, 24 February 2026 (UTC)

Regarding the purposes of "See also" section

I always thought that one of the main purposes of that section is to hold articles on topics that should be mentioned in the body, but aren't yet, and as articles transition to GA/FA, such links will be incorporated into the body, leaving only the odds ones like lists of related topics or such that cannot be mentioned in the main body. Yet I cannot find this in the current description of the section. Should we add something along these lines? _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 01:35, 26 March 2026 (UTC)

It was the purpose, I believe, but certain editors have been trying to change it. For example, User:Randy Kryn is an advocate of adding see also sections when articles already have the links in the body or in the footer or in a sidebar. I will let him explain his reasoning to you. I've asked him not to add them to articles I create but he won't listen. Viriditas (talk) 01:48, 26 March 2026 (UTC)

That roughly matches my understanding of the purpose of these sections as well. Sometimes even in GA and FA there are see-also links that it would be inconvenient to incorporate into the main text or that would bloat the text too much but are relevant enough to list, but they can also be a parking area for subtopics in need of expansion. I routinely undo edits adding see-also links that duplicate links in the main text, pointing to MOS:SEEALSO as the justification for the undo. But I'm not convinced that adding text about this purpose to the MOS would be a good idea; it's too likely to creep into rules about never having see also links in GA/FA or into editors removing valid and relevant see-also links with the rationale that they cannot be converted into article text. —David Eppstein (talk) 02:26, 26 March 2026 (UTC)

I'd rather try to develop some helpful way to say what stuff is valid but cannot be incorporated into body at the GA+ level, while saying its fine and even good to dump stuff into see also at lower levels as a form of "this needs to be in body for this to be a good article" roadmap. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 01:04, 27 March 2026 (UTC)

A simple explanation should be enough to dispel some,butnotall, of Viriditas's portrayal (when a mental picture is made some of it sticks around, the basis of first impressions). What I usually add to his painting articles are, are you sitting down?, See also links to "List of paintings by foo". That's it. Here's his great new art page (and I mean it, one of Wikipedia's best writers), Room in Brooklyn. Note that I added a 'See also' section with one entry, List of works by Edward Hopper. This is allowable and totally within the rules and regs of the See also guideline. But the complaint comes because it also appears in the {{Edward Hopper}} navbox. Is that enough to blank the See also listing? No, not even close. Here's the rub: Navboxes are offered to only 30% of readers. Mobile readers don't get them (their loss). so the footer or side navboxes don't have the firepower to replace a good See also link. As for lists, adding directly related lists to 'See also' has occurred since the first cavewikipedian thought of it. If you have a minute, here's some of my work, which should impress (saying that because the reader increase of some of these things still impresses me). Thanks, and will stop here before my tl;dr kicks in. Randy Kryn (talk) 03:53, 26 March 2026 (UTC)

@Piotrus, I think you're thinking of WP:NOTSEEALSO: As a general rule, the "See also" section should not repeat links that appear in the article's body. ~Kvng (talk) 14:55, 30 March 2026 (UTC)

I think this accurately states how the guideline is intended to operate, although as David Eppstein explains above, it probably should not be enshrined in the guideline itself. That said (and recognizing that I'm probably not saying anything that hasn't been said before), I feel like this gets to the silliness of WP:NOTSEEALSO, which seems to be premised on a hypothetical reader who reviews every link in the article. It is hard to imagine that such reader behavior is very common even for short articles. The idea of a non-editor doing all that for a full-length article -- rather than just clicking down to the "See also" section in hopes of finding other interesting articles on related topics -- seems exceptionally implausible. NOTSEEALSO is of very long standing and probably not realistically changeable, but it's hard to imagine who it is intended to serve. -- Visviva (talk) 05:07, 21 May 2026 (UTC)

There used to be a portion that read ... as many high-quality and comprehensive articles do not have a "See also" section, although some featured articles such as 1740 Batavia massacre and Mary, Queen of Scots include this section. —Bagumba (talk) 05:35, 21 May 2026 (UTC)

The claim being made in that edit summary does not appear to be correct. Suggest the wording be reversed: most don't, though some do. Nikkimaria (talk) 04:34, 22 May 2026 (UTC)

The current wording ("the section itself is not required; many high-quality and comprehensive articles do not have one") seems fine to me. Gawaon (talk) 06:38, 22 May 2026 (UTC)

I think the main problem with moving away from WP:NOTSEEALSO towards a more inclusive guideline is defining where you stop. We don't want an entire topic index in this section; that's what portals, list articles, navigation templates and categories are for. ~Kvng (talk)

Adding recommendations for splitting large sections with additional headings

Currently, Wikipedia:Manual of Style/Layout#Headings and sections states "Very short sections and subsections clutter an article with headings and inhibit the flow of the prose. Short paragraphs and single sentences generally do not warrant their own subheadings." However, it does not mention how long sections can also be problematic. I would like to add the following text, or something similar, after the quoted section above:

"Very long sections, consisting of too many paragraphs, makes article navigation more difficult and inhibits the reader's understanding of the section's topic. Sections typically are not longer than four paragraphs, although there are situations where longer sections are preferred. If a section is five paragraphs or larger, consider splitting it with headings or subheadings. The likelihood that a section needs to be split increases with the number of paragraphs it contains."

I look forward to reading thoughts on this addition. Z1720 (talk) 17:22, 5 May 2026 (UTC)

Five paragraphs is normal and harmless. Once a section has more than 10–12 paragraphs, I'd consider splitting. Gawaon (talk) 18:04, 5 May 2026 (UTC)

• @Gawaon: Nine paragraphs for a section seems very high to me. If I was evaluating an article for GA and there was nine paragraphs under a level 2 heading, I would recommend adding one or two level 3 headings to that section to split up the text. I chose four because MOS:LEAD used to limit the lead to four parargaphs, so I figured that was a good benchmark. Z1720 (talk) 01:18, 6 May 2026 (UTC)

  Four is far too short a threshold for MOS-based discouragement, this is WP:CREEP, and we should be evaluating length based on relevance of content not on bean-counting. —David Eppstein (talk) 01:29, 6 May 2026 (UTC)

Personally I think context plays a big role in evaulating how to split sections, so I think I'd rather not have a specific metric, and continue to leave it up to the interested editors to discuss on a case-by-case basis. isaacl (talk) 02:27, 6 May 2026 (UTC)

Agreed. Maybe I’m not browsing the right pages, but I find overlong sections to be a very rare occurrence, to the degree that I feel adding explicit instructions would cause more harm than help.  novov talk edits 03:40, 6 May 2026 (UTC)

I think that a reminder about splitting is good.

I think that longer sections should be split "naturally", i.e., according to what makes sense for the content. That could mean having just one sub-section (though Miss Snodgrass would disapprove) or having one that's longer and a second that is very short.

Over the years, I have seen multiple editors say that short subsections are easier for them to read and to find the thing they're interested in. Short(ish) sections with lots of headings is a generally recommended accessibility approach for people with dyslexia. Consequently, I usually take a "live and let live" approach to that. When I write an article, I put in the number of section headings that makes sense to me, and when someone else writes an article, I don't (usually) interfere if they put in more section headings than I would have (unless it's a long list of section headings with one bullet point or one sentence each. There are limits, after all). WhatamIdoing (talk) 06:14, 6 May 2026 (UTC)

Both overly long and overly short sections have issues, but where the balance lies is something that can only be determined in the context of the individual article. A section containing two long, information dense paragraphs can be appropriate, as can a section containing ten short and simple paragraphs, the latter particularly if they are split up by non-prose material such as formulas. Thryduulf (talk) 10:01, 6 May 2026 (UTC)

• I do not in principle object to a reminder that splitting overlong sections is good, but I would resist the urge to put in a specific threshold. This is a classic WP:CREEP problem. Once we make a rule (9 paragraphs, maybe?) it can be taken as a license to write sections having 9 paragraphs, when that is already (usually) far too long. Some sections with fewer paragraphs would benefit by subsectioning, others possibly not, and it's hard to imagine thresholds that would cover all potential use-cases. Sławomir Biały (talk) 10:33, 6 May 2026 (UTC)
• For easy access to information, rather than sections of equal size, I feel it's more important to have some consistent organization of sections for that topic area (and there are already MOS guidelines for many of these). Making recommendations by size could mean artificially associating information which would be better separated or arbitrarily splitting content that should be united. For example, film articles (below the GA level) often have the plot section as the longest in the article, but I don't feel it would make sense to recommend splitting it into subsections. Nor would it make sense to jam other sections together simply to balance size with the Plot section. – Reidgreg (talk) 13:26, 6 May 2026 (UTC)

  I'd also like to note that layout changes can be disruptive, and I fear that a guideline like this could offer free license for a certain type of editor to make widespread layout changes throughout the encyclopedia, hampering the efforts of those who are trying to balance the sections through content expansion (which should be the goal). – Reidgreg (talk) 13:36, 6 May 2026 (UTC)

  And on that note, frequent changes to section headings is likely to increase the issue of broken section redirects. Thryduulf (talk) 14:06, 6 May 2026 (UTC)

• Outside of say a few chronological history sections, where splitting raises questions about periodisation that may not neatly align with five-paragraph splits, I can't think off the top of my head of running into this very often. Over-long sections tend to naturally sort themselves into distinguishable sections as the prose is refined (good writing keeps a topic somewhat together), whereas overshort sections can result from a structure being created before the content is considered. CMD (talk) 13:37, 6 May 2026 (UTC)
• I'd like to note that this talk section has (after making this comment) 18 paragraphs, and does not have additional headings. We do add these headings to some megathreads, but only when they get much longer than this. I do not think that, at the current length, the lack of headings inhibits the flow of the discussion; in fact I think the opposite would be true. —David Eppstein (talk) 06:55, 7 May 2026 (UTC)