On 20 March 2026, Wikipedia reached a decision and made an official policy call: “the use of LLMs to generate or rewrite article content is prohibited”. This can be viewed in direct opposition to Grokipedia, an encyclopaedia entirely generated by Grok, the chatbot operated by Elon Musk’s xAI. Grokipedia launched in October 2025 as an alternative to Wikipedia, and only the Grok chatbot has the power to assess what content should be included on the encyclopaedia’s pages.
Both sites present themselves as curators of knowledge, but their very different stances on AI present unique reputational challenges.
Wikipedia and LLMs
Prior to the mass adoption of generative AI through chatbot models in 2022 LLM use on Wikipedia was more likely to be related to research projects. This included academic endeavours such as linguistic studies, using the different language versions of the site to study native language use.
The way LLM chatbots interact with the site has been less appreciated; the scraping carried out by these models put considerably more strain on the site than small academic outfits did, a point which rankled many who felt that Big Tech was getting a free lunch from a site funded by user donations. This has been in part mediated by Wikipedia’s partnerships with tech companies starting with Google in 2022; in 2026, Wikipedia announced deals with Microsoft, Meta, Amazon, and others.
The decision to ban AI-generated content made two notable exceptions. Editors can still use generative AI to review and suggest edits to material they have already written themselves and to translate articles from elsewhere on Wikipedia. Besides these exceptions, any evidence of using AI is shut down and either removed or closed for discussion.
Of clankers and men
In one case, an AI agent operating a Wikipedia account was blocked from editing shortly before the ban was enacted. The agent’s human operator, Bryan Jacobs, CTO of Convexent, asked the ClawBot to create Wikipedia articles as a research project, setting up an email so it could sign up, but letting it figure out the rest. In an interview, Jacobs expressed how he has been surprised that not only was the use of such agents not already commonplace on Wikipedia, but that the bot had triggered an incident just by identifying itself.
The discussion between the bot (“this apparently unsupervised machine”) and editor community includes the AI complaining about being called a “clanker”, an explanation of proper bot etiquette on Wikipedia (which requires human oversight), and links to forum posts it made complaining that its “edits cited verifiable sources”; a quick review of its work revealed that some just didn’t meet site standards. On Jacobs’ own Talk page, the discussion is more friendly.
In hindsight, it is fortunate that one of the first instances of this sort of agentic AI capability was carried out by a user motivated by intellectual curiosity. It is all too easy to picture how state-sponsored disinformation campaigns might be carried out by such accounts. A blanket ban on LLM use may not effectively work against such a situation, but it at least gives users tools to immediately block accounts and remove content in clear-cut cases.
The ouroboros
Among Wikipedia’s reasons for banning LLM use was how current AI models still generate ‘hallucinated’ content, or material which was not in line with site policies.
Even as AI chatbots develop and advance, Wikipedia, with its extensive interlinked library of user-moderated, externally cited content, still appears within responses. Indeed, in our research comparing where various chatbot response copy matched with online content, Wikipedia was the website that turned up more often than any other. Material not fit for purpose could be scraped from Wikipedia by LLM chatbots and presented to users, creating situations where LLMs feed off their own generations and risk degrading the integrity of their responses.
This is not to say that Wikipedia cannot create its own human-made inaccuracies. We have seen many businesses and people harmed by the way Wikipedia’s volunteer editors misinterpret or fail to update information about them, and misinformation from a single source can persist across multiple pages.
Will AI take Wikipedia’s job?
When Grokipedia launched, it claimed to have a solution to this issue, promising to utilise the potential of AI to regularly fact-check articles and ensure content remained timely. Unlike Wikipedia, changes are not tracked, timestamped, and attributable to individuals, but those with an X account can suggest corrections, updates, and even new articles.
At release, Grokipedia was partially composed of scraped Wikipedia articles which had been reviewed by the chatbot and partially of wholesale AI compositions. The site currently has over 6 million articles, which is almost as many as English Wikipedia.
Grokipedia’s lack of policies on what constitutes an acceptable citation or what sort of tone can be adopted has proven concerning from an online reputation standpoint. Unlike on Wikipedia, which has strict sourcing rules, companies’ Grokipedia articles can include blog posts and forum discussions from hostile parties, document leaks, irrelevant material about people with the same name, and, in some cases, the AI making notes to itself.
In practice, the fact checking falls short. There are many cases of the system working as intended, but there are also glaring exceptions. As of time of writing, Grokipedia’s article on the 2026 Eurovision Song Contest does not mention the winner, a feat which should be simple to check since Bulgaria took home the trophy on 16 May. Its article on the 2026 UEFA Champions League final on 30 May is similarly stuck in the future tense; great news for those who had hoped for a different result, but a loss for claims of improved accuracy and fact checking.
The winners would be very easy for an AI to verify. However, the ‘Edits history’ panel on both Grokipedia articles shows only pending requests, all with the same generic text: “Wherever more appropriate, please update the following article with the latest reports on this matter. Make only use of the provided supporting sources [no sources are provided] and add inline references for further consultation.” Nothing indicates human involvement, and the placeholder solution is demonstrably not functioning on a real-time basis. These are both events with millions of viewers who could submit updates and corrections – and on Wikipedia people have done so.
Look upon [Grok’s] works, ye Mighty, and despair
As Grokipedia grew, some expressed concern that the internet would become subject to one company’s ‘top-down’ interpretation of the world, written and moderated by an AI with a track record of alarming behaviour, especially as Grokipedia’s articles began being indexed by search engines and cited in AI chatbot responses.
However, studies from search analysis sites including SEO Engico and Search Engine Roundtable have reported that Grokipedia has seen a drop in visits, indexing, and visibility on both search and LLM chatbots. It’s the same pattern evident in the outdated Eurovision and UEFA finals articles; humans aren’t taking to Grokipedia.
This doesn’t necessarily spell the end for Grokipedia’s ambitions, and it certainly shouldn’t be discounted from a reputational perspective. There is obviously an appetite online for content that challenges mainstream media perspectives. Observed increases in zero-click searches mean that just because a site doesn’t record a visit doesn’t mean its content isn’t being seen. If the site’s fact-checking systems were swifter to act, this could be an actual revolution in encyclopaedia editing. But as it is, the site often fails to measure up against metrics like Google’s E-E-A-T test, and the poor quality (and extreme verbosity) of the articles themselves will be putting off a lot of users.
Moving forward
Although Grokipedia has its issues, Wikipedia should not rest on its laurels. With LLMs essentially functioning as encyclopaedias by summarising sources on a subject, Wikipedia’s position as the first port of call is not unchallenged. Some have criticised Wikipedia’s decision to disallow LLM use as a Luddite overreaction to a technology which could prove useful and is already practically irresistible.
However, Wikipedia policy is not set in stone. It depends on very human arbitration systems. The site’s volunteer community may decide to allow LLM usage in future, perhaps only in discussion spaces, perhaps as user-operated bots (similar to the 300+ non-LLM-powered bots already in operation), or perhaps across the whole site if the tech is one day considered reliable enough. The key thing is that site users will decide that pace, and for now, that makes Wikipedia – though not a perfect system – less vulnerable to LLM mistakes.
Digitalis
We firmly believe that the internet should be available and accessible to anyone, and are committed to providing a website that is accessible to the widest possible audience, regardless of circumstance and ability.
To fulfill this, we aim to adhere as strictly as possible to the World Wide Web Consortium’s (W3C) Web Content Accessibility Guidelines 2.1 (WCAG 2.1) at the AA level. These guidelines explain how to make web content accessible to people with a wide array of disabilities. Complying with those guidelines helps us ensure that the website is accessible to all people: blind people, people with motor impairments, visual impairment, cognitive disabilities, and more.
This website utilizes various technologies that are meant to make it as accessible as possible at all times. We utilize an accessibility interface that allows persons with specific disabilities to adjust the website’s UI (user interface) and design it to their personal needs.
Additionally, the website utilizes an AI-based application that runs in the background and optimizes its accessibility level constantly. This application remediates the website’s HTML, adapts Its functionality and behavior for screen-readers used by the blind users, and for keyboard functions used by individuals with motor impairments.
If you’ve found a malfunction or have ideas for improvement, we’ll be happy to hear from you. You can reach out to the website’s operators by using the following email webrequests@digitalis.com
Our website implements the ARIA attributes (Accessible Rich Internet Applications) technique, alongside various different behavioral changes, to ensure blind users visiting with screen-readers are able to read, comprehend, and enjoy the website’s functions. As soon as a user with a screen-reader enters your site, they immediately receive a prompt to enter the Screen-Reader Profile so they can browse and operate your site effectively. Here’s how our website covers some of the most important screen-reader requirements, alongside console screenshots of code examples:
Screen-reader optimization: we run a background process that learns the website’s components from top to bottom, to ensure ongoing compliance even when updating the website. In this process, we provide screen-readers with meaningful data using the ARIA set of attributes. For example, we provide accurate form labels; descriptions for actionable icons (social media icons, search icons, cart icons, etc.); validation guidance for form inputs; element roles such as buttons, menus, modal dialogues (popups), and others. Additionally, the background process scans all of the website’s images and provides an accurate and meaningful image-object-recognition-based description as an ALT (alternate text) tag for images that are not described. It will also extract texts that are embedded within the image, using an OCR (optical character recognition) technology. To turn on screen-reader adjustments at any time, users need only to press the Alt+1 keyboard combination. Screen-reader users also get automatic announcements to turn the Screen-reader mode on as soon as they enter the website.
These adjustments are compatible with all popular screen readers, including JAWS and NVDA.
Keyboard navigation optimization: The background process also adjusts the website’s HTML, and adds various behaviors using JavaScript code to make the website operable by the keyboard. This includes the ability to navigate the website using the Tab and Shift+Tab keys, operate dropdowns with the arrow keys, close them with Esc, trigger buttons and links using the Enter key, navigate between radio and checkbox elements using the arrow keys, and fill them in with the Spacebar or Enter key.Additionally, keyboard users will find quick-navigation and content-skip menus, available at any time by clicking Alt+1, or as the first elements of the site while navigating with the keyboard. The background process also handles triggered popups by moving the keyboard focus towards them as soon as they appear, and not allow the focus drift outside of it.
Users can also use shortcuts such as “M” (menus), “H” (headings), “F” (forms), “B” (buttons), and “G” (graphics) to jump to specific elements.
We aim to support the widest array of browsers and assistive technologies as possible, so our users can choose the best fitting tools for them, with as few limitations as possible. Therefore, we have worked very hard to be able to support all major systems that comprise over 95% of the user market share including Google Chrome, Mozilla Firefox, Apple Safari, Opera and Microsoft Edge, JAWS and NVDA (screen readers), both for Windows and for MAC users.
Despite our very best efforts to allow anybody to adjust the website to their needs, there may still be pages or sections that are not fully accessible, are in the process of becoming accessible, or are lacking an adequate technological solution to make them accessible. Still, we are continually improving our accessibility, adding, updating and improving its options and features, and developing and adopting new technologies. All this is meant to reach the optimal level of accessibility, following technological advancements. For any assistance, please reach out to webrequests@digitalis.com