Organize Wiki Pages
Keep the knowledge base searchable and easy to maintain.
The best wiki structure is simple enough that teammates know where to look and specific enough that search results are useful.
Group Pages by Team or Workflow
Create pages around how the team works:
- Sales playbooks
- Client onboarding
- Project delivery
- Finance operations
- Support responses
- HR policies
- Internal tools
Choose one primary grouping style. Mixing team names, client names, and random topics at the same level makes the wiki harder to scan as it grows.
Decide the Page Owner
Important wiki pages should have an owner. The owner does not need to write every update, but they are responsible for keeping the page current and deciding when old guidance should be archived.
For cross-team pages, name the process owner rather than every team involved. This prevents outdated shared pages from becoming nobody's responsibility.
Use Consistent Naming
Use predictable title patterns:
How to ...Checklist: ...Policy: ...Playbook: ...Template: ...
Consistent titles make pages easier to find from search.
Use verbs for workflow pages and nouns for reference pages. For example, How to prepare a renewal quote is a workflow, while Policy: refund approvals is a
reference page.
Avoid Duplicate Pages
Before creating a new page, search for the topic. If a page already exists, update it instead of creating a competing version.
When two pages cover the same process, keep the one with the clearest owner and latest review date. Merge useful details into that page and rename or archive the older page so search results stay clean.
Link Related Pages
At the bottom of longer pages, add links to related wiki pages, files, Agiled records, or help docs.
Link to the source of truth rather than copying everything. For example, link to a workflow, form, template, project, or finance setting when the wiki explains how that item should be used.
When a wiki page describes a repeatable process, link to the exact form, template, workflow, report, dashboard, or project view the team should use. This keeps the wiki actionable instead of becoming a separate manual nobody follows.
Review Structure Regularly
Review wiki organization after new modules, teams, workflows, or customer processes are added. A structure that worked for five pages can become hard to navigate after the knowledge base grows.
Create Navigation Paths
Important pages should be reachable in more than one way: search, related links, section placement, and links from active records or workflows. If a page is critical for finance, HRM, support, onboarding, or delivery, link to it from the process page where the work actually happens.
Do not rely on memory or chat history to help teammates find core processes. The wiki structure should guide them to the current page.
Archive Instead of Deleting
When a page is obsolete but may be useful for history, rename or archive it instead of deleting it immediately. Add a note pointing to the current page so searchers do not follow old instructions.
Maintenance Checklist
During review:
- merge duplicate pages
- rename vague titles
- archive obsolete process notes
- add owners or review dates to critical pages
- replace copied instructions with links to current records when possible
- search common terms and confirm the best page appears
After cleanup, ask one teammate who did not write the wiki to find a common process. Their path through search and links shows whether the structure works.