MainWP Article Uploader - WordPress Plugin

MainWP Article Uploader Guide: Bulk Uploading Articles to WordPress Sites Through MainWP

MainWP Article Uploader is not meant for writing content or replacing the WordPress editor. It handles a different stage of the workflow: when the content is already prepared and needs to be distributed cleanly across multiple child sites from a single MainWP Dashboard. In this guide, we will walk through how to choose the right upload method, prepare a TXT or CSV file, review articles before publishing, send them to the right Child Sites, and troubleshoot the issue if publishing fails.

This guide is written for owners of WordPress site networks, editors managing content operations, SEO specialists, and agencies that already use MainWP or plan to move content publishing into a centralized control hub. It does not cover buying a subscription, entering keys, or bypassing licensing. The focus here is practical: what data to provide to the extension, what it can do with that data, and how to avoid turning bulk publishing into bulk error cleanup.

What makes this product different is that it works inside the MainWP ecosystem. That means the quality of the outcome depends not only on the CSV or TXT file itself, but also on the condition of the Dashboard site, the connected Child Sites, author roles, categories, tags, encoding, server limits, and site-to-site connectivity. That is why this guide is organized as a workflow rather than a button list: preparation, upload, review, publishing, result validation, and troubleshooting.

If you have previously imported posts with the standard WordPress importer or general-purpose CSV plugins, it is important to draw a clear distinction right away. MainWP Article Uploader is not trying to be a universal migration engine with arbitrary field mapping. Its strength is centralized publishing of a ready-made set of articles to sites that are already connected to MainWP.

Where This Extension Fits in the MainWP Workflow

MainWP has two core parts: the Dashboard plugin installed on a separate management WordPress site, and the Child plugin installed on every site you want to manage. Article Uploader is added specifically to the Dashboard site. It is not installed separately on each child site, and it does not require an extra third-party plugin for its core function. This is an important operational detail: you prepare content and manage publishing in one place instead of repeating the same steps across dozens of admin panels.

In a typical content workflow, there are several manual steps: open the site, create a post, paste the title, review the article body, choose categories, assign tags, set the author, allow or disable discussion, save, then repeat on the next site. When you only have two or three sites, that manual work is still manageable. But when you are dealing with a network of client sites, regional projects, niche blogs, or a series of landing pages, the manual approach quickly starts producing errors: the wrong site, a missed category, a duplicate slug, or a draft published by mistake.

MainWP Article Uploader moves that work into a batch-based model. First you bring the content into a clean, predictable format, then upload it into the extension, review the table of imported articles, and only then publish the selected items to the selected sites. The main advantage here is not just speed, but control before a bulk action: you get an intermediate layer where you can catch a mistake before it spreads across the entire network.

It helps to think of the extension as a bridge between editorial preparation and distributed publishing. It will not fact-check an article, choose images, create an editorial calendar on its own, or guarantee that a post will look the same across every theme. What it does well is one repeatable technical task: take prepared content and deliver it where it is supposed to appear.

When Batch Publishing Actually Saves Time

The extension is especially useful when content is prepared outside WordPress in advance: in a code editor, spreadsheet, content generation system, editorial database, or a custom pipeline. For example, a team might prepare a series of local news posts, service descriptions for different cities, knowledge base articles for client sites, or documents that need to be published as pages.

The real time savings do not show up during the first test. They appear after you establish a repeatable process. If you invent a new file format every time and keep fixing fields by hand, the advantage disappears. The right approach is to define the content structure, author names, slug rules, categories, and review method once. After that, Article Uploader becomes a regular part of your publishing workflow.

When Not to Start With Bulk Uploading

If you only have one site, your content needs complex block editor styling, each article has its own custom images, non-standard fields, different templates, and separate SEO work, then batch uploading may not be the best first step. In that case, it is usually easier to create the post manually on the target site, review how it displays, and only then decide whether a similar workflow is worth automating.

You also should not start by publishing to all sites at once if the network has not been synchronized in a long time or some Child Sites are showing warnings. For bulk operations, MainWP depends on child sites being reachable, the Child plugin responding correctly, and the Dashboard server not running into execution limits.

Two Upload Methods: Quick TXT Files and Structured CSV

MainWP Article Uploader documentation splits the workflow into two approaches. The first is the Upload Method, where you upload individual TXT files. The second is the Import Method, which uses a specially structured CSV file. In practice, these are not interchangeable options, but two different levels of control.

The TXT approach works well when each article only has a basic pair of elements: a title and a body. The documentation highlights an important detail: for text files, the extension detects the first sentence and uses it as the article title. That is convenient for quick batches of simple content, but it requires discipline at the beginning of every file. If the first paragraph starts with a note, a temporary label, or badly pasted text, the title will be just as messy.

The CSV approach is better for content where you need to define more parameters up front: post type, author, categories, tags, slug, excerpt, comment settings, pingback settings, and the target site list. One important detail: the CSV format for Article Uploader is not a normal flat table with standard columns. Instead, it uses tags at the beginning of lines. That format may feel unusual if you expect a classic Excel-style sheet, but it reads well in a text editor and lets you keep the article body as a large block.

How to Choose the Right Method

Do not choose a method based on what is faster to click. Choose it based on how many decisions need to be made before publishing. If the editor only needs to upload a set of simple drafts, and categories and settings can be applied the same way across the whole batch, TXT will be faster. If each article needs its own set of sites, slug, author, and tags, CSV will require less manual cleanup.

Which method to use in common situations

Situation	Recommended method	Why
You need to quickly distribute several simple text articles as posts	TXT upload	Minimal preparation, the extension pulls the title from the first sentence and lets you choose shared publishing settings.
Each article needs different categories, tags, and a custom slug	CSV import	The tag-based format lets you set parameters for each article individually before publishing.
Content needs to go to different groups of Child Sites	CSV import	The SITES field lets you target specific sites or broader coverage, as long as the format is prepared correctly.
You need to open each article first and adjust SEO settings	CSV import with manual review after import	After import, the extension shows the articles and lets you edit them before publishing.

Why You Should Not Build the CSV in a Random Spreadsheet

The official documentation explicitly recommends editing the CSV for Article Uploader in a plain text editor or code editor, because the file uses special tags at the beginning of lines. This is not a standard CSV where each row is a record and each column is a field. If you open that file in a spreadsheet editor and save it back without checking, you can end up with extra quotation marks, changed encoding, altered line breaks, or auto-converted URLs.

It is safer to keep a text-based template. Within your team, it helps to maintain a short reference note: which tags are required, which fields can be left empty, how to separate articles with [NEW], and how to list multiple categories, tags, and sites. In this extension, losing the CSV structure is usually more dangerous than a small typo in the article text, because one formatting error can shift the entire publishing batch.

What to Check Before Installation and Your First Import

Before installing the extension, it is important to verify more than just the presence of MainWP Dashboard. Article Uploader runs a bulk operation, and bulk operations are sensitive to weak points in the underlying infrastructure. If one Child Site has been unreachable for a long time, another is blocked by a firewall, a third uses a different category structure, and the Dashboard has a small file upload limit, the problem will usually surface during publishing.

Basic preparation starts with the MainWP architecture itself. It is best to keep the Dashboard on a separate clean WordPress install rather than on a public-facing site with visitors, a theme, forms, and a bundle of marketing plugins. That is MainWP's own recommendation for reducing conflicts and improving stability. The Child plugin should be installed and activated on every site that will receive articles.

Checking the Dashboard Site

On the management site, review the MainWP server information: PHP version, memory limit, cURL, OpenSSL, timeouts, and the availability of required functions. For a small network, the requirements may be modest, but when publishing to dozens of sites, weak limits tend to show up much faster. If the Dashboard is already struggling with normal synchronization, stabilize it first and only then add batch publishing.

Also check the maximum upload file size. A TXT batch may be small, but a CSV containing several long articles, HTML markup, and large post bodies can easily run into server limits. If the file does not upload at all, the problem may not be Article Uploader itself, but the PHP upload limit or post size settings on the Dashboard server.

Checking Child Sites

In MainWP, open the list of managed sites and run a sync. For the sites that will receive content, you want to see a healthy connection status. If MainWP cannot connect to a child site, Article Uploader will not be able to deliver a post there reliably either. Common causes include a security plugin, WAF, Cloudflare rules, ModSecurity, Imunify360, an SSL certificate issue, DNS cache after migration, or a disabled Child plugin.

Verify that the necessary users, categories, and, if relevant, tags exist on the target sites. WordPress may create a new category during publishing in some interfaces, but for a batch workflow, it is better not to rely on the platform to fix your structure automatically. If the sites need a shared taxonomy, normalize it before you publish.

Practical rule: before your first large import, publish one test article to one test Child Site. Only after you confirm the title, slug, author, categories, HTML markup, and public URL should you expand the scope.

Checking the Editorial Model

Article Uploader does not solve content uniqueness, quality, legal rights, image compliance, or site policy issues. Before importing, you should already have a complete editorial package: titles, article bodies, excerpts, slugs, authors, categories, tags, target site list, and discussion settings.

For an agency, it is useful to keep a simple matrix: one row per article, with columns for target site, publication type, category, author, comment status, source document link, and the name of the prepared file. That matrix does not have to become the import CSV itself, but it helps you catch inconsistencies before upload.

Installing the Extension and Running the First Dashboard Check

MainWP add-ons are installed on the Dashboard site. The MainWP documentation describes several paths: through MainWP > Add-ons > Manage Add-ons, through the standard WordPress plugin installer, or manually by uploading the folder into wp-content/plugins. For regular use, the Manage Add-ons interface is usually the most convenient because it fits more naturally into MainWP extension management.

After installation, do not jump straight into bulk publishing. First make sure the extension appears in the Add-ons menu, the Upload Articles and Import Articles pages open correctly, and the upload interface renders without missing buttons. The Article Uploader changelog has included fixes related to the uploader library and missing buttons, so checking that the interface elements are actually visible is not just a formality, but a sensible first validation step.

Minimum Installation Sequence

1. Open the Dashboard site where MainWP Dashboard is installed.
2. Go to MainWP > Add-ons > Manage Add-ons and find Article Uploader.
3. Install the extension on the Dashboard site and activate it as a WordPress plugin.
4. Open the extension under MainWP > Add-ons > Article Uploader.
5. Confirm that both Upload Articles and Import Articles are available.
6. Open the Child Sites list and make sure your test site syncs without errors.

If the extension is installed but updates do not appear or the add-on activation does not go through, use standard MainWP licensing diagnostics: deactivate and reactivate the extension in Plugins, recheck the API key under Add-ons, confirm that the Dashboard server can reach mainwp.com, and only then start looking for a problem inside Article Uploader itself.

Your First Safe Test

Create a separate Child Site or use a non-indexed staging site. Prepare one short article without external images and without complex HTML. Upload it in TXT mode, choose to publish it as a post, assign one existing category, disable comments if they are not needed, and send it only to the test site. Then open the post on its public URL and confirm that the title, body, category, and discussion status match your expectations.

At this stage, your goal is to validate the route itself: the Dashboard accepted the file, Article Uploader displayed the content in the intermediate list, the publication reached the Child Site, WordPress created the post, and the public site displays it correctly. Until that route works on one site, do not run an import across the entire network.

TXT Upload: A Fast Way to Distribute Simple Articles

The Upload Articles mode is designed for content where each article is stored in its own .txt file. According to the documentation, this mode pulls the title and content from the file and then lets you choose whether to publish it as a post or page, assign a category, enable or disable comments, and select Child Sites. It is the fastest path, but it gives you less per-article control.

The main detail in TXT mode is the title. The extension uses the first sentence in the text file as the Article Title. That means the file should begin immediately with a proper title sentence, without internal notes such as "done," "version 2," "for the client," or "check later." If your editorial team is used to leaving notes at the top of documents, you will need to change that habit for Article Uploader: keep internal comments outside the file or in a separate system.

How to Prepare TXT Files

The best format for a TXT batch is one file per article, a clear filename, and clean text without hidden formatting. If the article needs HTML, it is better to switch to CSV mode, where the documentation explicitly describes support for HTML markup inside the article body. For a simple TXT workflow, keep the structure as predictable as possible:

• The first sentence is the future title, with no extra notes.
• After the title comes the article body in normal paragraphs.
• Use UTF-8 encoding, especially if the text includes Cyrillic, special characters, or quotation marks.
• The filename should be clear to the editor, but not the only place where meaning lives.
• No temporary comments, internal draft links, or personal data.

Before uploading, open each file in a simple editor and review the top of the content. If you see broken characters instead of Cyrillic, damaged line breaks, or a technical label at the start of the text, fix the file before upload. Article Uploader should not be the last place where you first inspect prepared content.

Upload and Post-Upload Handling

In the Dashboard, open MainWP > Add-ons > Article Uploader > Upload Articles, click Upload Articles, and select the prepared TXT files. After upload, the extension displays the available actions: publish, edit, or delete. Do not skip this intermediate list. It exists so you can verify how the extension interpreted the articles.

When publishing uploaded TXT content, choose post or page, set comment behavior, assign categories, and select Child Sites. If the same batch needs to go to different sites with different categories, do not try to force everything through in one action. Split the batch into groups. That makes it easier to review the outcome and roll back a mistake if one site uses a different category structure.

Where TXT Mode Becomes Limiting

TXT mode is not as convenient when you need custom slugs, different authors, different tags, or excerpts. It is well suited to quick publication of similar content, but it should not replace your editorial system. If SEO structure matters, if you need to control URLs in advance, or if the body contains HTML blocks with images or video, use import CSV instead.

Another risk is publishing articles that begin with the same first sentence. If several TXT files start the same way, you will end up with similar or duplicate titles. In a small test, that stands out immediately, but in a bulk upload it can take more time to fix than it would have taken to prepare the files correctly in the first place.

CSV Import: Controlled Publishing With Fields, Site Lists, and Separators

CSV mode is the most important part of MainWP Article Uploader for serious work. The documentation describes it as the more powerful option because it lets you define not only TITLE and BODY, but also POST TYPE, AUTHOR, CATEGORIES, TAGS, SLUG, EXCERPT, ALLOW COMMENTS, ALLOW PINGBACKS, and SITES. After import, you can open each article, review it, and edit it before publishing.

You should accept the non-standard format from the start. This is a file where the tag begins at the start of the line, and everything after it is used as the value. The [NEW] separator starts the next article. Multiple categories, tags, and sites are listed with commas. This format works well for text-based content packages, but it requires careful handling of line breaks and colons at the beginning of lines.

Working CSV Template

For an editorial team, it is useful to keep a minimal template and expand it only when needed. Inside BODY, you can use HTML markup if the article needs it and the markup has already been reviewed. Do not place prohibited scripts, heavy iframes, or code that depends on a specific theme inside the body if you are publishing the same content across different sites.

TITLE: How to Prepare a Site for a Seasonal Promotion
POST TYPE: post
AUTHOR: editor
CATEGORIES: News, Promotions
TAGS: seasonal promotion, checklist
SLUG: seasonal-promo-checklist
EXCERPT: A short summary for the archive page and theme snippet.
BODY: <p>The first paragraph of the article...</p>
<p>Main content with reviewed HTML markup.</p>
ALLOW COMMENTS: 0
ALLOW PINGBACKS: 0
SITES: https://site-one.example, https://site-two.example
[NEW]
TITLE: What to Check After a Catalog Update
POST TYPE: page
AUTHOR: admin
CATEGORIES:
TAGS:
SLUG: catalog-update-check
EXCERPT:
BODY: <p>Page content...</p>
ALLOW COMMENTS: 0
ALLOW PINGBACKS: 0
SITES: all

This example is not meant to be copied without changes. Its purpose is to show the rhythm of the file. Each article should have a clear beginning, its own settings, and an explicit separator before the next entry. If a field is not needed, it is better to leave it intentionally blank than to remove the tag and later guess how the extension interpreted the file.

How to Work With the SITES Field

The SITES field determines where the article will be sent. The documentation shows both the all option and a list of child site URLs. For real production use, it is safer to start with a short, explicit list. The value all is convenient for fully identical content, but it becomes risky if your Dashboard includes test sites, archived client sites, maintenance sites, or projects with different editorial rules.

If the network is large, group publishing by meaning: client, language, topic, region, site type, or readiness state. MainWP supports organizing sites by tags and clients elsewhere in the Dashboard, but CSV Article Uploader still needs to reflect your editorial approach explicitly. Publishing to "all" should be a deliberate decision, not a way to save one line.

POST TYPE, Slug, and Authors

POST TYPE determines whether WordPress creates a post or a page. Use post for blog content, news, guides, and updates. Use page for static pages that should live in the site's structure outside the content feed. If you work with custom post types, Article Uploader is not the main tool for that job. The MainWP ecosystem has a separate extension for custom post types, with its own workflow requirements.

SLUG is best defined in advance. That reduces the risk of accidental URLs based on long titles and gives you more control over internal linking. For sites using Cyrillic content, you can keep the slug in Latin characters while leaving the title and content in Russian. If the slug is already taken on a child site, WordPress may alter the final URL by adding a suffix. That is why after publishing you need to verify the actual URL, not just a "published" status.

AUTHOR must match an existing user on the child site. If that username does not exist, the behavior may vary depending on the site and the WordPress environment. Do not plan a bulk import under a user account that exists only on the Dashboard. For a client site network, confirm in advance that the required authors exist everywhere they need to appear publicly.

Comments, Pingbacks, and Excerpts

ALLOW COMMENTS and ALLOW PINGBACKS are easy to standardize as numeric values based on your editorial policy. For knowledge base pages, commercial landing pages, and most imported guides, disabling discussion and pingbacks is usually the sensible choice. For blog content with an active community, the decision may be different, but it should be made before import.

EXCERPT is useful when the theme displays excerpts in archives, cards, search, or on the homepage. If you leave the field blank, WordPress or the theme may generate an excerpt automatically from the beginning of the text. That is not always a problem, but in bulk publishing it is better to control the opening lines, especially when articles begin with a technical or internal introduction.

CSV check before import: open the file in a code editor, make sure each tag starts on a new line, each article is separated by [NEW], and the long body content has not swallowed the next tag.

Post-Installation Setup: Practical Rules for Safe Publishing

Article Uploader does not have a complex global settings panel like an all-in-one SEO plugin or a form builder. Its real setup happens in the process around the extension: where files are prepared, which values are considered valid, who reviews the import, which sites can be published to immediately, and which require manual approval.

That approach may feel less like "configuration," but it is exactly what lowers risk. The plugin performs a bulk action. That means the best MainWP Article Uploader settings are not a set of toggles, but editorial and technical guardrails that keep one mistake from spreading across the entire network.

The Test Batch Rule

The first rule is to always keep a test route. Even if you have already published through MainWP many times, a new CSV format, a new group of sites, a new author, or new HTML markup should always go through one site first. A test batch answers questions you cannot see in the file itself:

• Does the content appear under the correct content type?
• Does the slug stay intact without an unexpected suffix?
• Are the categories and tags assigned correctly?
• Does the HTML inside the article body render correctly?
• Does the author match how the theme displays attribution publicly?
• Were comments disabled where they are supposed to be closed?

If the test site is different from your live sites, use two tests: one on a technically simple site and one on a site with a theme or plugin stack similar to the production group. This is especially important for HTML body content, because the same markup can render differently across themes.

The Predictable Values Rule

Your CSV should not contain "almost correct" values. If one article uses the category News, another uses Announcement, and a third uses news, bulk publishing will create inconsistency. The same applies to authors, tags, and sites. Before import, define a list of allowed values and validate the file against it manually or through your own editorial workflow.

Use one consistent style for slugs: Latin characters, lowercase, short words, hyphens between words, and no dates unless the date is part of the page's meaning. If the slug is generated automatically from the title, you lose some control. If the slug is defined explicitly, you can link the future article to internal links and the sitemap ahead of time.

The Intermediate Editing Rule

The official documentation emphasizes that imported articles can be edited before publishing. Do not treat that as an emergency escape hatch only for mistakes. In a solid workflow, it is a separate stage. It is a convenient place to review fields that are not always easy to control in the file itself: SEO settings, additional post options, theme visibility, the excerpt, link accuracy, and formatting of complex blocks.

If the child sites use Yoast SEO or similar plugins, the Article Uploader documentation explicitly mentions the ability to set other post settings, such as Yoast SEO, through editing before publishing. Phrase that carefully: the extension does not promise to auto-fill every field of every SEO plugin from CSV, but it does give you an intermediate stage where you can open the content and verify extra settings before sending it out.

The Separate Batches Rule

Do not mix everything into one file: posts and pages, different client groups, different languages, content with HTML and plain text, publications for all sites and publications for a single site. The format may technically allow a large file, but operationally it makes review harder. A good batch answers a simple question: "What exactly are we publishing, and where should it appear?"

For ongoing work, you can use batch types like these:

• One client, multiple sites, one thematic series of posts.
• One site, multiple pages, one update to a knowledge base section.
• Several regional sites, one article with adjusted slugs and categories.
• A test batch: one item on one site before a full rollout.

This makes it easier to read the action log, review the outcome, and explain to the team what was actually published. If you need to cancel part of the work after import, separate batches also give you more control.

Practical Use Case: Publishing a Series of Articles to a Group of Child Sites

Let us walk through a concrete example. An agency manages several client WordPress sites in the same niche. It needs to publish a series of three knowledge-base pieces: one general blog post, one static checklist page, and one short article for a local site. The sites are already connected to MainWP, categories and authors are prepared, and the team wants to avoid logging into each admin panel manually.

Goal

Publish three correct pieces of content to the appropriate Child Sites, with controlled titles, slugs, post types, authors, categories, excerpts, closed comments, and verifiable public URLs. One key condition is to avoid sending all articles across the entire network when each one is meant for its own subset of sites.

Preparation

Before import, the team prepares a CSV template. Each article begins with TITLE: and includes POST TYPE:, AUTHOR:, CATEGORIES:, TAGS:, SLUG:, EXCERPT:, BODY:, ALLOW COMMENTS:, ALLOW PINGBACKS:, and SITES:. The articles are separated with [NEW]. All sites are listed with full URLs exactly as they are connected in MainWP.

Author matching is checked separately. If the CSV uses editor, that user must exist on the target sites. If the author name differs somewhere, it is better to fix that before import than to troubleshoot later why the post ended up under the wrong owner.

Steps in MainWP Dashboard

1. Open MainWP > Add-ons > Article Uploader > Import Articles.
2. Click Import Articles and select the prepared CSV.
3. After import, review the article table: title, post type, author, categories, tags, slug, and destination sites.
4. For any article with complex markup or SEO settings, click Edit and review the content before publishing.
5. Publish one test article to one site using the Publish action.
6. Open the public URL on the Child Site and verify the actual outcome.
7. If the result is correct, return to the imported article list and publish the remaining content one by one or through a bulk action if the batch has been fully validated.

Validating the Outcome

Validation does not end with a Dashboard message. Open the child site and make sure the content appears where a user would expect to find it. For a post, check the feed, category archive, single post page, tags, author, and comments. For a page, check the public URL, confirm the page exists in the admin area, and if needed, add it to the menu manually. Article Uploader creates content, but it does not automatically build out site navigation.

For a larger batch, it is useful to keep a simple validation log: article, site, expected URL, actual URL, status, and reviewer. This is especially helpful when publishing to client sites and you later need a fast way to confirm what was completed.

One Important Detail: Different Themes Display the Same Article Differently

MainWP's documentation for post management notes that previewing from the Dashboard may be limited because child sites use different themes and settings. Even if Article Uploader sends identical HTML correctly, the front end can still vary: content width, list styling, table styles, excerpt display, and the behavior of embedded images.

That is why for content with HTML markup, you should validate at least one site from each theme group. If one group uses the block editor with strict styling and another uses a classic template, the final presentation may differ. The publication itself may still be successful, but visual review is still required.

How to Prepare HTML, Links, and Media Inside the Imported BODY

The Article Uploader documentation allows HTML markup inside CSV to format the article body, including images, video, and other tags. That opens up a powerful use case: you can prepare content as HTML in advance and distribute it across the network. But it also creates risk, because one broken fragment inside BODY can affect display on every destination site.

Start with the most portable markup possible. Paragraphs, lists, subheadings, simple links, images with absolute URLs when they are genuinely available, and basic tables tend to work well. What does not transfer well are heavy page-builder blocks, shortcodes that do not exist on the child site, forms with unique IDs, interactive embeds, and scripts. If the content needs to work on multiple sites, the HTML has to make sense to all of them.

Links and Internal URLs

Links inside imported content should be prepared deliberately. An absolute link to one domain may be correct for one site and wrong for another. If the article is published across several regional sites, internal links often need to be adapted for each domain. In that case, create separate CSV entries for different sites even if the body text is almost identical.

There are fewer issues with shared external sources, but you should still review link attributes and anchor text. Article Uploader transfers your HTML, it does not evaluate the SEO quality of your link structure. If the original BODY contains a temporary link to a Google Doc, staging site, or internal editorial document, that link will go live in the published post.

Images and Video in BODY

If your HTML uses images, they must be publicly accessible or already exist in the media library of each child site under the correct URL. Universal importers such as WP All Import can work with images and media fields separately, but Article Uploader is documented as a tool for uploading articles, not as a full media migration system. Do not expect it to solve the more complex problem of moving images from arbitrary sources onto every site.

For video, it is safer to use a standard link or a normal embed that is allowed by the site's content policy. If you are publishing across different themes and editorial environments, test one short piece first using that embed. In some cases, the theme, security plugin, or content policy may alter how the embed behaves.

Shortcodes and Editor Blocks

A shortcode only works where the corresponding plugin is installed and active. If the article contains [gallery], a form, a pricing table, a builder button, or a block from a specific plugin, make sure every target site supports that element. Otherwise, users will see a raw shortcode or an empty space.

WordPress editor blocks can technically be stored as HTML comments plus markup. But when you are publishing at scale through an external process, it is better to avoid complex blocks unless you have tested them in a matching environment. For knowledge-base content, simple HTML that the theme can render without extra dependencies is the more reliable choice.

Safe process improvement: before import, run the BODY through an editorial check for temporary links, unsupported shortcodes, empty image alt text, and HTML fragments that are tied to one specific site.

How to Scale Publishing Without Duplicates or Editorial Chaos

After the first successful test, the usual temptation is to build one large CSV and send everything at once. Technically, that is what bulk publishing is for. But in a real editorial workflow, predictability matters more than maximum batch size. MainWP Article Uploader should become part of a clear process where every batch has a purpose, an owner, a site list, an expected outcome, and a review method. Otherwise, the extension will not speed up publishing. It will speed up the spread of careless decisions.

Scaling begins with naming rules. If content is stored as TXT, the filename should help a person find the source quickly: client, topic, short slug, language, or site group. If content goes through CSV, the filename should describe the batch, for example "client-a-blog-batch," "regional-pages-test," or "service-guides-group-1." The file itself does not have to end up in WordPress, but its name will remain in your editorial log and help you understand a month later where a specific post came from.

Separate Batches by Risk Level

Not all content carries the same level of risk. A simple news item without HTML, images, or internal links is usually safer than a long page with tables, call-to-action blocks, local service links, and shortcodes. That is why your batches should group content not only by client or topic, but also by complexity. Simple posts can be reviewed faster, while complex pages require a separate test and closer review on the public site.

A practical sequence looks like this: first a "test batch" with one item, then a "low risk" batch of similar simple posts, then a "medium risk" batch with HTML and links, then a "high risk" batch for pages that need manual navigation work, menu changes, or theme-specific validation after publishing. This order does not slow down the workflow if it is defined in advance. It simply prevents one broken BODY template from hitting every site at once.

Keep a Publishing Log Separate From the CSV

The CSV handles import, but it is not a complete operational log. Your log should contain the details that help you manage consequences: batch name, who prepared the content, when the test was completed, which Child Sites were selected, which posts were published, which ones are still under review, where errors were found, and who confirmed the public outcome. It can be a simple table in your editorial system, but it should exist.

The log is especially useful for preventing duplicates. If publication fails on some sites, you cannot simply rerun the entire batch. First record where the post already exists, then repeat the action only for the sites where no result is present. Otherwise, the same content may receive a second slug with a suffix or show up as a duplicate in the feed. In bulk publishing, a record of the outcome matters just as much as the CSV itself.

Validate More Than Just the Fact of Publication

Article Uploader can help create posts, but editorial quality still belongs to the team. After publishing, do not just check whether "the page opened." Confirm that the content did not land on a site where it makes no topical sense, that the category fits the site's navigation, that the excerpt was not cut off awkwardly, that the author label is meaningful to readers, and that internal links point to the correct section of that specific domain rather than a neighboring project.

This matters even more across networks of similar sites. The sites may look identical, but one may use a different menu structure, another local categories, a third different comment rules, and a fourth a narrow content layout. If the CSV was prepared as "one article for all," those differences will only become visible after publication. That is why your review log should not just say "done," but something closer to "URL opens, category is correct, slug is correct, HTML renders correctly, no stray shortcodes."

How to Stay in Control With a Large Number of Sites

If your Dashboard includes dozens or hundreds of Child Sites, do not treat the entire network as one abstract mass. Split the sites into working groups: client projects, owned blogs, regional sites, test environments, archived sites, sites with a non-standard theme, and sites that are especially sensitive to publishing changes. Even if Article Uploader accepts a plain URL list, the editorial decisions should be made earlier, at the batch planning stage.

Choose a review level for each group. On test sites, you can validate HTML more aggressively. Client sites need prior alignment. Sites with unique themes are better handled first as drafts or through one control URL. Older sites should be checked for connection health and system limits before publishing. That is where MainWP provides real value: the central Dashboard remains the control center, but your decisions do not become generic.

When You Should Stop a Batch

A batch should be stopped not only when there is an obvious technical error. Pause the import or publishing if you see a recurring wrong title, an unexpected slug, an empty BODY, the wrong author, broken Cyrillic characters, unsupported shortcodes, the wrong site list, or a mismatch between the plan and the imported article table. At that stage, fixing the issue is still inexpensive.

If the mistake is discovered after publication on several sites, stop the remaining rollout, mark the affected sites in the log, decide whether a rollback is needed, and only then prepare a corrected file. Do not mix the corrected batch with the original one. It is better to create a new CSV with a clear name and only the articles that actually need to be resent. That lowers the risk that the team will lose track of which version of the content has already been published.

A good bulk workflow looks boring: files have clear names, batches are small in scope, there is always a test, the outcome is documented, and reruns are limited to sites where publication failed. That kind of boring predictability is exactly what makes Article Uploader useful on a real site network.

Publishing, Editing, and How It Connects to Other MainWP Tools

After upload or import, Article Uploader should not feel like a black box. It displays the content and gives you three actions: publish, edit, or delete. That intermediate table is one of the most useful parts of the extension because it separates file intake from live publishing to Child Sites.

In editorial practice, it is helpful to separate roles. One person prepares the file, another reviews the imported table, and a third confirms publication to client sites. In a small team, this may still be the same person, but the stages should remain separate: first the file, then the import, then the review, then the publishing step, then the external validation of the result.

When to Edit Before Publishing

Editing before publishing is essential if the file contains HTML, SEO fields need manual review, authors differ across sites, categories have similar names, or the article is being published as a page. Editing is also needed if the imported table shows an unexpected title, an empty excerpt, the wrong post type, or an overly broad site list.

If the content is simple and the format has been validated many times before, you can publish through a bulk action. But even then, review several rows from the batch first. Bulk publishing only works well when the input data is predictable.

Using It Together With Post Dripper

The official product page mentions integration between Article Uploader and MainWP Post Dripper for time-based publishing. That does not mean Article Uploader turns into an editorial calendar by itself. The relationship is straightforward: Article Uploader helps you upload and prepare content, while Post Dripper may be useful when posts or pages need to be released gradually across the network instead of going live all at once.

A practical combined workflow looks like this: you import a batch of articles, review the fields, and then use gradual publishing if the sites need a steady update rhythm. This is especially useful for blog networks where publishing everything at one moment looks unnatural and is harder to control. Before using them together, verify that Post Dripper works correctly with your version of MainWP and that its scheduling does not conflict with standard WordPress cron behavior.

When You Need a Different Tool Instead of Article Uploader

If you need to manage posts that are already published, search across the network, change statuses, or remove content, use the standard MainWP content management section. If you need to create and edit custom post types, look at MainWP Custom Post Types. If you need detailed CSV/XML migration with arbitrary field mapping, images from URLs, ACF, WooCommerce, or recurring imports, WP All Import on the individual site may be a better fit.

That is not a weakness of Article Uploader. It has a different job: quickly accept prepared articles and send them to selected Child Sites through MainWP. The more clearly you respect that boundary, the less frustration you will have in real use.

Validating the Outcome: What Counts as Successful Publishing

Successful publishing is not just the absence of an error message in the interface. For a content tool, the outcome has to be checked across several layers: the post was created in WordPress, attached to the correct site, assigned the expected content type, visible or hidden publicly according to plan, filled with the right HTML, given the correct URL, showing the intended author, categories, and tags, and displayed to users without broken layout.

It is best to define in advance what status counts as success. For example, for a blog article it may mean a published post with a public URL, the "News" category, comments disabled, a defined excerpt, and correctly rendered links. For a static page, it may mean an existing page with the correct slug but without automatic placement in the menu if navigation is managed manually. For content that still needs final editing on the Child Site, success may mean a created draft rather than a live post.

Mini Checklist After Publishing

• MainWP shows no obvious publishing errors for the selected Child Sites.
• On every target site, the content appears under the correct content type.
• The actual URL matches the expected slug or differs in a clear, understandable way because the original address was already taken.
• Categories, tags, and author display the way you intended.
• Comments and pingbacks are in the correct state.
• HTML markup does not output stray technical characters or break the page.
• Internal links point to the correct domain, and external links do not lead to drafts.
• The site still syncs normally with the Dashboard after publication.

Validation Through MainWP Post Search

After publishing, you can use MainWP's standard post management tools to find content by status, keyword, date range, or selected sites. This is a useful second layer of control, especially when a batch was sent to multiple sites. Search shows where the material appeared, and public preview confirms that users see it correctly.

But do not replace public validation with Dashboard search alone. MainWP may confirm that the post was created, but it will not always reveal how the child site's theme behaves. If the theme cut the excerpt awkwardly, hid the author, changed the table styling, or displayed a raw shortcode, you will only see that on the public page.

How to Roll Back a Failed Publication

If you discover an issue after publishing, respond based on scale. One article on one site: open it through MainWP or directly in the Child Site admin area, fix it, and save it. One incorrect article across many sites: find it through Manage Posts and change its status if you need to hide it temporarily. A problem across the entire batch: stop further publishing, delete imported but not yet published entries in Article Uploader, fix the file, and rerun the test.

Do not try to patch a bad CSV on top of an already published batch without a plan. First determine exactly what is wrong: the slug, BODY, category, author, target sites, or discussion settings. Then choose the simplest rollback path: edit the post, move it to draft, delete it, or reimport only the corrected content. The earlier you catch the issue in the intermediate Article Uploader table, the less rollback work you need.

Common MainWP Article Uploader Issues and Troubleshooting

Article Uploader problems usually fall into three groups: the file is not accepted or parsed correctly, the imported articles come in with unexpected fields, or publishing never reaches the Child Sites. Troubleshooting is best started at the earliest layer rather than blaming the destination site right away.

The File Uploaded, but the Titles Look Wrong

Symptom: in the imported article list, the title is empty, contains an internal line, or begins with part of the body text. In TXT mode, this is often caused by the first sentence of the file. In CSV mode, the reason is usually the TITLE: tag, extra characters before it, or broken line structure.

What to check: open the source file in a code editor. Make sure the first line of the TXT file starts with the real title, and in CSV mode confirm that the TITLE: tag is at the start of the line. Check UTF-8 encoding and make sure there are no hidden control characters at the beginning of the file.

How to fix it: if it is just one article, fix the title during intermediate editing. If the issue repeats across the batch, delete the imported items, correct the template, and upload the file again. Do not bulk publish articles with titles that look "almost fine."

The CSV Does Not Split Into Separate Articles

Symptom: several articles are merged into one, some fields end up inside BODY, and the next article never appears in the table. For Article Uploader, the [NEW] separator is critical and must appear after one article ends and before the next one starts.

What to check: find every instance of [NEW] and make sure it appears as a separate marker between articles. Confirm that a long article body does not contain a stray line that looks like a field tag unless it is meant to be part of the content structure. Also check whether a spreadsheet editor changed your line breaks.

How to fix it: keep the working file in a text editor and use a spreadsheet only as a planning tool. After generating the CSV, open it as plain text and visually inspect at least the first two entries. If the errors come from your content preparation system, fix the export process instead of repairing each batch manually.

Cyrillic or Special Characters Display Incorrectly

Symptom: unreadable characters appear in titles or body text, quotation marks break, letters with diacritics disappear, or part of the text looks like the result of bad encoding. The Article Uploader changelog has historically included fixes related to non-standard encoding and UTF-8, so this is not a hypothetical issue.

What to check: make sure the file was saved as UTF-8, confirm it did not pass through an editor that changes encoding, and check whether any text was copied from an old document with unusual characters. For HTML-based content packages, also review special characters inside attributes.

How to fix it: resave the file as UTF-8 without unnecessary transformations, repeat the import with one article, and review the outcome. If the issue only appears on one Child Site, compare its settings, theme, and plugins with a site where the publication displays correctly.

Upload or Import Buttons Are Missing

Symptom: the extension page opens, but the required upload button is missing, the interface looks broken, or actions are unavailable. The Article Uploader changelog includes fixes related to missing upload buttons and compatibility between the uploader library and MainWP versions, so updates and compatibility are the first things to investigate.

What to check: make sure both MainWP Dashboard and the extension are up to date, check for JavaScript errors in the browser, and see whether an admin optimization or security plugin on the Dashboard site is causing a conflict. Also confirm that the extension is installed on the Dashboard itself, not on a Child Site.

How to fix it: update the Dashboard and the extension through the normal mechanism, clear the admin cache, temporarily disable plugins that interfere with the Dashboard admin area, and test again. If the problem appeared after an update, record the versions in your notes for MainWP support.

The Article Imported, but It Will Not Publish to a Child Site

Symptom: the import completed, the row appears in the table, but publishing to one or more sites never finishes. Most of the time, the cause is not the CSV but the connection between the Dashboard and the Child Site: firewall, security plugin, SSL, DNS, a disabled Child plugin, or a server timeout.

What to check: run Test Connection for the problem site, sync it in MainWP, and check the Child plugin status and server information. If you see 403, timeout, "Child plugin cannot be detected," or a similar message, use MainWP connection troubleshooting: WAF, ModSecurity, Imunify360, Cloudflare, SSL certificate, DNS, and security settings.

How to fix it: restore a healthy connection between the site and the Dashboard first. Only then should you retry publishing. If some sites already received the post and others did not, do not rerun the entire network without checking first, or you may create duplicates where publishing already succeeded.

The Author, Category, or Slug Did Not Match the Plan

Symptom: the post was created, but it ended up with a different author, a different category, a new slug with a suffix, or was published to the wrong place. This is usually a data issue, not an interface failure.

What to check: verify that the author exists on the Child Site, that the category names match, that the slug is not already taken, and that you are not mixing different language versions of the same category. Review the CSV specifically in the line set related to the problem site.

How to fix it: for one post, correct the fields manually. For a repeating issue, stop publication, standardize authors and categories across the sites, change the slug, or split the batch into groups. If the slug is already taken, decide whether the existing page should be updated manually or whether a new unique URL is needed.

The HTML in BODY Published, but the Page Looks Broken

Symptom: the text was published, but lists, tables, images, buttons, or spacing are broken on the site. Article Uploader delivered the content, but the front-end theme rendered it according to its own rules.

What to check: validate the HTML, confirm closing tags are present, review supported shortcodes, check image availability, and inspect the theme's styles for tables and content blocks. If the issue appears only on one theme, compare it with a test site and temporarily simplify the markup.

How to fix it: correct the BODY in the source, retest with one article, and then publish the updated batch. For complex content blocks, it is usually better to rely on the native capabilities of the specific site rather than bulk inserting markup that depends on a theme or page builder.

Who MainWP Article Uploader Is Best For, and Where It May Not Fit

MainWP Article Uploader makes sense when you already have a site network in MainWP and a repeatable flow of prepared content. It is especially well suited to agencies, editorial teams managing multiple projects, owners of niche site networks, regional site groups, and teams that prepare content in batches outside WordPress.

It is a strong choice if you want to reduce manual logins across admin panels while still keeping control before publication. The extension does not force you to publish the file immediately: after upload or import, you can review the content, edit it, remove incorrect rows, and only then send it to the sites. For bulk work, that is more valuable than a simple "upload everything" button.

Good Fit For

• Agencies managing multiple WordPress sites and publishing recurring content batches.
• Editors who receive finished articles in TXT or pre-structured CSV format.
• SEO teams that need to control slugs, categories, tags, and destination sites before publishing.
• MainWP Dashboard owners who need a centralized way to add posts or pages to Child Sites.
• Teams that need an intermediate review stage for imported content before a bulk action.

May Not Be the Right Fit

• Sites without MainWP infrastructure, where the standard WordPress editor or a local importer is simpler.
• Projects where every article is built manually in the block editor with unique blocks and media.
• Imports with arbitrary fields, complex images, ACF, WooCommerce data, or recurring syncs from external files.
• Networks where Child Sites are often unreachable because of firewall rules, SSL issues, or unstable hosting.
• Workflows that require custom post type management without separate preparation for matching CPT.

If you are unsure, start with a small test: one TXT file, one CSV file, one Child Site. That will quickly show whether the tool fits your workflow. If everything matches expectations, you can move on to a larger batch and then download MainWP Article Uploader for full testing on your own MainWP network.

FAQ About Setting Up and Using Article Uploader

Can I use the extension without MainWP Dashboard?

No. The extension only makes practical sense within the MainWP Dashboard and Child Sites model. It is installed on the management Dashboard site and uses the existing MainWP infrastructure to publish to connected WordPress sites. If you only have one site without MainWP, standard WordPress import tools are usually the simpler option.

What is better for a first attempt: TXT or CSV?

For your first technical test, TXT is easier: one file, one test site, minimal fields. For a real workflow, CSV is usually better because it lets you define the slug, author, categories, tags, excerpt, comments, pingbacks, and destination sites in advance. Do not move on to a large CSV until you have validated one entry first.

Why does Article Uploader CSV not look like a normal table?

Because the format uses tags at the beginning of lines rather than classic columns. The documentation lists tags such as TITLE, POST TYPE, AUTHOR, CATEGORIES, TAGS, SLUG, BODY, and SITES. That is why the file is better edited as plain text instead of relying on a spreadsheet editor.

Can I put HTML into the article body?

Yes. The Article Uploader documentation states that HTML markup can be used in CSV for the article body, including content formatting. But that does not mean every complex markup pattern will behave the same way on every site. Test shortcodes, images, tables, embeds, and theme styling on a test site before bulk publishing.

What should I do if publishing only worked on some of the sites?

First, do not rerun the entire batch. Check which sites already received the post and which did not. For the problem sites, run Test Connection, sync them, and review the Child plugin, SSL, and firewall setup. Once connectivity is restored, repeat the publishing action only where the content is genuinely missing, so you do not create duplicates.

Is the extension suitable for custom post types?

Article Uploader is primarily aimed at articles and pages. For custom post types, the MainWP ecosystem provides a separate Custom Post Types extension with its own requirements for matching CPT on the Dashboard and Child Sites. If you need to publish products, projects, testimonials, or another non-standard content type, study that tool first.

Can I publish to all sites at once with SITES: all?

Yes, if that is truly your intended workflow and the entire network is ready for it. But for your first batch, it is better to specify exact URLs or a small site group. The value all is convenient when every Child Site should receive the same content, but it is risky in a Dashboard that includes test, archived, or client sites with different publishing rules.

Does Article Uploader affect SEO by itself?

It helps you control the technical publishing fields, but it does not guarantee an SEO outcome. SEO depends on content quality, heading structure, slug quality, internal linking, indexation, site speed, theme behavior, metadata, and competition. Use the extension as a way to deliver already prepared content cleanly, not as an automatic ranking tool.

When MainWP Article Uploader Is the Right Choice

MainWP Article Uploader is best understood as a tool for a mature content workflow. It shines when articles are already prepared, sites are connected to MainWP, the team understands the publishing structure, and the goal is to remove repetitive manual work. If those conditions are in place, the extension helps turn a batch of files into a controlled publishing process with an intermediate review step.

The product's strongest advantage is the combination of TXT speed and CSV control. TXT helps you upload simple content quickly. CSV gives you article-level settings, a site list, slug, author, categories, tags, excerpt, and discussion settings. The ability to edit content before publishing reduces the risk of a bulk mistake, and its connection to other MainWP tools makes it easier to fit article uploads into a broader site network workflow.

Before a production rollout, validate the Dashboard server, Child Sites, file encoding, tag format, authors, categories, slugs, and the public outcome on a test site. After that, the extension can serve as a practical center for bulk publishing. But if your real task is complex data migration, image import from multiple sources, custom fields, or WooCommerce structures, compare it with more specialized tools instead of expecting Article Uploader to do a job it was never built for.

The best path is simple: start with one test file, then one small CSV, then one batch for a limited site group, and only after that move into a regular workflow. That sequence gives you speed without sacrificing control and helps you use MainWP Article Uploader as a real working tool rather than as a risky one-click bulk publishing button.