About this plugin
Autolinker builds internal links between the posts you already have. It reads
each post, finds the most semantically related pages on your site, and asks a
language model to choose an anchor phrase that already exists, word for word, in
the source text (capitalisation aside). The link is then written into the post
content and kept in a registry so it can be tracked, repaired, or removed later.
There is no keyword list to maintain. Relevance comes from meaning, not from
matching strings.
How it works
- Embedding. Each post is converted to a vector with an OpenAI embeddings
model, stored locally, and refreshed only when the content changes.
- Candidate search. Cosine similarity ranks every possible target above a
configurable threshold.
- Filtering. A first model pass drops candidates that are topically close but
editorially wrong.
- Anchor selection. A second model pass proposes an anchor phrase. The plugin
verifies the phrase appears in the source exactly, capitalisation aside; the
linked text keeps the capitalisation of your post. If the phrase is not there,
the link is rejected rather than forced.
- Writing. The link is inserted with a marker attribute so the plugin can find
its own links again without guessing.
Every rejection is written to a journal with a reason, so an empty result is never
indistinguishable from a broken plugin.
IMPORTANT: this plugin relies on a third-party service
Autolinker does not work without an OpenAI API key that you supply. The plugin
com), a third-party service that is not
org.
What is sent: the text content of the posts you choose to process, the text of
your link targets (up to 8,000 characters each, to compute the embeddings
that match them), the titles and excerpts of candidate link targets, and the
prompts the plugin builds around them. Your API key is stored encrypted in your
WordPress database and is sent to OpenAI to authenticate each request.
When it is sent: in these four cases, and no others:
- When you publish a post or update a published one. This processing on publish
is on by default; you can switch it off in Settings (“Full auto on publish”).
- When you trigger a scan yourself.
- When you add a post type to the link targets in Settings: its published content
is queued for embedding.
- After a plugin update that changes the plugin’s database, or when the embedding
model changes (the plugin uses a larger model on multilingual sites): your link
targets are queued for embedding again.
The last two cases run in the background through WP-Cron, even with “Full auto on
publish” switched off. They only send content that has no embedding yet, or whose
text or embedding model has changed since its embedding was computed.
What is not sent: no data is sent to the plugin author, and no post content
leaves your site other than to OpenAI, as described above.
One clarification about link health. The plugin also checks whether the links in
your content still resolve. That check runs on a schedule and makes ordinary HTTP
txt, which it
honors. It sends none of your content and involves no third-party service: it only
visits the addresses you already link to. Those requests identify themselves with a
user agent naming the plugin and your site URL, so the hosts you link to can see that
the request came from your site.
Using this plugin means your content is processed under OpenAI’s terms. Please read
them before installing:
- OpenAI Terms of Use: https://openai.com/policies/terms-of-use
- OpenAI Privacy Policy: https://openai.com/policies/privacy-policy
- OpenAI API data usage policies: https://openai.com/policies/api-data-usage-policies
You pay OpenAI directly for the tokens the plugin consumes. See the FAQ for cost
control.
Features
- Semantic candidate search with a configurable similarity threshold
- Anchor validation against the source text (word for word, capitalisation
aside), so anchors are never invented
- A per-post link budget and anchor length bounds (default 2 to 6 words)
- Silo mode, to keep links inside the same category
- Per-post exclusions: exclude entirely, as a source only, or as a target only
- Link health: periodic checking, broken link detection with a failure threshold,
and an orphaned state when a link disappears from the content
- Slug refresh: when a target’s permalink changes, the links Autolinker placed to
it are rewritten. Links you added by hand are never rewritten automatically;
those that point to an old post slug are listed on the Link health screen, with
an “Update href” button for each one
- Elementor support, including posts stored in Elementor’s own data structure
- A decision journal covering every link placed and every candidate rejected
Multilingual
Sites running WPML or Polylang are detected automatically and links are kept inside
a single language. A French post never links to its English translation.
Detection requires at least two active languages, with WPML as with Polylang: a
site with a single language is treated as monolingual. Translation layers that render
on the fly without duplicating posts (TranslatePress, Weglot, GTranslate) are treated
as monolingual, because only the original content exists in the database.
On a multilingual site the plugin switches to a larger embedding model for better
cross-language separation. When the site changes mode (a second language added, or
removed), every post is queued once to be embedded again with the new model, which
means a one-off token cost for the whole catalogue.