weDocs - WordPress Plugin

A Practical Guide to Setting Up a Knowledge Base with weDocs

This guide is for WordPress site owners who need more than a few published help articles. It explains how to turn a collection of articles into a clear knowledge base: plan the content hierarchy, create documentation and sections, publish a landing page, help visitors find answers, and make sure editors do not break navigation. weDocs matters here not as another text editor, but as a layer for organizing and presenting help content on top of standard WordPress.

You will find more than installation instructions below. The guide also covers the decisions that follow: which documents to create first, how to separate public and internal materials, where to use the weDocs - Docs Grid block, when search should remain the primary navigation method, and when a predictable hierarchy is the better choice. It also covers feedback, access permissions, migration from BetterDocs, and safe testing in a separate browser window.

The plugin interface may change, so compare exact tab names and the availability of advanced features with the edition you have installed. The guide follows a dependable working approach: start with structure and content, then move on to presentation, access, and improvements. This order reduces the risk of creating a polished but unhelpful help page.

What weDocs Is Designed to Solve and When It Makes Sense

A documentation plugin is usually installed because the same questions keep coming up: how to get started with a service, where to change a setting, why an email did not arrive, or what an order status means. When answers are scattered across staff notes, blog posts, and several pages, visitors have to guess where to look. weDocs helps you build a dedicated support area with top-level documents, sections, and articles, plus public-facing navigation, search, and article actions.

The main value is not the number of published articles. A useful knowledge base shortens the path from a question to an action that can be verified. For example, a SaaS product can use the product name as a document, with sections for getting started, accounts, integrations, and errors, and articles for specific tasks. An agency can use services or client portals as top-level documents. A store can organize content around shipping, returns, product selection, and warranties. The point is that readers choose their context first, then a topic, and only then open an instruction.

The plugin works for both public help centers and managed internal knowledge bases. Official descriptions and documentation confirm support for unlimited documents and knowledge bases, the block editor, drag-and-drop ordering, nested structures, and quick search. Advanced capabilities come with separate conditions: permissions, privacy, help widgets, the assistant, and some presentation options should be checked against the edition available to you rather than building a process around a feature that is not included in your installation.

Do Not Confuse Documentation with a Blog or a Page Directory

A blog post answers, "What is new, and why does it matter?" A service page persuades visitors and leads them toward an inquiry. A knowledge base article should answer a different question: "What should I do now to get the expected outcome?" It therefore usually includes one action, prerequisites, a sequence of steps, a visible sign of success, and a short troubleshooting path. If a piece of content contains no action, it may remain an overview page, but it should not take up space in an instructional sequence.

This distinction affects editing decisions. Instead of a help-center heading such as "A New Service Feature," use "How to Add a Team Member to a Project," and keep the news item as additional context. Instead of one oversized article called "Everything About Settings," create a parent section and separate articles organized around user goals. weDocs does not automatically improve weak content, but it makes this architecture visible and easier to maintain.

Who the Plugin Is For and When Another Approach Is More Sensible

weDocs is especially worthwhile when the site has a recurring subject area that needs its own navigation: product documentation, a support answer base, internal policies, an instruction library for partners, or plugin documentation. Editors do not need to manually rebuild a menu with dozens of links after every change; documents, sections, and articles become the foundation.

It may be excessive for a site with three static pages and no plans to grow. In that case, standard WordPress pages and a simple menu are usually enough. Be cautious with a knowledge base that requires a complex multi-stage editorial workflow involving legal approval, mandatory version history, or external synchronization with an engineering repository. Define and test those requirements in a staging environment before installation, because needing documentation does not mean every plugin can cover the entire knowledge-management process.

A useful selection criterion: if visitors need to independently follow the path "choose a topic - find an article - complete an action - return to work," a dedicated weDocs structure is usually more logical than a random collection of pages. If that path does not exist, improve the WordPress content and menu first.

Map the Future Knowledge Base Before Your First Click

The most common mistake when launching a knowledge base is opening the plugin dashboard and immediately creating ten articles. A month later, titles are duplicated, critical instructions are buried on the third level, and someone who cannot sign in has no idea whether to open the account, security, or error section. Start with a small map that fits in a note or spreadsheet: a top-level document, four to seven sections, key articles, and the reader's path.

In the weDocs model, a top-level document defines the scope of a topic, a section groups related tasks, and an article solves one question. The official instructions for creating a document show the path WP Admin > weDocs > Add Doc; the section documentation demonstrates that sections belong to a parent document. This is more than a technical hierarchy. It should match the way users describe their problem.

Build the Tree Around Tasks, Not Product Interface Labels

Imagine a knowledge base for a small cloud service. An impractical tree mirrors admin-menu items: "Settings," "Users," "Reports," and "Integrations." A new user may not know that the needed action is hidden under "Users." A more human-centered map begins with goals: "Getting Started," "Team and Access," "Workflows," "Connections," and "Troubleshooting." Articles can name the exact interface item inside the content, but the entry point to the knowledge base should make sense to a person rather than a developer.

For every planned article, fill in five lines in advance: the reader's question, prerequisites, the action, the outcome, and a link to a related article. For example: "How to invite a colleague" - the administrator knows the email address - sends an invitation - the colleague sees an email or an entry in the list - with a nearby link to access roles. This exercise reveals gaps before publication.

Where to Draw the Line Between a Section and a Long Article

A section groups materials that readers browse for one goal. A long article is justified when its steps must be completed in order and skipping one makes the next unclear. If every subsection answers an independent question, those are candidates for separate articles. For example, "Connecting a Domain" can be one instruction with sequential steps. "DNS," "Email on Your Domain," and "HTTPS" should not be combined without a reason: they have different prerequisites, signs of success, and errors.

Do not turn three levels into a mandatory ritual. Nesting exists to reduce cognitive load, not to display complexity. If a section contains one article, first ask whether that intermediate level is needed. If an article title becomes a long string containing four separate ideas, the document probably needs to be split.

A Starter Set of Materials That Gives Readers a Foundation

For a new product, a good starting knowledge base usually includes an introductory article, a short path to the first outcome, core tasks, answers about access and billing only when they relate to the product itself, and a troubleshooting section. You do not need to write an encyclopedia in a week. It is more important to cover recurring real-world questions already reaching support, chat, or comments.

• Start with an article called "Get Your First Result in a Few Minutes" that includes a specific verification step.
• Add a separate article about roles and access if actions differ for administrators and regular users.
• Organize errors by symptoms rather than internal module names.
• Create a feedback page so the team can see what readers were missing.
• Add a link to the next logical step at the end of every key instruction.

This map makes it easier to decide later whether you need a dedicated document for partners, developers, or employees. Do not mix audiences in a single sequence. If an article for a customer suddenly includes an administrator action, either move it into a staff note or clearly identify the role and provide a safe handoff.

Preparing WordPress: What to Check Before Installation

Installation takes minutes, while fixing the consequences on a live site can take much longer. Before you begin, create a backup using the method standard for your hosting environment and make sure you have administrative access to WordPress. The official plugin listing publishes minimum WordPress and PHP requirements, but compatibility should be checked against your actual site environment and active extensions before an update.

Also decide where the knowledge base will live. A dedicated page is usually easier to explain to users and easier to measure in analytics. If the section already exists, record its URL and make sure it does not compete with another page or category. The weDocs Home option is intended to select the page that displays documentation, so decide on the knowledge base home before adding content.

Check Roles, Your Theme, and the Publishing Approach

Do not give every author identical permissions just to get started quickly. First list who creates documents, who writes articles, who publishes, and who can change global settings. Advanced weDocs features include permission management, including separate access settings for documents and settings. Even if you currently use only the core features, this role matrix protects the hierarchy from accidental reordering or publication of a draft.

Your WordPress theme affects content width, heading styles, sidebars, and block rendering. Open a test page on a wide screen and on a real phone, but do not try to write CSS exceptions in advance. First inspect the standard output: heading readability, line length, link contrast, active-item state, and the appearance of long titles. If the theme uses aggressive global styles, that does not automatically mean it conflicts with weDocs, but it does require separate testing.

A Checklist That Actually Saves Time

• You have a database and file backup, or a clear restoration point provided by your host.
• An administrator is assigned who can roll back the plugin or a setting after testing.
• A knowledge base page has been selected and its future permalink has been checked.
• The first 10-20 questions have been collected from support, sales, editors, or customers.
• The roles of editor, author, reviewer, and settings owner have been documented.
• A separate browser window or visitor-role account is available for testing the outcome.

Agree on naming rules in advance as well. Some teams use question-based titles, while others begin with a verb, such as "Configure Notifications." Choose one approach that fits the audience. Predictability matters more to readers than perfect terminology. Internal names in the dashboard can remain short, but public titles should be understandable without knowledge of your internal operations.

Installation and a Safe First Launch

The official instructions describe two standard methods. In the WordPress dashboard, open Plugins > Add New, search for weDocs, install it, and activate it. The second method is to upload a ZIP archive obtained from the official directory through Plugins > Add New > Upload Plugin. For a typical site, the first option is more convenient: WordPress retrieves the package from its directory and provides the normal update process.

After activation, do not rush to move all your old documentation. First make sure the weDocs section appears in the dashboard and opens without a critical error. Then create one test document, one section, and one short article. Official documentation recommends creating the top-level item through WP Admin > weDocs > Add Doc; you can then add sections and articles in the selected hierarchy.

Minimum Post-Activation Check

1. Open Plugins and confirm that weDocs is marked Active.
2. Go to weDocs and create a test document with a neutral title.
3. Add a section called "Testing" and a short article with one line of text.
4. Save the content and open the public documentation page in a private browser window.
5. Check that the title, navigation, and article link are available to visitors as expected.
6. Delete the test entries, or rename and expand them if they have become the foundation of the actual structure.

Do not test the installation with dozens of real articles immediately. One document helps separate an activation problem from an import error, permission issue, or structural problem. If the dashboard does not open, the public page is blank, or the block editor behaves unusually, first temporarily deactivate only the recently added plugin and see whether the symptom disappears. Then check your hosting and theme error logs. Do not change the theme, PHP version, and several extensions at the same time; otherwise, the cause becomes impossible to distinguish from coincidence.

How to Choose the Knowledge Base Page Without Losing Navigation

In weDocs settings, find the documentation home-page selector and connect it to the page you prepared earlier. After saving, open the address directly, then reach it through the site's main menu. These are two different tests: the first checks the plugin output, while the second checks the theme menu and link. If the knowledge base should appear in the header, add a dedicated menu item only after its permanent address and section name have been determined.

When the knowledge base is not located on the site homepage, add a short context label above its link: "Help," "Help Center," or the product name. Do not use the unclear word "Documents" if the business already uses it for contracts. Readers should understand that the link leads to instructions and answers, not downloadable files.

Building a Working Hierarchy in the weDocs Dashboard

After testing comes the real work. Create a top-level document through weDocs > Add Doc, give it a name that explains the subject area, and avoid turning it into a promotional headline. Add sections at the next level, followed by articles. Official materials describe section creation and drag-and-drop ordering, so you can improve the sequence as real questions appear instead of trying to predict navigation forever.

This mechanism has a clear cause-and-effect chain: an editor creates a document as a topic container, adds a section as a route for a task, publishes articles as specific actions, and visitors receive sidebar navigation and a path through the hierarchy. The outcome is visible not only in the admin dashboard. Open it from the perspective of a new reader and check whether the needed instruction can be reached without search in two or three meaningful steps.

Article Order and the One-Task Rule

Drag-and-drop becomes especially useful after launch, when it becomes clear that people read content in a different order from the one the team considered logical. Put introductory content first, followed by the next safe step, and place articles about specific errors near the relevant action or in a dedicated "Troubleshooting" section. Do not build navigation around the principle of "what matters most to the company goes at the top." In help content, the visitor's common path matters more.

Every article should make one primary promise. A good export article explains exporting, checking the finished file, and a known limitation. It should not simultaneously teach account creation, role configuration, and integration setup. Links to related materials are more useful than one enormous universal text. If readers arrive from a search page, they can complete the specific task and continue through a clear link when necessary.

What to Put at the Beginning, Middle, and End of an Article

Start with the outcome and the scope: "After these steps, you will see..." or "This guide is for administrators..." Then list the preparation required for the action to work. Put the sequence in the middle. After an important save action, show the verification point: which message, email, page element, or status change should appear. At the end, mention a common symptom and link to the next article.

This format makes content quality easier to evaluate. If an editor cannot name the verification step, the instruction is not ready yet. If an error is explained only by the name of an internal class or module, rewrite it in terms of an observable symptom. Users should not need to understand how your system is built in order to report that a button is missing or an email never arrived.

Three Levels of Nesting and Greater Depth

In the core weDocs model, it is convenient to treat document, section, and article as the main sequence. The plugin page mentions a three-level nested structure, while advanced-edition documentation includes a separate article about deeper hierarchy. Do not use greater depth simply because it is available. The deeper the tree, the more important search, breadcrumbs, and clear titles become. For most customer help centers, several well-named sections are better than a maze of subsections.

If you need to separate a large volume of content, first create separate top-level documents by audience or product. This creates a cleaner separation than endlessly deepening one document. For example, "For Users," "For Administrators," and "For Integrators" can serve as different entry points with different sets of permitted actions.

Settings That Shape the Reader Experience

Go to weDocs > Settings after creating at least one test item. Official help lists core fields: the weDocs home page, feedback email delivery, recipient address, article helpfulness rating, comments, and printing. You do not need to enable everything. At first, configure only what your team is prepared to respond to and verify.

Settings are not dashboard decoration; they are a promise to visitors. If feedback email is enabled, specify an inbox that someone actually reads. If comments are allowed, assign a moderator and an expected response process. If articles include a helpfulness rating, decide in advance who will review negative signals every week and turn them into editorial tasks. Otherwise, the interface creates an expectation of dialogue and the knowledge base quickly loses trust.

A practical order for initial configuration

Setting	When to enable it	Verification	Safe rollback
weDocs Home	When the permanent help page has been selected.	Open it directly and through the site menu.	Restore the previous page after documenting the cause.
Email feedback	When someone is responsible for incoming messages.	Send a test message from a public article.	Disable the option until email is configured.
Helpfulness rating	When the team will analyze the responses.	Click both options in a test article and confirm the signal is recorded.	Hide the block if nobody processes the data.
Comments	When moderation and communication rules are in place.	Test publication and spam handling.	Disable it if irrelevant messages become frequent.
Article printing	When readers save policies or instructions.	Open browser print and review headings, links, and page breaks.	Disable it if the theme's page format is unsuitable.

Feedback Without False Promises

A "helpful/not helpful" rating alone does not explain what went wrong. It is useful as a prioritization signal. Near critical instructions, add a simple sentence such as: "If this step differs from what you see in your dashboard, tell us the section name and include a screenshot without personal data." This turns an emotional "it doesn't work" into material that can improve the article.

Test the feedback address by more than submitting a form. Check who sees the message, whether it reaches spam, which subject line arrives, and whether there is enough context to identify the article associated with the message. Do not ask visitors to send passwords, tokens, personal data, or a full dashboard screenshot. Documentation should reduce risk, not teach people to bypass it.

Printing and Comments: Enable Them for a Real Use Case, Not Out of Habit

Printing is not necessary for every article. It barely changes the experience for a short tip, but it can be highly useful for a step-by-step policy or an on-site instruction. Check whether screenshots are cropped, unnecessary navigation elements are printed, and step numbers remain in the proper order. If needed, have a theme developer adjust the appearance in a child theme or a safe area for custom styles rather than changing plugin files.

Comments make sense when discussion genuinely improves the knowledge base: for example, when several customers clarify the same step and an editor can turn the answer into an article update. If the knowledge base serves as public help and the team is not ready to moderate messages, feedback through a dedicated channel is usually more honest. An open comment is not a replacement for a support system and should not become a place to share confidential information.

Search and Navigation: Do Not Make Readers Guess Their Path

A good structure does not eliminate the need for search. Visitors rarely enter a knowledge base at the beginning, especially if they found an article through Google or an email link. They may encounter an unfamiliar term, search for an exact error message, or not know which section contains the action. weDocs supports search on the documentation page and quick search within documentation. Official advanced-search instructions describe a dialog available on an individual document page that accepts a keyword query; they also list Command+K for macOS and Ctrl+K for Windows.

Do not treat search as a replacement for architecture. It works well with precise wording, but it cannot rescue a knowledge base where every heading is vague: "General Questions," "Miscellaneous," or "Additional Information." Users cannot guess an editor's wording. Titles should therefore include both the object and the action: "Change the Notification Address," "Check Editor Access," or "Find an Order Number." Synonyms are fine inside the text, but there is no need to repeat the key phrase in every sentence.

The Chain: "Query - Found Article - Next Step"

Imagine a visitor entering "email not received" into search. The plugin may lead them to an article about email notifications, but the quality of the outcome depends on the article itself. The first paragraph should name the problem area, then show how to verify the address and sending status, and finish with related links: checking the spam folder, changing the recipient address, and contacting support. Search then ends with a specific action rather than reading alone.

Measure more than search-query volume; look for signs of unsuccessful searches. If people type one word and leave immediately, the knowledge base may lack the needed article or its title may be written in internal language. Every few weeks, select recurring support requests and test whether they can be found through search without knowing the navigation. This is an editorial test that attractive view statistics cannot replace.

Navigation Within a Long Article

The official plugin listing includes blocks for breadcrumbs, a sidebar, document navigation, a table of contents, printing, and font-size controls. Their availability does not mean you should add them all at once. For a long technical instruction, breadcrumbs, a table of contents, and links to the previous or next article are usually justified. For a short answer, a heading and one back link may be enough. The more secondary elements you add, the harder it becomes to notice the actual instructional step.

Test navigation in two modes. In the first, readers start from the knowledge base homepage and choose a path through sections. In the second, they open an article link directly. In both cases, they should understand where they are, what the content relates to, and where to go if the article does not answer their question. If the sidebar hides the active item or the heading gets lost among promotional theme blocks, simplify the page before adding another widget.

Words That Help Search Without Turning an Article into Spam

Use the natural name of the action, object, and condition in the heading and first paragraph. Instead of "Settings," write "Configure Notifications for New Requests." Instead of "Doesn't Work," write "What to Check If the Confirmation Link Will Not Open." In the body text, you can mention once how users usually phrase the problem, then immediately turn it into technically verifiable signs. That is enough to help both site search and external search results without making the page repetitive.

Docs Grid, the Shortcode, and a Knowledge Base Home Page Worth Opening

A knowledge base has two distinct surfaces. One helps editors maintain the tree in the admin dashboard. The other helps visitors begin their search on the public site. weDocs provides several options for the second. According to official documentation, the core shortcode [wedocs] displays documentation on the selected page. The block editor includes weDocs - Docs Grid, which displays documents in a configurable grid.

The choice between them should be based on the nature of the knowledge base, not taste. If you have one document and visitors usually start in the same place, a simple documentation page may be better. If you have several independent topics or products, a grid helps present entry points as separate cards. It should not duplicate a long list of every article. Its job is to provide top-level orientation before the normal hierarchy takes over.

How to Configure Docs Grid Without Pretending Design Solves Everything

The official Docs Grid guide describes adding the block to a new or existing page through the + button, choosing one or two columns, setting the number of documents per page, excluding documents, sorting, controlling the number of displayed sections and articles, and collapsing articles. A separate style tab provides heading and active-child colors, borders, corner radius, spacing, and button appearance.

Start with content rather than colors. First leave only documents that represent independent tasks in the grid. Then choose the number of columns based on title length. If titles are long and include two clarifications, two narrow columns make them harder to read. Next decide whether to show child articles. On the homepage of a large knowledge base, it is often better to leave some materials collapsed so visitors do not face a wall of links. In a small knowledge base, an expanded list may speed up the path.

1. Open the appropriate page through Pages and add the weDocs - Docs Grid block.
2. Choose one or two columns based on title length and theme width.
3. Set an order that reflects user priorities rather than document creation dates.
4. Exclude draft, internal, or temporary documents from the public entry point.
5. Configure the number of sections and articles so the card explains the topic without replacing navigation entirely.
6. Save the page, open it while signed out of WordPress, and test every visible destination.

A dependable grid presents choices, not the entire archive. If visitors see twenty similar links, they have to read them like a spreadsheet. It is better to provide several distinct cards with clear names and let the next level reveal the details.

The Shortcode as a Stable Placement Option

The [wedocs] shortcode is useful when editors need predictable documentation output on a regular WordPress page or inside a builder that supports shortcodes. You do not need to manually copy it into dozens of places: select one knowledge base page, configure it as the home, and point your menu there. Duplicating the same output across different pages creates confusion in links, analytics, and support.

After placement, always check how the theme styles the container. Public documentation should not end up in an extremely narrow column, beneath a huge page title, or beside a sidebar that pulls attention away. The solution usually begins with the page template and theme settings. Do not edit weDocs files to make a one-time spacing adjustment: a plugin update will overwrite your changes. If theme settings and styles are insufficient, use reversible custom CSS only after confirming the selector on a test site and checking it after updates.

A Careful Custom Adjustment for Outer Spacing

If your theme compresses content into an unreadable strip, you can add a custom adjustment in the theme's custom CSS area or a child theme. It is based not on an undocumented weDocs API, but on the standard principle of limiting container width. First use browser developer tools to confirm that the container class actually belongs to your theme rather than being generated incidentally. The example below deliberately uses a neutral class that you should replace only after checking your own markup.

/* Add only after confirming your theme's container class. */
.site-main .your-docs-container {
  max-width: 1180px;
  margin-right: auto;
  margin-left: auto;
  padding-right: 24px;
  padding-left: 24px;
}

Check the knowledge base page on a wide screen, at a medium window width, and on a phone. Rollback is simple: remove only this CSS block and clear the theme or optimization cache if one is in use. Do not put code into plugin files or use it to replace weDocs grid settings. The purpose of the adjustment is to restore readable width, not change the documentation workflow.

Roles, Privacy, and the Boundary Between Internal and Public Help

Documentation often contains two kinds of material: public instructions for customers and internal notes for the team. A boundary mistake is more dangerous than inconvenient navigation because internal information can become available to the wrong audience. weDocs Pro materials describe global documentation editing settings, selection of who can manage settings, individual document privacy, and roles at the individual-document level.

Before enabling access rules, create a simple matrix. The administrator is responsible for global settings and knowledge base pages. An editor can modify approved documents. An author prepares drafts. An external visitor sees only public articles. You may also have a separate contractor or partner group. Do not grant that group permissions "just in case." First verify what it needs to read and what it needs to edit.

How to Test an Access Rule Instead of Just Saving It

In permission-management settings, change one rule, save it, and sign out of the administrator account. Then sign in as a test user with the relevant role or use a separate browser window. Open the documentation list, a direct link to an article, and the editing screen. These three checks matter: sometimes a link is hidden from navigation while the address remains accessible, or reading access is correct but the editor cannot see a necessary button.

Official permission documentation demonstrates global permissions, user selection, individual document configuration, and switching between public and private states. It also shows that editing rights and settings-management rights should not be combined. For a team, that means a simple rule: an editor can update an article without necessarily being able to change global options, feedback addresses, or access for all roles.

A Safe Sequence for Introducing Privacy

1. Create one test internal document with no secret data.
2. Assign the required visibility and editor role in the appropriate management panel.
3. Check the document as an administrator, as an authorized employee, and as a guest.
4. Open the direct link in a private window and through normal navigation.
5. Apply the rule to real materials only after the outcomes match.
6. Maintain a list of internal-document owners so a departed employee does not remain the only editor.

Do not put instructions in a public knowledge base that effectively require administrative secrets. It is better to explain how to safely route the request to the appropriate role, for example: "Contact the site owner and include the document name." Documentation should reduce unnecessary access rather than work around it.

Help Without Leaving the Page: Search, Assistant Widget, and AI Features

When visitors are reading a long instruction, they sometimes need a brief clarification rather than a move to another page. Advanced weDocs documentation describes the Assistant Widget with Explore, messaging, and styling areas. The Explore tab can display materials identified as helpful or selected manually. The documentation also describes hiding the widget on individual pages and customizing its text and colors.

These capabilities are justified when they help visitors complete the current task. Do not add a floating assistant as a decorative button. First define what it should do: show the three most useful articles for a new user, suggest related material, or provide a way to contact support. Then make sure the base navigation and search already work without it. A widget strengthens a good knowledge base, but it does not repair empty content.

The Messaging Widget and Protection Against Automated Submissions

The official Assistant Widget guide describes email address fields and Cloudflare Turnstile integration for the messaging tab. Do not publish keys or other secrets in an instruction or team text document. Enter them only in the settings intended for that purpose. After configuration, send one test message, confirm that visitor verification works, and check the email path through to the responsible inbox.

The use case should be honest. A message button is appropriate for a question an article does not resolve. It is not appropriate for collecting passwords, card data, logs with personal information, or urgent incidents if your team does not promise that level of response. The widget text should briefly explain what data visitors may send: the article address, the step, a screenshot without personal details, and the expected outcome.

Opening Related Documentation in the Current Context

A separate weDocs instruction describes Link Enhancer: when creating a link to another document, you can enable opening it through the Assistant Widget. The materials show display modes including inline, sidebar, and modal. An important limitation in the same instruction is that the mechanism applies to weDocs documents, not standard posts, custom post types, or WordPress pages.

Use it for short context. For example, in an article called "Configure a Domain," the link "What Is a DNS Record?" can open alongside the article when readers need clarification and do not want to lose a filled-out form or a long text. However, a primary instruction with many steps is better opened as a full page: a modal does not replace normal navigation, printing, or an accessible link.

AI Chatbot and AI Doc Writer: Do Not Promise More Than You Have Tested

The current WordPress.org listing includes AI Doc Writer, which can create text from a prompt, product data, or an image, and AI Chatbot as a Pro capability. Chatbot documentation states that it requires at least one enabled documentation set and that answers are generated from knowledge base materials. The practical conclusion is clear: a bot does not replace editorial discipline. If an article is outdated, incomplete, or describes the wrong process, the assistant is highly likely to reproduce the same flaw.

Start with a small controlled set: five to ten stable articles with clear titles, verified actions, and no sensitive information. Create a list of real support questions and test which materials the assistant leads to. If an answer confidently adds a nonexistent step, do not try to hide the issue behind polished wording. Disable the feature for that use case, clarify the original source, and repeat the test. An automated answer should not be the only verification point for an important action.

AI Doc Writer is more sensible as a drafting assistant. An editor must check button labels, access conditions, links, consequences of actions, and the absence of secrets. Do not automatically publish generated text simply because it sounds convincing. An article becomes part of the knowledge base and therefore affects search, chat, and user trust.

Migration, Layouts, and Change Logs Without Losing Meaning

A new knowledge base rarely starts from nothing. More often, a team already has BetterDocs articles, regular WordPress pages, PDF instructions, chat notes, and links in support replies. A migration succeeds not when every record has physically arrived in the new plugin, but when readers retain their path to an answer. Start with an inventory: URLs, audience, owner, current-status review, each article's primary question, and possible duplicates.

Official weDocs documentation describes migration from BetterDocs. Its workflow depends on the original BetterDocs categorization: if categories are missing, the migration tool may be unavailable; after preparation, you select the source, enter the new document title, and review the migration hierarchy. This leads to a cautious principle: check categories and create a backup before launching the migration. Migration is not a reason to publish old disorder through a new interface.

A BetterDocs Migration Plan You Can Stop

Start with a small segment, such as one product or the ten most requested materials. In the source knowledge base, mark uncategorized articles, drafts, old URLs, materials with outdated screenshots, and texts that are really news items. In weDocs, create a test document with an obvious title. Only then open the migration section and see how it proposes mapping the future hierarchy.

Before running the operation, answer five questions. What happens to the source pages? Which addresses must continue working? Which new hierarchy will become public? Who will check links in articles? How quickly can you roll back the experiment if the hierarchy is wrong? If any question has no answer, postpone a large migration. You may first need to organize categories in the source knowledge base or conduct an editorial review.

1. Create a backup and save an exported list of old URLs.
2. Select a small set of articles that does not affect critical customer instructions.
3. Confirm that source materials are assigned to categories that actually reflect the future sections.
4. Create a test document in weDocs and migrate only the selected segment.
5. Compare article count, order, titles, internal links, and public-page availability.
6. Open several old URLs and decide whether redirects are needed through WordPress or hosting.
7. Move the next segment only after acceptance and keep a record of every decision.

Do not use migration as text editing. Move the structure first, then update articles in small batches. Otherwise, you will not know what caused a problem: import, a new theme, a changed address, or a rewritten instruction. One wave of changes should have one verifiable goal.

When Building a New Map Is Better Than Migrating

If old documentation groups material by authors, months, or random marketing campaigns, migration will preserve an ineffective approach. In that situation, use old articles as a source of facts and questions, but design the new tree from scratch. Keep old URLs available until you prepare a redirect map. The reader's path matters more than preserving the historical shape of a menu.

A sign that you need a new map is when the same task is explained in three places, a section title does not suggest the expected outcome, and editors cannot name the article owner. Start with five to twelve key tasks and create a new weDocs tree for them. Then decide the fate of the remaining materials: migrate, merge, archive behind restricted access, or rewrite. Do not remove the old source until you are sure that important links and data are no longer needed.

Documentation Layouts and Styles: Start with Information Hierarchy

Advanced weDocs documentation includes a Layouts and Styles section for choosing the documentation-page appearance and individual-document template, along with settings for colors, content, and navigation. The instructions show that individual options should be selected in settings and evaluated in public view. This order matters: do not choose a style from a dashboard thumbnail until you have seen it on a real article with a long title, a list, a table, and several heading levels.

For most help centers, a calm composition is useful: the article title is prominent, the main text has sufficient width, the sidebar tree does not compete with the steps, links are recognizable without hover, and the active navigation item is visible. Complex decorative elements, huge covers, and overly contrasting cards may be appropriate on an entry page, but inside a technical instruction they usually only increase the distance to the first action.

Do not test presentation on just one short article. Create a test publication with a long title, a six-step list, a warning block, an image, and a link to the previous document. Open it on a wide screen, at medium width, and on a phone. Then increase the browser zoom. If, at larger text sizes, the panel covers the text or buttons become impossible to press, that is not a minor issue: part of your audience reads help content that way.

Minimum Presentation Standard for a Knowledge Base

• The article title is distinct from navigation and does not disappear beside the theme logo.
• Links are visible through more than color alone and have sufficient contrast against the background.
• Long lines do not stretch across the entire width of a large screen.
• Nested menu items remain understandable with long titles.
• Images and code snippets do not overflow their container at narrow widths.
• Links to the next article do not look like promotional buttons or distract from the instruction.

Once this basic quality is in place, move on to colors, border radius, and additional actions. Every style should support understanding. For example, a table of contents is useful in a long article if readers can quickly return to the needed section; in a short article, it creates an unnecessary block before the first paragraph. There is no universal layout, only a reader path that can be tested.

A Change Log as Part of Trust, Not a List of Cosmetic Updates

The weDocs WordPress.org listing and official documentation mention public changelog functionality in Pro. It is useful for a product that frequently changes behavior and needs to explain those changes to users. But a feed containing a hundred technical entries with no consequences for readers does not help. Start by defining the audience: customers need interface and action changes, administrators need configuration and compatibility changes, and developers need integration details.

A good changelog entry answers four questions: what changed, who it affects, whether anyone needs to do anything, and where to read more. Instead of "processing improved," write "The export form field name changed; check your integration if you read it automatically." If no action is required, say so directly. Do not publish internal secrets, keys, or details that could make misuse easier.

Link each change note to the instruction it affects. Then someone arriving through search sees the current step, while an interested user can open the explanation of the change. This is especially important after migration: if article addresses, titles, or locations change, a short explanation and proper redirect reduce unnecessary support requests.

How to Preserve Quality as the Team Grows

As the knowledge base grows, people with different writing styles begin contributing: support staff, product teams, developers, and editors. Do not try to solve this solely by restricting permissions. Create a short editorial card: how to write a heading, where to identify a role, how to format a warning, what counts as verification, and who is responsible for updates. This card can itself be a weDocs article available to editors.

Assign an owner not only to the whole document but also to critical articles. The owner does not have to personally edit every paragraph, but should know whom to contact after a product change. For materials that become outdated quickly, add an internal review date to the editorial process. You do not need to display a date in every public text when readers do not need it. What matters more is that the team does not treat an article as permanent merely because it is well written.

When a new capability appears, first follow the chain: where will users see the change, what action will they take, what will the outcome be, what risk appears if something goes wrong, and which article needs updating? Only then create a new publication. This keeps weDocs a living knowledge base rather than an archive where links are added after a release.

Practical Use Case: Launching a Knowledge Base for a Service with Support

Below is a focused example that can be adapted for a SaaS product, agency, or digital product. The goal is for visitors to independently find instructions for getting started, managing access, and resolving one common error, while the team can identify materials that need improvement. We will not build a huge portal. The important thing is to launch a small but fully verifiable sequence.

Goal and Preparation for the Use Case

Suppose the service receives the same questions repeatedly: how to create a workspace, how to invite an employee, and why an invitation email does not arrive. Prepare three texts, assign a responsible editor, and create a test visitor account. Create a page called "Help Center." Do not publish real employee addresses, internal domains, or dashboard screenshots containing personal data.

Create a top-level document called "Using the Service." Within it, create the sections "Getting Started," "Team and Access," and "Notification Problems." In the first, add an article called "Create Your First Workspace"; in the second, "Invite a Team Member"; and in the third, "What to Check If an Invitation Did Not Arrive." This hierarchy uses subject-focused questions rather than repeating technical dashboard sections.

Editor Steps in weDocs

1. In WP Admin > weDocs > Add Doc, create a document called "Using the Service."
2. Add three sections and place them in the order a new customer would normally follow.
3. Create the first article with the outcome in its first sentence, conditions before starting, and numbered actions.
4. In the invitation article, identify who is allowed to perform the action, where to check the status, and which link to send next.
5. In the troubleshooting article, begin with the observable symptom, then list safe checks that do not require a password.
6. Select the "Help Center" page as weDocs Home and add a link to it in a clear site menu.
7. Add the weDocs - Docs Grid block if independent documents for other products or audiences will appear later.

After publication, do not evaluate quality by the number of articles. Give someone who did not participate in writing the task: "You received an invitation, but no email arrived. Find out what to check." Do not suggest the section name. Do not measure seconds; note the places where they stop or begin guessing. If the tester enters an unsuitable section, that is a valuable signal about titles and structure.

Verifying the Outcome from Both Sides

On the editor side, confirm that the document, sections, and articles appear in the expected order and that drafts have not reached the public page. On the visitor side, open the knowledge base in a private window, follow navigation without a direct link, enter a key phrase into search, and confirm that the first article found answers the question. If you enabled helpfulness ratings or feedback, submit a test and confirm it reached the owner.

Then check the connections between articles themselves. After the workspace-creation instruction, readers should see a link to inviting a team member. In the invitation article, they should find a link to email troubleshooting. In troubleshooting, they should find a clear path to support if the basic checks did not help. This makes the knowledge base a route rather than a collection of articles, where every next transition has a purpose.

How to Verify and Improve the Knowledge Base After Publication

Publishing the first version is the beginning of a cycle, not the finish line. Documentation quickly develops a gap between what the team considers obvious and how readers phrase their questions. It is therefore useful to establish a regular but lightweight review: once a week or after a product change, choose several critical articles and walk through them again in a clean browser.

The review has four layers: access, structure, content, and connection to the real product. Access asks whether the right role can see the material and the wrong role cannot. Structure asks whether an article can be found through the menu and search. Content asks whether the steps match the dashboard. Connection to the product asks whether the action produces the intended outcome. If you check only spelling, the knowledge base may look neat while still misleading readers.

A Small Editorial Review

• Select the three most visited or most critical articles and open them as a guest.
• Check the title, first step, link to the next material, and visibility of feedback.
• Compare interface button names with the current product dashboard.
• Search using the wording of the question rather than the exact article title.
• Confirm that the text contains no test passwords, private addresses, or outdated screenshots.
• Record the change and the reason: a product update, support question, failed search, or new role.

It is useful to keep a short documentation change log in a separate article or editorial process. weDocs Pro includes functionality for publishing a changelog alongside documentation, but you do not need to enable it just for an attractive feed. First decide which changes readers genuinely need to know about: a change in product behavior, removal of a limitation, a new operation, or retirement of an old path. Minor typo corrections usually do not require a public announcement.

What Counts as a Quality Signal

Do not promise that a knowledge base will necessarily reduce support requests or improve search rankings. More realistic signs are modest and useful: fewer identical questions with the same answer, visitors reach the needed article without guidance, editors find the information owner faster, and new materials follow one understandable principle. If requests do not decline, first check whether the needed article exists, whether it is named correctly, and whether it matches the current product.

A negative rating does not always mean the text is poor. Sometimes an article honestly explains that an action is unavailable to the selected role or depends on another setting. In that case, check whether the condition, reason, and next path are stated. A good instruction may not provide the desired answer, but it does not leave readers uncertain.

Troubleshooting weDocs: Symptoms, Checks, and Safe Fixes

It is better to investigate a knowledge base issue from the observable symptom rather than an assumed cause. First identify what is not happening: the plugin will not activate, the page does not display materials, an article cannot be found, an editor lacks access, or the theme breaks the appearance. Then change one factor and verify the outcome in a separate window. This approach prevents a common mistake: disabling several plugins, changing the theme, and clearing all data at once, after which it becomes impossible to know what helped.

The Plugin Will Not Activate or the weDocs Dashboard Will Not Open

Symptom: after activation, a critical error appears, the page is blank, or the plugin section will not load. Likely cause: an incompatible environment, an incomplete installation package, an extension conflict, or an update-related error. The WordPress.org listing changelog includes fixes for activation and block problems in individual releases, so it is especially important to confirm that you are using a current package from the official directory.

What to check: the WordPress and PHP versions against directory requirements, available disk space, hosting error logs, and whether installation completed successfully. How to fix it: temporarily deactivate only weDocs, update it through the standard method from the official source, and repeat the test with one document. If the error remains, save the exact message and list of active extensions for support. Rollback: restore the last known working version from your backup and do not perform a bulk import until the cause is understood.

The Knowledge Base Page Opens but Shows the Wrong Materials

Symptom: visitors see an old list, an empty section, or documentation on another page. Possible cause: the wrong weDocs Home is selected, the page is cached, a similar WordPress page is being used, or an extra shortcode has been placed there. Check: open the page address directly, then review the home-page setting and site menu. Compare the outcome in a private window and a normal browser window.

Fix: assign one clear knowledge base page, save the setting, and clear only the cache that serves this page if you use caching. Then follow the link from the menu. When to roll back: if changing the home page breaks existing links, restore the prior connection first, document the target address, and prepare site-level redirects before trying again.

Search Does Not Lead to the Needed Article

Symptom: a query returns irrelevant materials, or readers do not know where to go after the results. Possible cause: the article has an abstract title, the key term appears only in an image, the document is unpublished, or expectations apply to a different post type. weDocs quick search is intended for documentation, so do not expect it to behave like a universal search across all WordPress objects without separate testing.

Check: enter the reader's question and the exact article title, then compare the results. Open the material as a guest and confirm it is published. Fix: rewrite the title and opening paragraphs in human language, add a link from a related article, and, if necessary, move the material into a more obvious section. Rollback: do not change dozens of titles at once; test one article and see whether the path becomes clearer.

An Editor Sees the Wrong Buttons or Can Change Too Much

Symptom: an employee cannot edit a document, sees settings they should not change, or an internal article opens for a guest. Possible cause: global and individual permissions are mixed, testing is being done in an active administrator session rather than under the target role, or the rule was not saved. Check: use a separate test account for every role and test three addresses: the documentation list, a specific article, and the editing screen.

Fix: restore minimum permissions, save the rule, and add access one level at a time. weDocs documentation distinguishes between people who edit documents and people who manage settings, so do not grant the second permission unnecessarily. When to roll back: if the outcome remains unclear after changing permissions, restore the previous working configuration and test on a separate draft.

Theme Styles Break the Grid or Article

Symptom: cards are too narrow, buttons are unreadable, links lose contrast, or a sidebar covers text. Possible cause: global theme styles, an optimizer combining CSS, or a block conflict. Check: open the page while signed out, temporarily disable only style aggregation in a test environment, and compare the outcome with another WordPress page.

Fix: first use block settings and page-template width, then add a focused reversible style in a child theme or custom CSS section. Do not edit plugin styles. Rollback: remove only the rule you added, clear the cache for this page, and repeat the test. If the issue occurs only with a specific theme, prepare a minimal reproduction for its support team.

A Short Video Introduction to the Editorial Workflow

The official weDevs video, "How to create documentation using weDocs," shows the actual creation and organization of documentation in WordPress. It is useful as a visual complement to the sections about the first document, sections, and articles. Watch it after reading the step-by-step portion: the video helps you see the overall dashboard path, but it does not replace testing your own theme, roles, and public page.

As you watch, pay attention to the point where a document is created and how materials are connected to sections. Then repeat only one small use case on a test document. Do not mechanically transfer everything shown in the recording into a live knowledge base: the interface may change, and your access rules and section names should fit your actual audience.

Questions That Come Up When Implementing weDocs

Can I Use weDocs Without the Advanced Edition?

Yes. The official WordPress.org listing describes the core feature set: documents and knowledge bases, Gutenberg support, nested structure, search, shortcodes, helpfulness ratings, and other blocks. Some advanced features, including certain permissions, privacy options, styles, the assistant, and chat, belong to Pro. Before planning your process, check not just the general feature name but whether it is available in your edition.

What Is the Best First Document to Create?

Create a document that reflects the primary audience or product rather than a technical site category. For one service, this might be "Getting Started with the Service"; for an agency, "Client Portal"; for a team, "Internal Policies." Keep several task-based sections inside it. Do not start with a document called "Miscellaneous": it is almost impossible to develop without confusion.

Do I Need a Separate Page for Every Knowledge Base?

Not always. One entry point is convenient when materials share an audience and visitors can select a topic within it. Several independent documents and the Docs Grid block become useful when different products, customers, or user types should not overlap in the first layer of navigation. Test the decision with someone who does not know your internal terminology.

Why Does an Article Exist in the Dashboard but Cannot Be Found by Visitors?

First check publication status, permissions, and the direct address in a private window. Then review how the heading and opening text are phrased. If they contain an internal component name instead of the user's question, search may not connect the query to the material the way readers expect. Update one article and test the query before making bulk changes.

Can I Open a Related Document Without Leaving the Current Article?

Pro materials describe the Link Enhancer Assistant Widget for links to weDocs documents with several display methods. Use it for small clarifications. For a large instruction, a normal link to a full page is safer so readers receive a predictable address, content, and navigation.

Is weDocs Suitable for an Internal Employee Knowledge Base?

Yes, provided that you have tested access rules and privacy in your edition. Configure permissions first on a test document, sign in under different roles, and check the list, direct link, and editing screen. Do not publish sensitive data before this test, and do not replace access management with a hidden link alone.

Does weDocs Slow Down the Entire Site?

The WordPress.org listing states that scripts and styles in the 2.x branch load only on documentation pages. This does not remove the need for a practical check: evaluate your own site with its theme, cache, and other extensions, compare the knowledge base page before and after installation, and do not draw conclusions from someone else's project. If you notice a problem, document the specific page, action, and active plugins for support.

When Is It Better Not to Use an AI Assistant?

Do not make it the only way to obtain an answer about a legally significant, financial, medical, or sensitive action. Use an assistant only after verifying source articles, testing typical queries, and providing a clear route to a person. For stable recurring questions, it can complement search, but it is not a replacement for quality control.

When weDocs Becomes a Good Next Step

weDocs makes sense when your help content has outgrown a collection of random pages and needs a managed structure: documents, sections, articles, search, a clear entry point, and an improvement cycle based on feedback. The safest start is one real use case, one document, and verification from a guest's perspective. If the path is clear, expand the knowledge base gradually without breaking names and links for the sake of the next trend.

After preparing a backup, selecting the knowledge base page, and compiling your first user questions, you can download the installation file and test the described sequence on a test document. Do not judge the outcome by the number of enabled switches. The main indicator is simpler: a person finds the needed instruction without guidance, completes the action, and understands what to do next.