A daily SEO article, published straight into the WordPress site you already run

No. Connecting needs nothing installed on your site and nothing added to your theme or your functions file.

Publishing goes through the WordPress REST API, which your installation already serves, authenticated with an application password you issue and can revoke. Your site is unchanged apart from the posts you approve.

There is an optional plugin, and it does one job: it puts the three values we need on one screen with a copy button beside each, and a Revoke access button next to them. It makes no calls to us or to anybody else. It is prepared for submission to the plugin directory, and the connection works exactly the same without it.

One that can publish posts. In a standard installation that means the Author, Editor or Administrator role.

The connection is tested against your site before anything is stored, and an account that cannot publish is refused with the reason rather than accepted and left to fail later.

The posts are created as that account, so pick the one you would want to appear as the owner of the post in your dashboard. The byline your readers see is set separately in your brand brief.

No. Delivering the same approved article a second time finds the post already on your site by its slug and leaves it exactly as it is.

If a piece we published changes, because you edited it or asked for changes, that same post is updated in place and keeps its address, its comments and its date. A post at that address carrying no marker of ours is somebody else’s page, and we refuse to write to it and tell you rather than putting a second copy beside it.

Every publish attempt is also recorded against the article, the version and the channel before the request is made, so a retry is a retry rather than a second post.

Yes, and it happens inside your weekly plan rather than as a separate service. When a piece we published slips at least five places from a position on page one and stays down for a week of daily readings, or turns six months old without ever having been refreshed, the next week’s plan proposes a refresh of that exact piece with the evidence written on the card: the position it fell from, the position it is at now, and the search it is about.

You approve a refresh the way you approve anything else, and you can drop it. When it publishes, it updates the post already on your site rather than adding a second one, so the address, the comments and the date survive. A refreshed piece is not re-announced on your social accounts, because it has been live for months.

By default at most a fifth of each plan goes on upkeep, you can set that share anywhere between none and half, and a piece can only be refreshed again after sixty days however badly it is doing. Posts you wrote or imported yourself are outside all of this: we only ever refresh a piece we wrote.

You can, and it is worth being exact about where they land. An import reads a WordPress export file or your sitemap, up to five hundred posts at a time, shows you what it found and how completely it read each one, and publishes the ones you pick to the blog we host for you. It does not write to your WordPress installation, so the archive already on your site simply stays there, untouched, which is usually what a WordPress owner wants.

Each imported piece keeps its original date, so a five-year archive arrives in the order you actually published it, and you get a redirect list to download and put on your old host. This is content portability rather than a search migration: until a domain of yours points at the blog we host, your old addresses go on serving what they serve today and search engines go on ranking those.

An imported piece is labelled as your own writing everywhere it appears, because we did not research, check or edit a line of it. No source count and no verification line is shown for one, and it cannot be picked up by the refresh proposals above. What it does do is count as a subject you have already covered, so we do not write you a second article on something you have already written.

Yes. You can type a post and send it to any of your connected networks, and because those are your own words on your own account, writing it is approving it. Nothing waits in a queue for you to approve a sentence you typed thirty seconds earlier.

You can also hand us a link or a block of pasted text and have a post written for each network from it. Those are written by a model, so they land in your queue at pending review like everything else we write. Each one is checked against the source you gave: a figure, a quotation or a link that is not in your source refuses that network’s post and tells you which check failed, rather than publishing a claim your source never made.

A picture can be generated for a post while you are writing it, on a monthly allowance separate from the image every article already gets. If you attach a link, it is added when the post goes out rather than written into the copy, and it is not added on X: an X post promotes the piece in its own words and cannot carry a reader to it. On Instagram the link goes in the first comment under the post, as an address to copy, because Instagram makes no address clickable.

Posts already on your site stay on your site. Nothing of ours reaches back into them.

New articles go to a blog we host instead, from the next piece onwards rather than retroactively, and you can connect WordPress again at any time from the dashboard.

We keep the connection details so reconnecting is one press. Revoking the application password in your WordPress profile is what ends our access, and it takes nothing else with it.

On your own site that needs an IndexNow key of yours, which most SEO plugins will generate and serve for you. Paste it in with the connection and approved posts are submitted to Bing, Yandex and the other engines that support the protocol as soon as they go live. A submission tells those engines the page exists; when, or whether, they index it is their decision.

Without a key of yours we submit nothing from your domain rather than submitting under ours, because the protocol checks that the key is served by the host the URL is on.