Turn on Link Graph under WP Visibility → Settings → Modules, load any admin page once, then run wp visibility links rebuild. After that, wp visibility links orphans lists published posts that no other post links to, hubs lists the most linked-to posts, and suggest <id> proposes posts worth linking from a given one. In this release the report is available from WP-CLI, REST and a connected assistant; there is no screen for it in the admin.
What it records
The module keeps a table of which published post links to which, and how many times. It reads the links inside post content when a post is saved:
- Links to your own site count: full URLs on your site’s exact host, protocol-relative ones, and root-relative paths such as
/about/.www.example.comandexample.comcount as different hosts. - External links, anchors within the page,
mailto:and other schemes, relative paths without a leading slash, links that do not resolve to a published post (drafts or archive pages, for example), and links a post makes to itself are ignored. - Menus, widgets, footers, theme templates and links that blocks or shortcodes generate when the page renders are not read. A page linked only from the menu counts as an orphan here.
- Only published posts of public post types are indexed. Unpublishing, trashing or deleting a post removes its links, including the links other posts make to it. If the post is published again, those inbound links return only when the linking posts are saved again or you rebuild.
It adds one parse per save, which is why the module is off by default.
Build the index
Posts saved before the module was on are not in the table until you rebuild:
wp visibility links rebuild
wp visibility links rebuild --batch=100The rebuild shows a progress bar and ends with the number of posts that have outbound internal links and the number of distinct post-to-post links recorded. Over REST, POST /wp-json/wpvis/v1/links/rebuild needs manage_options, processes 200 posts per call and returns processed, remaining, total and complete; call it again with offset set to the number of posts processed so far until complete is true.
The reports
wp visibility links orphans
wp visibility links hubs --limit=10
wp visibility links suggest 123| Report | What it lists | Columns |
|---|---|---|
orphans |
Published, indexable posts with no inbound internal link | id, title, url, outbound_count |
hubs |
The most linked-to posts | id, title, url, inbound_count, inbound_hits |
suggest <id> |
Posts worth linking from post <id> |
id, title, url, reason |
orphans refuses to run until one rebuild has finished, because before that, links from posts not yet indexed are missing and their targets would look like orphans. Noindexed posts are left out of it on purpose. --format takes table, csv, json, yaml or count; --limit defaults to 100 for orphans, 20 for hubs and 10 for suggestions, and is capped at 500, 100 and 25.
Suggestions are computed on the spot from words in the post’s title and from its first category (or its first tag or other public taxonomy term, when it has no category), with no AI involved. The reason column says which: “shares: pruning, tomatoes”, “same category” or, for example, “same tag”. The post itself, posts it already links to and noindexed posts are left out.
GET /wp-json/wpvis/v1/links/report returns the orphans, hubs, dead ends (posts with no outbound internal links) and totals in one response, and needs manage_options. With the Assistant connection module on, the “Get internal link graph” and “Suggest internal links” abilities return the same data to an assistant.
Act on it
An orphan is not always a problem. A thank-you page or a landing page for ads usually needs no inbound links. For an orphan that should be found, add a link to it from two or three related posts, in the sentence where it helps the reader. Then save those posts and the orphan drops off the list.
Behavior checked against WP Visibility 2.10.3.