Web & SEO Autolinker - AI Internal Linking

Yes. The plugin has no bundled key and no free tier of its own. You create a key on your own OpenAI account and pay OpenAI for what you use.

It depends on how many posts you process and how long they are. Two levers reduce it: the per-post link budget caps how many placements are attempted, and embeddings are cached, so a post that has not changed is never re-embedded.

Yes. Links are written into the post content, with a marker attribute so the plugin can identify its own links later. This is deliberate: the links are real HTML, they survive in exports, in feeds, and for search engines, and they do not depend on a filter running at display time.

The links stay in your content, because they are ordinary HTML. Link tracking, health checks and repair stop until you reactivate.

By default, everything is kept. Tick "Delete data on uninstall" in Settings and uninstalling removes everything the plugin created, except the links already written into your posts and their revisions. To take links out, revoke them before you uninstall: once its data is deleted, the plugin can no longer find them. On a multisite network, each site where the box is ticked is cleaned up, and sites where it is not ticked keep their data. With a persistent object cache (Redis, Memcached), the robots.txt rules cached by the link checker are not deleted: they expire on their own within 24 hours.

Yes. Each post has controls to exclude it entirely, to stop it being used as a link source, or to stop it receiving links.

Elementor is supported, including content stored in Elementor's own data structure. Within an Elementor page, text editor widgets are linked; other widgets are left alone. Builders that store their layout as shortcodes in the post content, such as Divi, are linked inside their text, and their shortcodes are left untouched. Text that a builder keeps in a shortcode attribute rather than in the body, such as a module title, is never linked: writing there would break the module and the link would be invisible. The journal records those as an anchor found only in a shortcode. SeedProd is supported on landing pages and on pages edited with SeedProd. Text blocks are linked in both places SeedProd keeps them, so the link shows at once and survives the next save in the SeedProd builder. Other blocks, such as headlines and buttons, are left alone. Tested with SeedProd Lite. Pages built with the SeedProd Pro theme builder use the same storage but were not tested.

No, and the reason is structural rather than a list of integrations: the plugin adds nothing to the front end. No meta tag, no canonical, no sitemap, no filter on the content at display time. The links are written into your content as ordinary HTML, so an SEO plugin counts them exactly like a link you typed yourself. The plugin does read the noindex setting of those four: a page you have marked noindex is never chosen as a link target. Nothing to configure. Two limits are worth knowing. It reads the setting you put on the page itself, not a site-wide rule that makes a whole post type noindex. And it reads the four plugins above; another SEO plugin is not recognised. In both cases the page can still be chosen as a target, and the per-post controls in the sidebar exclude it. Developers can also filter aial_target_is_noindex.

Yes. Nothing is computed at display time, so a cached page can never serve a version without the links: they are already part of the stored content. Writing to the post content goes through the normal WordPress update path, which is the signal WP Rocket, W3 Total Cache, LiteSpeed Cache, WP Super Cache, WP Fastest Cache and SG Optimizer already watch in order to clear a page by themselves. On an Elementor page, and in ACF fields, the plugin writes to post meta instead of the post content, which does not fire the post update hooks. Since 0.2.1 it signals the change itself on those paths: it calls clean_post_cache(), which WP Super Cache and W3 Total Cache listen to, and it clears Cache Enabler and LiteSpeed Cache through their own per-post API. Measured against those four. Two are not covered. WP Fastest Cache exposes no per-post purge that another plugin can reach. WP Rocket could not be tested here, so nothing is claimed about it. If a new link on an Elementor or ACF page does not appear on either of those, purge that page in your caching plugin, or hook the aial_post_content_changed action to call your cache's own purge.

Open the journal. Every candidate that was considered and dropped is recorded with a reason: below the similarity threshold, rejected by the filtering pass, or an anchor that did not appear verbatim in the source. The last one is the most common, and it is working as intended: the plugin will not invent an anchor that is not in your text.

No. The only external service is the OpenAI API, and only for the posts you process.