It's been submitted and pending, so it will be available in a few hours. This update made a lot of improvements for glossaries, both large and small. On my test site I had 6k terms and here I have 2.6k terms.

On a side note, if anyone is using an SEO plugin that has a similar feature to SEOPress IndexNow, please comment with the plugin. I had to add an exclusion for SEOPress because on imports, especially large ones, SEOPress was hammering the server/site for the IndexNow processing. Now that process happens AFTER the terms are processed instead of during.

• Improve performance and caching for large term libraries.
• Add bulk term management, health fixes, and complete term cleanup.
• Improve import reliability, cancellation, progress, and count refresh.
• Add SEOPress-aware IndexNow queue controls.
• Preserve Block Editor definitions and special characters when saving.
• Update compatibility metadata, documentation, and user manual.

I was doing some final testing and had planned to push out the update this evening when I discovered a potential issue that occurs on sites with larger glossaries/terms count... much larger than anyone currently has that I'm aware of on my testing site, 5000 terms.

I am in the process of fixing this so folks don't run into the same issue, so the next update is delayed.

Hi Jeff,

First, thanks for the plugin — the glossary structure and Term Studio are exactly what I needed, and I've built it out quite far. I'm probably running one of the largest installs out there, so I wanted to share some performance data that may be useful as you plan ahead.

My setup

• 644 glossary terms, each with a full definition
• ~1,300 articles that link to them automatically
• Single WordPress site, roughly 2,000 indexed pages

What I measured

The generated term map (/wp-content/uploads/clevlite-map/map-*.js) is now 454 KB uncompressed, and it loads on every page of the site, including articles that reference no glossary term at all.

Breaking down its content:

So roughly three quarters of the payload exists solely to power hover tooltips.

Why this matters

Two problems compound here.

First, tooltips don't exist on mobile. There's no hover on touch devices. Yet mobile visitors still download and parse all 334 KB of tooltip text they can never trigger.

Second, the file is served with Brotli, so the network transfer is fine — the cost is parsing and execution, and compression doesn't help there.

Here's what Lighthouse reports on one of my article pages (PageSpeed report):

• 526 KB of unused JavaScript flagged (essentially this file)
• 1.7 s of JavaScript execution time
• 2.7 s of main-thread work
• 8 long tasks on mobile
• CLS 0.231 on desktop — Lighthouse also flags a forced reflow, which I suspect comes from linked-terms.jsinserting links into already-rendered text
• Mobile lab LCP: 7.4 s on a throttled 4G connection

Google Search Console flags 1,000+ URLs on my site for CLS as a result.

One more angle worth knowing about: PageSpeed now has an "Agentic navigation" category — how readable a site is for AI agents. My page scores 1/3 on desktop, and CLS is one of the two failing audits. So this now affects AI visibility, not just Core Web Vitals.

What would help

A few ideas, in rough order of how much they'd help me:

• An option to exclude tip fields from the generated map. Even just a toggle — sites that don't use tooltips, or that accept losing them, would drop the file by ~75% instantly.
• Load tooltip definitions on demand, via a small REST request on hover, rather than shipping all of them upfront. Best of both worlds, and it would scale to any glossary size.
• A filter hook on the map data before it's written, so site owners can strip fields themselves without patching the plugin.
• Only enqueue the map where it's needed — glossary pages and posts that actually contain linked terms.

Is there already a way?

Before I work around this myself: is there an existing setting or filter to disable tip generation that I've missed? I've gone through General, Styling and Add-Ons without finding one. If there's a hook I can use today, that would unblock me immediately.

Happy to run tests on my install if that's useful — I have a large, real-world dataset and I can measure before/after on request.

Thanks again for the work,
Fabien — youtips.com

Jeff Brigman is this plugin MCP friendly?

This update is a performance and reliability hotfix focused on larger glossaries, frontend tooltip payloads, block/embed rendering, and relationship phrase linking.

The biggest improvement is how Clever Linked Terms handles tooltip data on the frontend. Tooltip payloads are now much smaller, the Tooltip Characters setting is respected properly, and linked terms no longer duplicate large tooltip data directly into every linked item on the page.

What’s improved:

– Better frontend tooltip payload performance for larger glossaries
– Tooltip payloads now respect the Tooltip Characters setting
– Tooltip text now prefers term summaries/excerpts before falling back to definition content
– Reduced duplicated tooltip data in linked term markup
– Improved block/embed rendering safety on glossary term pages
– Fixed relationship phrase linking setting persistence in some configurations

Thank you to Fons for reporting the payload issue.

The update should be available through WordPress.org/plugin updates in less than 6 hours.

Plugin page:
https://wordpress.org/plugins/clever-linked-terms/

Hi Jeff,

I run a French glossary of 502 terms on youtips.com using Clever Linked Terms 1.2.1, and I had to disable the WordPress Content module because every page on the site had grown to roughly 4 MB. I dug into the cause and wanted to share what I found, since I think three of these are straightforward fixes on your side and would benefit anyone running a large glossary.

1. The whole glossary is serialised inline on every page

Clevlite_WPContent::enqueue_assets() builds the payload with 'tip' => $t['definition'], where the definition is the entire post_content of the term, stripped of tags. With 502 terms averaging 11,110 characters each (longest: 48,866), the window.CLEVLITE = {...} inline script measures 3.66 MB, and it is re-sent on every single page load.

Measured on my install:

The tooltip only ever displays the first couple of lines, so the remaining ~3 MB is downloaded and parsed for nothing, on every page.

2. The tooltip-length setting is read but never applied

This one looks like a simple oversight. In includes/class-portal-assets.php, build_terms_payload() opens with:

private static function build_terms_payload(): array {
    $tip_chars = Clevlite_Settings::tipchars();   // line 169

$tip_chars is never used anywhere below. The Tooltip characters setting in the admin UI therefore has no effect at all. Applying it in both payload builders would fix the size problem on its own.

3. The two payload builders disagree

Clevlite_PortalAssets::build_terms_payload() (FluentCommunity) prefers post_excerpt when it exists:

$tip = $t->post_excerpt ?: wp_strip_all_tags($t->post_content);

Clevlite_WPContent::get_all_terms() (WordPress content) ignores post_excerpt entirely and always takes the full post_content. Aligning the WordPress path on the FluentCommunity behaviour, and honouring tipchars in both, would make the two modules consistent.

4. Definitions are re-encoded in base64 on every occurrence

In assets/linked-terms.js, lines 621 and 623, each matched term gets the full definition base64-encoded into a data-clevlite-tip-b64 attribute:

'... data-clevlite-tip-b64="' + escAttr(b64encode(termData.tip)) + '"'

Base64 adds ~33%, and the attribute is written once per occurrence. With maxLinks = 4, an 11 KB definition appearing four times adds roughly 60 KB to the DOM for that single term. Looking the definition up by data-term-id in the existing array at hover time would avoid the duplication entirely.

5. the_content is re-entered on itself

includes/class-cpt.php, lines 746–748:

remove_filter('the_content', [$this, 'append_relationships_to_single_term'], 20);
$rendered = apply_filters('the_content', $raw_content);
add_filter('the_content', [$this, 'append_relationships_to_single_term'], 20);

Only your own callback is detached, so every third-party the_content filter runs twice on glossary term pages. In my case a related-terms block I had added rendered twice, with a duplicated HTML id. I worked around it with a nesting-depth guard, but other plugins hooking the_content will hit the same thing without knowing why. Passing the raw content through a narrower set of filters, or setting a public flag while re-entering, would spare them the surprise.

6. Feature request: allow the glossary CPT in Post Types

includes/settings-tab-wordpress.php, line 29:

unset($clevlite_post_types['clevlite_term'], $clevlite_post_types['attachment']);

I understand excluding attachment, but excluding clevlite_term means glossary entries can never link to one another. On a 502-term glossary, that is exactly where interlinking carries the most value — and it leaves every entry as a dead end for crawlers. If the concern is self-linking, filtering out the current post ID from the payload on singular views would handle it. An opt-in checkbox would be very welcome.

What I did on my side

Rather than patch your plugin (which updates would overwrite), I wrote two small mu-plugins:

• One intercepts the inline script before it is printed, truncates each tip to 300 characters, and serves the payload from a content-hashed external .js file. Pages went from ~3.8 MB to 170 KB; the map is now downloaded once per visit instead of once per page, and cached for a year.
• One adds a server-side "See also" block at the bottom of each glossary entry, since the plugin cannot link entries to each other.

Both are workarounds for the outside. Fixes 2 and 3 in particular seem cheap and would help every install with a sizeable glossary.

Happy to test a patch or share the mu-plugin code if that is useful. Thanks for the plugin — the tooltip UX itself is genuinely nice, and the glossary is central to my site.

Best regards,

Fabien Fons
YouTips — youtips.com

This update improves the Gutenberg / WordPress Block Editor support introduced in v1.2.0, with fixes focused on reliability, block embeds, and the Term Studio editing experience.

If you’re using the Block Editor for glossary term definitions, this update improves how block-based content renders on the front end and fixes an issue where scrolling inside the embedded Block Editor could stop working.

Term Studio still manages the structured glossary fields like summaries, sources, relationships, tags, SEO, and linking settings, while the Block Editor can handle richer definition content when enabled.

What’s improved:
– Improved Block Editor support inside Term Studio
– Fixed block embeds and dynamic block rendering on glossary term pages
– Fixed scrolling inside the embedded Block Editor
– Improved reliability for block-based definition editing
– Classic/WYSIWYG definition editing remains available when Block Editor support is disabled

The update should be available through WordPress.org/plugin updates in less than 6 hours.

Plugin page:
https://wordpress.org/plugins/clever-linked-terms/

v1.2.0 has been sent to the repository, and should be available for update in 24hours via your dashboard. This version adds support for Gutenberg/Blocks Builder in the Term Studio editor. You have to enable this in the settings as the default is the TS Editor.

Hi!

I've been messing around with having Clever Linked Terms in the FluentCommunity template and for some reason, it creates a huge gap when I do! Offset setting is at 0.

You can check it out here on the staging site: https://staging.shanistutoring.com/glossary/

This update focuses on smoother management, better compatibility, and cleaner workflows for larger glossaries. Please note that WP has finally decided to implement safeguards against instant availability of a plugin update via dashboard whenever a dev pushes their update to the Repo. They now require a 24 wait for review on all updates, so you should see an update notice tomorrow this time.

What’s new:

• Optional SEO fields in Term Studio, with support for SEO title, meta description, Open Graph title/description, and social image.
• SEO plugin detection for Yoast SEO, Rank Math, SEOPress, and All in One SEO.
• Duplicate term detection when creating new terms or importing terms, with duplicates saved as drafts for review.
• Faster admin workflows with AJAX-style filtering/search and pagination for Term Manager and heavier Terms Engine screens.
• New optional compatibility fields for placing shortcode/content before or after the definition and metadata areas on single term pages.
• Better import/export handling, including SEO fields and compatibility placement fields.
• Improved CSV/XML downloads and export handling for larger glossaries.
• More performance polish around Terms Engine, relationship data, and optional module loading.

Clever Linked Terms is free on WordPress.org:

https://wordpress.org/plugins/clever-linked-terms/

User Manual:

https://jeffbrigman.com/clever-linked-terms-user-manual/

Change Log:

https://jeffbrigman.com/clt-change-log/

Join the community:

https://jeffbrigman.com/community/space/linked-terms/home