What a WP autoblogging plugin does and where it fails

Search for a WP autoblogging plugin and you find a category, not a product. The phrase covers feed importers that turn RSS items into posts, AI tools that write articles from keywords, multi-source “robots” that pull from YouTube and affiliate feeds, and custom workflows that publish through the WordPress REST API. Each kind fails differently, so which one you pick matters less than knowing what it has to do.

Most autoblogs also break for boring reasons. Cron doesn’t fire, a feed sends back HTML instead of XML, or a run times out halfway. Switching plugins just moves those failures somewhere else. If you have already tried reinstalling, the general steps for WordPress plugins that are not working still apply. The causes below are the ones specific to automated publishing.

What a WordPress autoblogging plugin actually does

An autoblogging plugin creates WordPress posts on a schedule, with no one writing each one. The only real difference between tools is where the content comes from:

• Feed-to-post importers such as WP RSS Aggregator, Feedzy and WPeMatico. They read RSS or Atom feeds and turn each item into a post.
• AI article generators. They write posts from keywords or titles and schedule them, usually through a paid API key.
• Multi-source tools. They mix RSS, video, social and affiliate product sources in one campaign, often with an AI rewrite step added on.
• Custom workflows. Tools like n8n, Make or Zapier post to WordPress through the REST API, so no dedicated plugin is involved.

An RSS aggregator and an autoblogging tool are also different things. An aggregator can simply show feed items in a block or shortcode, with a title, an excerpt and a link. Feed-to-post creates real WordPress posts that search engines can index. That second step is where duplication, attribution and indexing start to matter.

The category is small. On WordPress.org, WP RSS Aggregator and Feedzy list about 40,000 active installs each and WPeMatico lists 10,000. Content Pilot lists 800 and Auto Robot lists 40. WP RSS Aggregator’s own page says it is used on 50,000+ websites. That doesn’t contradict the directory: the directory counts current active installs, rounded, while the vendor counts every site that has ever used it.

The plugin literally named WP Autoblog is not the one you want

If you search the exact phrase, you may land on “WP Autoblog” by Sascha Huber. Its WordPress.org listing warns that it has not been tested with the latest three major WordPress releases and may no longer be maintained. The name matches your search, but the plugin is stale. Check the “last updated” and “tested up to” lines before you install any importer.

How a feed-to-post import works, step by step

Every feed importer runs roughly the same pipeline. Knowing the steps tells you where to look when posts stop appearing:

1. Trigger. A scheduled event, normally WP-Cron, starts the run.
2. Fetch. The plugin requests each feed URL over HTTP.
3. Parse. SimplePie, the feed parser bundled with WordPress, reads the XML. Feedzy and WP RSS Aggregator both rely on it.
4. Filter. Keyword, date and category rules drop items you didn’t want.
5. Deduplicate. The plugin checks each item’s GUID or a stored hash against earlier imports.
6. Transform. This step is optional. It can fetch the full article, rewrite it with AI, or apply a post template.
7. Create. WordPress inserts the post as draft, pending or published, and attaches or links the images.

Each step can skip items without raising an error. That’s why “it imported nothing” is such a common complaint and so rarely a bug. One more trap sits at step 6. Many feeds carry only a summary, and pulling the full article is usually a paid feature. Feedzy’s documentation, for example, puts full-content extraction in its Developer and Agency plans.

Why an autoblog stops publishing, most common cause first

Vendor troubleshooting docs and WordPress.org support threads point to the same rough order. Work down it before you change plugins.

1. WP-Cron isn’t firing

WordPress’s Plugin Handbook explains that WP-Cron runs when a page loads, not as a continuous process. With no visitors, nothing runs. Full-page caching can also serve pages without ever reaching WordPress, and a staging site behind a password sends cron requests nowhere. WP Engine’s support docs add two more limits: cron jobs run one after another, so an earlier job that errors can hold up later ones, and sites behind basic authentication are incompatible with WP-Cron requests.

To check, install WP Crontrol and open Tools, then Cron Events. If the plugin’s import event shows a next-run time in the past, cron is the problem. On the command line, wp cron event list shows the same thing.

The fix is a real server cron. Feedzy’s troubleshooting guide suggests one every 5 to 15 minutes for low-traffic or cached sites. First turn off the page-load trigger in wp-config.php:

define( 'DISABLE_WP_CRON', true );

Then add a server cron job through your hosting panel or crontab -e. You need hosting access for this:

*/10 * * * * cd /path/to/site && wp cron event run --due-now > /dev/null 2>&1

These two lines only work as a pair. If you set DISABLE_WP_CRON without the server job, every scheduled task on the site stops, including scheduled posts and update checks. If you add the server job but leave page-load cron on, the same job can trigger twice. Hosts also set this up differently, so use your host’s documented path rather than one copied from a forum. WPeMatico ships its own wpe-cron.php endpoint if you’d rather point cron straight at it.

2. The feed is invalid or blocked

A URL that opens in a browser isn’t necessarily a feed. It may send back an HTML page, a redirect, a paywall or a bot challenge. Feedzy’s docs also note that a feed can pass the W3C validator and still fail in SimplePie. Blocked requests show up as 403 or 429 errors, which some sites send to shared hosting IPs that poll too often.

Test each feed URL on its own, add sources one at a time, and poll less often. One bad source can slow the whole run in some importers, so a single broken feed can look like a site-wide failure.

3. The run times out or runs out of memory

Too many feeds or items per run, full-content fetching and image downloads all add up. The usual messages are cURL error 28 (the HTTP request timed out, often after 10,000 milliseconds) and, in WPeMatico, a campaign stuck on “Running Campaign…”. Split large campaigns into smaller ones, stagger their schedules, and lower the items per run. On shared hosting, this is often the point where a bigger plan becomes the cheaper option.

4. Filters and duplicate detection are doing their job

If a run finds 50 items and imports 10, check the per-run item cap first. Feedzy shows Found, Duplicates and Imported counters and has a Debug log level. WPeMatico logs Found duplicated hash when it skips an item it has seen before. Feedzy’s “Treating this feed of type ‘128’ as an RSS feed” is a notice, not an error.

A related trap: if you delete imported posts without clearing the plugin’s duplicate record, the plugin either re-imports them or keeps skipping them forever, depending on the tool. Fix the identifier first, usually the item’s original GUID or URL, then clean up.

5. Images are missing

Feeds often have no image tag. Source CDNs block hotlinking with a 403, SVGs may be rejected as an upload type, and some themes never show a featured image. Set a fallback image, or use your importer’s option to reference the external image URL. External images break if the source moves them, and copying them locally raises licensing questions.

Alt text needs the same care. The W3C’s images tutorial says informative images need a text alternative that carries their meaning, and decorative images get an empty alt="". Auto-filling the post title as alt text does neither.

6. An update changed the parser

Importers depend on WordPress’s bundled SimplePie and on their own add-ons, so a core, PHP or plugin update can break a working import overnight. Update one layer at a time, keep the plugin and its paid add-ons on matching versions, and test on staging first. If you need a log, turn on WP_DEBUG_LOG and read wp-content/debug.log. Don’t display errors on the live site.

7. The posts exist but the theme doesn’t show them

If the posts appear in Posts, All Posts but not in a slider or homepage widget, check that widget’s query and the post’s category. WPeMatico’s FAQ points out that some themes run their own processing only when a post is saved by hand, so posts inserted by a plugin miss it. The importer’s post template is usually the cleaner fix.

What Google does with automated posts

Google’s spam policies describe scaled content abuse as producing many unoriginal, low-value pages mainly to manipulate rankings, and they apply it however the pages were made, whether by automation, people or both. Automation alone isn’t the problem. A thousand lightly reworded feed items is.

Google’s canonicalization documentation explains that it groups duplicate and near-duplicate pages and picks one URL to show. When your imported copy competes with the original article, the original usually wins. Synonym swaps and AI rewording don’t change this, because the claims, structure and source are the same. Blocking pages in robots.txt doesn’t set a canonical either, and using noindex to force the choice can drop the page from search entirely.

Practitioners who describe good results from automation almost always describe partial automation: drafts, a human edit, a steady pace of about one post a day, and topics grouped so posts don’t compete with each other. Nobody documents fully hands-off publishing going well over time.

Does an RSS feed give you permission to republish?

Treat a feed as a way to receive content, not as a license to reuse it. We found no legal source that settles this, and the answer depends on your country. The consistent view among WordPress practitioners is that titles, short excerpts and a clear link back are the lower-risk pattern. Republishing full articles needs the publisher’s permission. Adding a canonical tag or a credit line doesn’t turn copying into permission.

If a source matters to your site, ask the publisher. Many will agree to syndication when your post adds context their readers don’t get elsewhere.

A setup that holds up on a live site

1. Identify exactly what you are running. Note the plugin, its version and any add-ons. Listing plugins with wp plugin list gives you the versions in one command.
2. Back up, then work on staging. If staging sits behind basic auth, remember that cron won’t fire there without a server job.
3. Test one source and one post. Check the title, body, links, image, alt text, category, author and canonical URL.
4. Confirm cron on its own. Use WP Crontrol or wp cron event list before you blame the importer.
5. Import as drafts first. Auto-publishing makes sense only for sources you control, such as your own product feed or a partner’s feed you have permission to use.
6. Read the logs before changing settings. The Found, Duplicates and Imported counters answer most “why nothing” questions.
7. Scale slowly. Add sources one at a time, and only after duplicates, permissions and image handling behave.

If what you really want is posts written, edited and published when you ask, rather than a feed campaign running in the background, SiteSelf does that work through chat on your existing site. It is described on the page about writing and publishing WordPress content. It works on request, so it doesn’t replace a scheduled import.