FAQs, Wikis, and Knowledge Bases in SharePoint: What Fits Where

Posted on May 12, 2026

FAQs, Wikis, and Knowledge bases sound similar enough that most organizations treat them as interchangeable, and that is exactly why their company knowledge ends up scattered, duplicated, or out of date. They are actually three different formats, each built to solve a different problem, and getting the match right is one of the highest-leverage decisions you will make about how your intranet content is organized. In this post, I will walk you through what each of the three actually is, what kind of content fits each one, how to decide where a given piece belongs, how the three coexist in a healthy intranet, the most common mistakes I see, and how Copilot and AI change the picture.

The three options at a glance

Option	What it is	Best for	Governance Level
FAQ	Short Q&A entries with definitive answers	Recurring questions with short answers – “how do I…”, “what is…”, “where do I find…”	Light. One owner per topic, occasional review.
Wiki	Collaborative, evolving content with many contributors	Living documentation that benefits from many editors – team conventions, project notes, technical docs	Light to moderate. Open contribution, light editorial review.
Knowledge Base	Formally published, structured articles with clear ownership	Definitive how-to guides, reference material, official procedures	High. Named owner per article, review cycle, gated publishing.

Option 1: FAQs

An FAQ (Frequently Asked Questions) is the simplest of the three options. Each entry is a question, paired with a short, definitive answer. The questions are usually narrow in scope (“what’s the office address?”, “how do I request time off?”, “who do I contact about expense questions?”). The answers are usually a few sentences at most. The format is meant to be skimmed, not read.

FAQs work best when the same questions get asked over and over, and the answers are stable. They are particularly valuable when embedded directly on department pages, where employees naturally land when they have a question for that team. A few well-placed FAQ entries can dramatically reduce the volume of repetitive emails to HR, IT, Finance, and other shared services.

The size of that repetitive-question tax is bigger than most teams realize. IDC’s research on the cost of not finding information estimates that knowledge workers spend roughly 2.5 hours a day searching for information, and that an enterprise of 1,000 employees loses about $5.7 million a year to inefficient knowledge retrieval. Even a small dent in that number – say, the routine HR or IT questions – pays back the modest cost of a well-placed FAQ many times over.

They work best when

Recurring questions with short, definitive answers.
Embedded on department pages where employees naturally look.
Light governance – one owner per FAQ section, occasional review.

They do not work well

What FAQs do not work well for is content that requires depth, has multiple variants, or evolves frequently. The moment an answer needs to be more than a few sentences, you’ve outgrown the FAQ format and should be writing a knowledge base article or a wiki page instead. The discipline of keeping answers short is what makes FAQs scannable; the moment they grow, the format breaks down.

Example of an FAQ Section in SharePoint using the FAQ Web Part

Option 2: Wikis

A wiki is collaborative, evolving content with many contributors. The defining feature is open contribution – anyone on the team can add, edit, or expand content. Wikis work because they accept that knowledge is messy, that it changes, and that the people closest to the work are usually the best ones to capture it. They trade structure and authority for breadth and freshness.

Wikis are particularly valuable for engineering teams, project teams, and any group where knowledge evolves through discovery and the contributors are knowledgeable peers. Team conventions, project notes, technical decisions, troubleshooting tips, internal lore that nobody would think to formally document – all of these fit naturally on a wiki. The lower friction of contribution is the whole point.

This is exactly the dynamic Etienne Wenger described when he coined the term “communities of practice” — groups of people who share a topic or set of problems and deepen their expertise through ongoing interaction. A team wiki is the digital surface for that kind of community: it works because the people closest to the work are the ones writing things down, and because contribution is easy enough to actually happen.

They work well

Living, evolving content with many knowledgeable contributors.
Team conventions, project documentation, technical notes, and internal know-how that grows organically.
Light to moderate governance — open contribution with light editorial oversight.

They do not work well

What wikis do not work well for is content that needs to be authoritative across the organization. The same openness that makes wikis good for capturing team-level knowledge makes them risky for company-wide policies, customer-facing reference material, or anything that needs a single trusted version. Wiki content can vary in quality, and that’s acceptable for the use case – but it means wikis are not the right home for content where consistency matters.

Example of a Wiki built using Microsoft Loop

Option 3: Knowledge Bases

A knowledge base is formally published, structured content with clear ownership and a defined quality bar. Each article has a named owner. Each article has a last-reviewed date and a next-review date. Each article goes through a review step before being published. The whole experience is designed to feel authoritative – when an employee finds an article in the knowledge base, they should be able to trust it.

Knowledge bases are the right choice for content that needs to be definitive across the organization. Official how-to guides. Standard operating procedures. Reference material that customer-facing teams cite to customers. The kind of content where inconsistency would cause real problems — disputes, mistakes, compliance issues. The investment in structure and governance pays back through trust over time.

They work well

Definitive, authoritative content that needs to be trusted across the organization.
Official procedures, how-to guides, reference material.
Heavy governance – named owners, review cycles, gated publishing, retirement workflow.

They do not work well

What knowledge bases do not work well for is content that benefits from many contributors and rapid evolution. The same governance that makes them trustworthy also slows down contribution. If your content needs to be fast-moving and openly editable, a knowledge base is the wrong format — you’ll either fight the governance, or you’ll abandon it, and either outcome is worse than just using a wiki.

Example of a Knowledge Base built using Microsoft Lists and SharePoint Pages

How to decide which one fits a piece of content

When you’re trying to figure out where a specific piece of content belongs, four questions usually settle it:

How long is the answer? If it’s a few sentences, it’s an FAQ. If it’s a few pages, it’s a knowledge base article or a wiki page.
Who’s it for? If it’s for a specific team, a wiki probably fits. If it’s for the whole company or for customer-facing teams, a knowledge base is usually right.
How often does it change? If it evolves rapidly through team contribution, a wiki. If it changes occasionally and needs review when it does, a knowledge base. If it’s stable for long stretches, a FAQ if short or a knowledge base if long.
How much does it matter if it’s wrong? If a wrong answer creates real risk (compliance, customer-facing, cross-team), it belongs in a knowledge base with proper ownership and review. If a wrong answer is recoverable and the team will fix it, a wiki is fine.

Most pieces of content settle naturally into one option when you walk through these four questions honestly. The few cases that genuinely fit two options usually mean the content needs to exist in both – for example, a complex topic might warrant a full knowledge base article AND a short FAQ entry that answers the most common version of the question with a link to the full article.

How the three options coexist

The most important shift in thinking is recognizing that these aren’t competing options. The right setup uses all three, each handling the content type it fits best:

FAQs sit on department pages, embedded directly where employees go for help with that team. Each shared services team (HR, IT, Finance, Operations) maintains its own FAQ section.
Wikis sit on team sites for the groups that benefit from collaborative documentation — engineering teams, project teams, departments where peer-contributed knowledge is core to the work.
The knowledge base is the company-wide, authoritative source for content that needs to be consistent and trusted across the organization.

These three layers point at each other, which makes sense. A FAQ entry might link to the full knowledge base article for employees who want more detail. A wiki page might reference the relevant knowledge base article as the authoritative source on a related topic. A knowledge base article might reference the wiki for the team-level context behind a procedure. The layers work together – each one playing the role it’s designed for.

Common mistakes that come from confusing the options

When companies try to make one resource do all three jobs, predictable problems show up. The most common mistakes I see:

Forcing wiki content into a knowledge base. The heavy governance kills contribution. The team that was happily updating a wiki page stops contributing the moment they have to file a request and wait for review.
Forcing knowledge base content into a wiki. Without ownership and review, official content drifts out of date or gets edited inconsistently, and employees lose trust in the wiki for the questions where they really need a definitive answer.
Building one giant FAQ for everything. The format breaks down once answers get long, the categories get unwieldy, and the FAQ becomes a poorly-structured knowledge base in disguise.
Maintaining the same content in two places. Sometimes a topic genuinely needs both an FAQ entry and a knowledge base article, but the FAQ should be a short summary that links to the article — not a duplicate of it. Keeping two copies in sync is a maintenance trap.
Treating the wiki as the company’s official knowledge base. Wikis are great for what they’re great for. They are not a substitute for the structure and governance that an authoritative knowledge base requires.

The principle that ties it all together

Here is the framing I want you to leave with. Match the format to the content, not the content to the format. A piece of content has natural characteristics — its length, its audience, its rate of change, and the cost of getting it wrong. Those characteristics determine which option fits. Forcing content into the wrong option almost always produces a worse outcome than picking the right option in the first place. Tom Davenport made the same point a generation ago in Working Knowledge, the seminal book on knowledge management: technology should account for at most a third of any KM effort, while culture, roles, and content discipline carry the rest. The format you choose for a piece of content is one of those discipline decisions, and getting it right is what makes the technology actually work.

Companies that get this right usually have a small inventory of all three formats — FAQs on department pages, wikis on team sites, a single authoritative knowledge base — and a clear understanding of what goes where. The result is that each format does what it does best, employees know where to look for the kind of content they need, and the cost of maintaining the entire information ecosystem is dramatically lower than maintaining one overloaded resource trying to do everything.

What about AI? Will Copilot replace any of these?

This is the question I get most often these days, and the short answer is: no, but it does change how each of these options earns its keep. Tools like Microsoft 365 Copilot or the dynamic FAQ web part don’t generate trustworthy answers from thin air. They retrieve content from your sources and then summarize it. That technique is only as good as the content underneath it.

If your wiki is contradictory, your knowledge base is out of date, and your FAQs are scattered across five different places, Copilot will surface the contradictions, repeat the outdated answers, and confidently cite the wrong source. The phrase the AI engineering community uses for this is the oldest one in computing: garbage in, garbage out. Bad information doesn’t become good when an LLM speaks it back to you in a polished sentence – it just becomes harder to question.

This is also the framing that the analysts have settled on. Gartner’s consistent guidance on generative AI in knowledge management is to focus on augmentation, not replacement: use these tools to amplify the value of well-curated content, not to substitute for the work of curating it. With more than 80% of enterprises projected to have generative AI in production by 2026, “well-curated content” is going to be the input that decides whether your AI is impressive or embarrassing.

So if anything, AI raises the importance of getting these three options right, not the opposite. A clean FAQ becomes the trusted answer Copilot quotes back to an employee asking how to submit an expense. A well-tended wiki becomes the team-context layer the AI uses to make its answers feel local instead of generic. A governed knowledge base becomes the authoritative source AI cites when the stakes are high. The options don’t go away in an AI-first world – they become the input quality that decides whether the AI is worth trusting.

All Articles