How to Move Your Plugin Docs from a GitHub Wiki to WordPress

Updated October 19, 2026

Your plugin’s docs live in a GitHub wiki because that was the quickest place to start. Now customers can’t search it from your site, the pages don’t match your brand, and half your buyers never find the wiki at all.

To move a GitHub wiki to WordPress, you clone the wiki and import it with one WP-CLI command. Core Support turns every Markdown page into a native block doc in a collection, keeps the order from the wiki’s sidebar and rewrites the links between pages. Everything lands as drafts first, so nothing goes public until you’ve checked it.

Core Support is my help desk plugin for WordPress, and Docs is one of its modules. The importer also reads docs sites, single pages and wordpress.org readmes, as Import Existing Documentation covers. This guide is the wiki route from start to finish.

Before You Start

WP-CLI on the server where Core Support runs. Imports have no screen in wp-admin.
Git, to clone the wiki.
A collection for the product. Create it under Core Support → Collections, or with WP-CLI:

wp term create csp_collection "My Plugin" --slug=my-plugin

Clone the Wiki

Every GitHub wiki is its own Git repository, at the repository address plus .wiki.git:

git clone https://github.com/owner/my-plugin.wiki.git

Clone it onto the server, or clone it locally and upload the folder. A private repository’s wiki needs the same access as the repository.

Run a Dry Run First

wp core-support docs import markdown ./my-plugin.wiki \
  --source-base=https://github.com/owner/my-plugin/wiki \
  --collection=my-plugin --dry-run

The dry run lists each page with its title, slug and source address, and saves nothing. Check 3 things in that list:

The order. A wiki’s _Sidebar.md sets it. Pages the sidebar doesn’t list follow in file-name order.
The titles. Each comes from front matter title:, then the first # heading, then the file name.
The first page. Home.md becomes an Overview doc and comes first.

Always pass --source-base. It’s the wiki’s public address, and the importer uses it to remember each page. Without it, links between pages aren’t rewritten and a second run adds every page again.

Import as Drafts

Drop --dry-run to import for real:

wp core-support docs import markdown ./my-plugin.wiki \
  --source-base=https://github.com/owner/my-plugin/wiki \
  --collection=my-plugin --section="Documentation"

--section puts every page under one section doc. A wiki has no folders, so without it each page becomes its own section, which is rarely what you want. You can regroup pages into more sections in the editor afterward by setting each page’s parent.

The importer converts as it goes:

Headings, paragraphs, lists, code, quotes and images become native blocks.
Tables become Custom HTML blocks, which render the same and never fail block validation.
A quote that starts with [!NOTE], [!TIP] or [!WARNING] becomes a callout.
[[Page Name]] wiki links become links to the matching doc.
Images are copied into the media library once each.

Files whose names start with _, such as _Sidebar.md and _Footer.md, aren’t imported as docs. A folder import reads only the .md files directly inside the folder, not those in subfolders.

Review and Publish

Open Core Support → Docs and filter by the collection. Each imported page is a draft.

Read each doc in the editor. Fix anything that only made sense on GitHub, such as “see the sidebar”.
Set Last reviewed in the Doc details box, or tick Reviewed today.
Publish.

The collection shows on /docs/ once it has at least one published doc. Until then, only people who can write docs see it.

Run It Again Safely

You can re-run the same command while you review:

Pages new in the wiki are created.
Pages that haven’t changed are left alone.
Drafts nobody has edited are refreshed from the wiki.
Docs you edited or published are kept, with a warning naming each one.

So a fix made in the wiki reaches an untouched draft on the next run. Once you edit or publish a doc, the importer stops touching it, and later fixes happen in WordPress.

Point Readers to the New Docs

The wiki stays on GitHub after the import, and WordPress can’t redirect a github.com address. So the old pages need a signpost:

Replace Home.md in the wiki with a short note and a link to your new docs.
Add a link from the repository’s README to the collection.
Consider turning off the wiki under the repository’s settings once the new docs are live, so nobody finds an outdated copy.

Each imported doc keeps its wiki address under Old addresses in Doc details, so you always know where it came from.

When the Import Goes Wrong

What you see	What it means	Fix
Nothing to import	The folder has no `.md` files at its top level	Point the command at the cloned wiki folder itself
No collection with that slug	The collection doesn’t exist yet	Create it first and use its slug
Every page imported twice	`--source-base` was missing on one of the runs	Delete the duplicates and always pass the same `--source-base`
An image keeps its GitHub address	The image couldn’t be copied	The import prints a warning per image; upload it by hand and replace it

What It Won’t Do

It doesn’t sync. The import is a one-time move with safe re-runs while you review. After that, the docs live in WordPress.
It won’t create sections from a flat wiki. Use --section, then regroup in the editor.
It can’t redirect github.com addresses. Use the signposts above.

Once the docs are live, How to Keep Your Docs Version in Sync with Your Latest Release keeps their version badge current without editing every page.