Install the WordPress plugin, paste two fields, articles arrive

Because it never needs to write to your site from outside it.

Most publishing tools connect the other way round. WordPress documents application passwords, shipped in version 5.6, as credentials “passed along to REST API requests served over https:// using Basic Auth” (developer.wordpress.org/rest-api/using-the-rest-api/authentication/, checked 4 September 2026), and that is the door they knock on. Koala's WordPress integration asks you to “Create an application password in your WordPress admin area” and advertises that no plugin installation is required (koala.sh/features/wordpress-integration, checked 4 September 2026). SEO.AI ships a plugin, SEO.AI Publisher (seo.ai/wordpress), and its own setup guide runs the connection through an application password too (seo.ai/blog/how-to-set-up-the-wordpress-integration, checked 4 September 2026).

That design has real consequences. It hands a third party a credential that can write anything your account can write, it needs your REST API reachable from the public internet, and it breaks when a security plugin blocks application passwords or the endpoint entirely.

The two fields this plugin asks for are ours, not yours: a website ID and a website key that read one article feed and nothing else. The key gives no access to your WordPress installation. Revoke it in your dashboard and the plugin stops receiving articles; it never had a way in.

The trade-off is honest: because delivery is a poll, an article appears within about fifteen minutes rather than instantly. If you want it instant and your site is reachable at a stable URL, take the signed webhook instead.

WordPress asks IT Master for articles, not the other way round, and that is deliberate. A push webhook needs the site to be publicly reachable at a stable URL and to verify a signature. Not every small-business host gives you that, and some filter inbound requests before they reach WordPress at all. An outbound HTTPS GET works from anywhere.

WordPress ships hourly as its shortest cron interval, so the plugin registers its own 15-minute schedule. Each run:

• sends the stored cursor to the article feed, authenticated with your website key as a bearer token
• walks up to four pages of 25 articles per run, enough to drain a backlog in one tick
• advances the cursor only after a page is processed, so a failed page is retried on the next run instead of being skipped
• stops early when a page returns nothing new, or when the feed stops moving forward

There is one caveat worth stating plainly, and it is WordPress's own: “WP-Cron works by checking, on every page load, a list of scheduled tasks to see what needs to be run”, and it “does not run constantly as the system cron does; it is only triggered on page load” (developer.wordpress.org/plugins/cron/, checked 4 September 2026). A site nobody visits therefore checks in less often, and a very quiet site may go hours between syncs. Two fixes: press Check for new articles now on the settings screen when you want one immediately, or have your host run a real system cron against wp-cron.php, which is the standard remedy and helps everything else on the site too. Stacks that would rather be pushed to can use the signed webhook or the REST feed described in the docs.

Every decision is made upstream, so the plugin maps rather than judges. One payload carries:

• the article body as HTML, plus an excerpt
• an SEO title and meta description
• a JSON-LD graph built against the article's real author, citations and FAQ
• a hero image with alt text
• a list of questions and answers
• tags, and the topic cluster the article belongs to

The FAQ arrives as structured data rather than as trailing HTML, so each consumer can render it its own way. The plugin appends it under a Frequently asked questions heading with every question as its own subheading. Dropping it would remove a whole section from every article and leave FAQPage schema describing content that is not on the page.

The hero image is side-loaded into the media library once and keyed to its source URL, so re-syncing an updated article does not download the same file again and the library does not fill with copies of one picture. Alt text comes with it. Tags are set from the payload. The category is either one you pin in settings or the article's own topic cluster. Right-to-left articles are wrapped with the correct direction and language so mixed-script paragraphs render properly.

With Yoast SEO active, the plugin writes the SEO title, meta description and focus keyword into Yoast's own post meta. With Rank Math active, it writes Rank Math's. Either way the values look native in the editor, and you can override any of them by hand.

With no SEO plugin installed, the plugin outputs the meta description, Open Graph and Twitter tags and the JSON-LD graph itself — from the document head, and only on the articles it imported. If Yoast, Rank Math, All in One SEO or SEOPress is present, it emits none of its own. Two description tags, or two Article schema blocks, are worse than one imperfect set.

One detail matters more than it sounds. The schema is built for the canonical path the engine expects, while your permalink structure may serve the same article at /2026/09/slug/. The plugin re-bases the page's own identifiers onto the real permalink and leaves every other node alone, so the organisation, author and image nodes keep the IDs that the rest of the graph points at. Schema describing a URL your site does not serve is markup about a page that is not there.

The plugin only ever touches posts it created. It records its own slug in hidden post meta and finds its posts by that key, so anything you wrote, imported or published before installing is out of scope.

If you move one of its posts to draft, pending, private or the trash, it stays there. Content updates still land, but the status is left exactly where you put it. Silently republishing something an owner deliberately unpublished is the one thing an automation plugin must never do.

Each payload carries a content hash. If it matches what is already stored on the post, the sync skips the article entirely — no rewrite, no new revision, no touched modified date.

When an article is taken down in IT Master, because a fact changed or a product was discontinued, a tombstone comes down the same feed. The plugin moves that post to the trash by default: reversible, and it leaves a normal WordPress 404 behind. You can switch it to permanent deletion. There is no setting to keep a withdrawn article live, because the reasons an article is withdrawn are usually the reasons it should not stay up.

The rest of the screen is short. Articles can arrive published, or be held as drafts for a second review. The default is published: the article already passed the validation checks before it was sent, and two review queues for one article is how content stops shipping. You can pin a category, set the post author, turn image import off, turn SEO field writing off, and under Advanced change the post type or the API address.

Below the form is a status table — when the next check is due, when the last one ran, and what it did: how many new, updated and removed. When something is wrong, the reason is there in plain English rather than in a log file.

Deactivating unschedules the recurring event and syncing stops. Uninstalling deletes three options and the cron hook, and nothing else. Your articles stay. You paid for them per published article — see pricing — and removing a plugin is not consent to delete content. Reconnect later and the feed is walked again from the start: posts already imported are matched by their stored slug and skipped when nothing changed, so nothing is duplicated.

It is the right route for most WordPress sites, and the wrong one in a few specific cases.

• You need articles live within seconds. A poll runs every fifteen minutes at best, and less often on a quiet site. Use the signed push webhook if latency matters.
• Your site is not WordPress. Next.js sites use @itmaster/sdk; anything else can read the REST pull feed. Wix and Squarespace get a copy-paste queue, which means a person still posts each article.
• You cannot install plugins. WordPress.com's lower plans and some managed hosts forbid it. There is no application-password path here as a fallback, because the plugin is the only WordPress client we ship.
• Outbound HTTPS is blocked. The plugin makes an outbound request to our API; a host that blocks WordPress's HTTP layer stops it working, and the settings screen will tell you so in plain English rather than in a log file.
• You want each article held for review indefinitely. You can set articles to arrive as drafts, but nothing chases you to publish them, and a review queue nobody clears is how content programmes quietly stop. That is a workflow decision, not a feature.

One more thing the plugin deliberately will not do: keep a withdrawn article live. There is no setting for it, because the reasons an article is withdrawn are usually the reasons it should not stay up.