WP All Import Pro - WordPress Plugin

WP All Import Pro Guide: importing data, updating records, and checking the results

WP All Import Pro is best viewed not as an "upload CSV" button, but as a working tool for moving data into WordPress and keeping it updated on a recurring basis. This guide focuses on the practical side: how to prepare the file, how to work through the import wizard, where people go wrong with the unique identifier, how to avoid overwriting fields you want to keep, how to import images, and how to verify the result without putting the site at risk.

This guide is written for site owners, store admins, content managers, and developers who receive an XML, CSV, Excel, or Google Sheets file and need to turn it into posts, pages, WooCommerce products, users, taxonomies, custom fields, or plugin data. It does not cover purchasing, license activation, or bypassing restrictions. It assumes the plugin is already available on your site, and the task is to configure imports safely and understand where its strengths and limits are.

The main idea is simple: WP All Import Pro works well when the data has a repeatable structure and a clear matching key. If that key is chosen correctly, the plugin can update existing entries, add new ones, import images, work with theme or plugin fields, and run on a schedule. If the key is chosen poorly, the import can easily create duplicates, skip records, or update something other than what you expected.

What the plugin is good for and where it is most useful

WP All Import Pro makes sense anywhere manual content entry has become too slow or too risky. A common example is a product catalog that a supplier sends as CSV or XML. Another is a real estate site where listings regularly come in from an external CRM. A third is an old-site migration, where posts, images, categories, and metadata have already been exported to a file, but the built-in WordPress importer does not provide enough control over field mapping.

The official materials confirm several key use cases: importing XML, CSV, Excel, and Google Sheets files; handling large files; mapping data through a drag-and-drop interface; supporting images, categories, custom fields, WooCommerce, and a number of popular extensions. WordPress.org also notes that the Pro version adds import into custom fields, importing images into the Media Library, importing files by URL, recurring imports, and running custom PHP functions on the data.

In practice, that means the plugin covers not one job, but several closely related ones. The first is initial site population, when you need to load hundreds of pages, products, or listings. The second is regular synchronization, when the file changes and the site needs to update prices, inventory, descriptions, or statuses. The third is partial migration, when you are not moving the entire site, but a specific data type with controlled field mapping. The fourth is bulk editing: export the data, edit it in a spreadsheet, and import it back without touching the rest of the fields.

The real strength of WP All Import Pro is not just support for multiple formats, but control over what gets created, updated, and skipped. The built-in WordPress importer is usually more rigid: it expects a specific format and is less effective with non-standard fields. WP All Import Pro lets you take a file with arbitrary columns or XML nodes and manually connect them to the WordPress fields you actually need. That makes it especially valuable for sites where data lives not just in the title and body, but also in meta fields, attributes, taxonomies, galleries, SKUs, prices, stock levels, or ACF fields.

There is a limit to what it can do, though. The plugin does not turn a messy data source into a clean database on its own. If the file has no stable identifiers, images are not accessible by URL, categories are written in inconsistent ways, and prices arrive in mixed formats, you need normalization first. Sometimes that can be handled with filters, price settings, or a simple custom function. But if the source is chaotic, it is better to clean the file in a spreadsheet or a separate process before sending it into the importer.

Common scenarios worth planning separately

For regular posts, the important fields are title, body content, publication status, author, categories, tags, featured image, and custom fields. For WooCommerce, additional areas come into play: product type, price, sale price, stock, SKU, attributes, variations, gallery, and product categories. For custom post types, the more important question is where the theme or plugin stores the data: in post meta, taxonomies, separate tables, or its own interface.

If the data goes into standard WordPress fields, setup is usually straightforward. If it goes into WooCommerce, ACF, Meta Box, JetEngine, or another plugin, the first step is to check whether WP All Import Pro supports that field type directly or through an add-on. The official documentation has separate sections for WooCommerce, ACF, Meta Box, JetEngine, users, Gravity Forms, and other areas. That does not mean every exotic plugin will import cleanly with no effort, but it gives you a solid process: first find a supported path, then check how the data is stored, then test on a small sample.

Who WP All Import Pro is for, and when another approach may be better

The plugin is a good fit for anyone working with recurring datasets who wants to manage imports from the WordPress admin panel. It is commonly used for stores with supplier price lists, listing catalogs, news and reference sites, migrations from other CMS platforms, user imports, SEO metadata updates, gallery uploads, and connections to external spreadsheets. The more fields you have, and the more often the source changes, the more useful an import template becomes.

A good WP All Import Pro user understands data structure at least at a basic level. They do not have to be a developer, but they do need to see the difference between a CSV row, an XML node, a SKU column, a category, a meta field, and an image URL. The drag-and-drop interface helps reduce the need for code, but it does not remove the logic: every column has to land in the right place, and every update needs a matching rule.

The plugin may not be the best fit if the data source constantly changes structure, if the import has to run in real time through an API with no intermediate file, if the data is written into undocumented private plugin tables, or if the client expects "one button" with no testing phase. In those cases, it may be better to use a dedicated integration, the external system's native API, or a more specialized tool for that platform.

Stores deserve a separate note. WP All Import Pro with the WooCommerce Add-On is very effective for products, variations, prices, stock, images, and categories, but it requires care. Do not import a full catalog on a live site without a backup and a test run on a handful of products. WooCommerce stores a product as a set of connected data, and a mistake in SKU, attributes, or variation rules can be much more expensive than a mistake in an ordinary blog post.

Practical rule: if, after the import, you cannot quickly explain which field the plugin uses to match an existing record to a new row in the file, the setup is not ready to run at full scale.

When the Pro version really matters

The free version of WP All Import is useful for basic imports, but the Pro version becomes necessary when you need to import images from URLs into the Media Library, work with custom fields, run recurring imports from external sources, use custom PHP functions, or get premium support. WordPress.org explicitly lists these as Pro-only capabilities. For a simple one-time post import without images or meta fields, the base tool may be enough. But for a real catalog or store, requirements that depend on Pro and add-ons usually show up quickly.

That said, do not choose Pro just because of the word "automation." Automated imports are only useful once you have already debugged the manual run. Start with one test file, then verify the result, then rerun it as an update, then protect against duplicates, and only then put it on a schedule. That order feels slower, but it saves time by preventing cleanup later.

What to check before installation and before the first import

Preparation starts not with the New Import button, but with evaluating the site and the file. The plugin runs inside WordPress and depends on the server, memory, PHP execution time, and the extensions used for XML, archives, and spreadsheet handling. The official troubleshooting section lists the basic server components: cURL, libxml, SimpleXML, xmlreader, xmlwriter, ZipArchive, along with PHP and MySQL requirements. This article intentionally does not lock version numbers into the HTML because they change, but before you start, you should compare current requirements against the documentation and your hosting environment.

The first mandatory step is a backup. For a store or a site with a large amount of data, you need more than a file archive - you also need a database dump. If the import creates hundreds of products, categories, and attachments, manually deleting things to roll back is unreliable. A good workflow is to make a staging copy of the site, run the import there, save the template, verify the result, and then repeat the same process on the live site with the same file and the same rules.

The second step is to prepare a small sample. Do not begin with a file that has tens of thousands of rows. Take 5 to 20 records that cover different cases: a standard product, a product without an image, a product with multiple categories, a product with variations, a record with Cyrillic text, a record with an empty field, and a record with an updatable SKU. That sample will show how the plugin reads CSV delimiters, which XML nodes it sees, where empty values appear, and which fields need transformation.

The third step is to define the unique key before importing. WP All Import explains in its documentation that the unique identifier must be unique for every record and remain stable when the file is updated. Good candidates are usually a SKU, an external ID, a slug, or a combination of fields. Bad candidates are a description, a price, a random row number, a modification date, or any field the supplier may change. If the key changes, the plugin cannot reliably determine that a new row belongs to a record that already exists.

File checklist before upload

• Check the encoding, especially if the file contains Cyrillic text, special characters, or data from an older system.
• Make sure the CSV delimiter and quoting are detected correctly, and for XML confirm that the right parent node is selected.
• Identify a field you can use as a unique identifier and verify that it contains no duplicates.
• Open image URLs in a browser without authentication if images are supposed to be downloaded from an external source.
• See how categories are represented: as one string, multiple columns, a hierarchy, or separate nodes.
• Separate fields that can be updated regularly from fields that should be preserved after manual editor changes.

Site checklist before launch

• Create a backup of the database and files, including the Media Library.
• Disable aggressive admin-panel caching if it interferes with AJAX or the wizard steps loading correctly.
• Verify that the required plugins, post types, and fields already exist before the import starts.
• Create a test record with filled custom fields if you want WP All Import Pro to auto-detect those fields.
• For WooCommerce, configure currency, taxes, attributes, categories, and the basic inventory settings in advance.
• Check user permissions: bulk imports should be run by an administrator or a trusted role with sufficient access.

How to break down the input file before building the template

The most expensive import mistake is assuming the file is self-explanatory. Until you can describe the structure of the source in plain words, the WP All Import Pro wizard will seem easier than it really is. Before setup, it helps to make a small map of the file: which fields are required, which can be empty, which are used only once, which are updated regularly, which should become taxonomies, and which are just control flags for filtering.

For CSV, start with the column headers. Rename them to clear technical names before importing if that does not break the supplier workflow: sku, external_id, regular_price, stock, image_url, category_path. The cleaner the names, the fewer mistakes you will make while dragging fields into place. If the supplier sends Russian headers, that is not a problem, but they do need to be stable and consistent from one file to the next.

For XML, the more important step is selecting the correct repeating node. A single XML file may contain the store, categories, products, variations, images, and internal service blocks. WP All Import Pro needs to see one distinct entity as one import record. If the record is supposed to be a product, the repeating node must be the product node - not the entire catalog, and not an individual image nested inside a product. So before importing, open the XML in an editor or viewer and identify the boundary of a single record.

For Excel and Google Sheets, check not just the data but also hidden formulas. The importer should receive final values, not a visually polished spreadsheet. If the price is calculated by a formula, make sure the exported file contains the resulting number. If the sheet includes notes, merged cells, or extra rows above the headers, it is better to prepare a dedicated import sheet. The plugin can work with different formats, but it should not have to guess where the usable part of the table begins.

Each field as a source of truth

Ask one question for every field: who owns this value after the import? If the supplier owns the price, then a repeat import can update the price. If the editor owns the description, a repeat import should not overwrite it. If the store owns the categories, the import should either use existing terms or create new ones only on the first run. If an external CRM owns the listing status, the import can change publication status, but only after the rules are agreed on.

This logic matters most in stores. At the beginning it feels convenient to update everything from the file, but within a few weeks product pages start to take on a life of their own: an editor improves the copy, an SEO specialist rewrites the title, a manager adds photos, and the store owner manually changes a category. If the next automated import overwrites all of that, the team loses its work. That is why deciding which fields may be updated is not a minor technical detail - it is part of the site's editorial policy.

How to handle empty values

An empty field can mean different things. The supplier does not know the value. The value should be removed. The value has not changed. The value is missing because of an error. If you do not distinguish between those cases, the import will behave unpredictably. For example, an empty price can disable sales for a product, leave the old price in place, or create a product with no price at all. An empty image URL may mean the image does not exist, or it may mean the image should not be updated.

Before a repeat import, decide how empty values should be handled. For critical fields, it is safer to filter out records where key data is blank. For stock updates, you may want to allow zero but not an empty string. For images, you may want to import them only during the initial run and leave them untouched during later updates. That approach reduces the risk that a temporarily incomplete file will damage a catalog that is already live.

Pre-import decision table

This table does not replace the WP All Import Pro settings, but it helps you avoid making decisions on the fly. If you already know the source is responsible only for price and inventory, you will not enable updates for every field. If you already know the image URL is sometimes empty, you will test how the plugin behaves on a repeat run. If you can already see that category_path is not normalized, you will not be surprised by dozens of newly created terms.

How to build a safe process for your team

Imports are rarely handled by one person in isolation. Usually the site owner, content manager, developer, SEO specialist, and sometimes the data supplier are all involved. If the process is undocumented, each person only sees their own slice of it: the supplier thinks "the file was sent," the manager assumes "the plugin will load everything," the developer says "we need a stable key," and the owner expects a finished catalog. WP All Import Pro helps with the technical part, but the team workflow has to be defined separately.

A minimal working process looks like this. First, the responsible person signs off on which fields come from the external source. Then a technical specialist configures the import on staging and saves the template. The content manager checks several records in the admin panel and on the front end. The SEO specialist confirms that important metadata is not being overwritten. Only then is the import run on the live site. If the source changes the structure of the file, the process goes back to the test sample instead of being rerun automatically "the same way as before."

For recurring imports, it helps to keep a simple change log. It only needs to record the run date, file source, number of created and updated records, errors, template changes, and the person responsible. Dates do not belong in `article-RU.html`, but in a real project a log like this makes it much easier to understand why yesterday 300 products were created and today only 20 were. On a commercial site, that is not bureaucracy - it is a fast way to reconstruct the decision chain.

Access rights and client mode

Not every editor should have full access to the import template. A mistake in the unique identifier or the update settings can change the entire catalog. If the team is large, split responsibilities: one person prepares the file, another runs the approved import, and a third has permission to modify the template. WP All Import documentation covers Client Mode, but even without it, one rule is worth keeping: only someone who understands the consequences of field updates should be allowed to edit the template.

If the site is maintained by an agency, give the client clear instructions: which file to upload, where to look after the run, which errors count as critical, and who to contact if the file structure changes. Do not hand over a complex import as a black box. The better the boundaries are documented, the less likely it is that someone will accidentally enable deletion of missing records or overwrite SEO descriptions.

When to stop an import

Sometimes the right move is not to patch the template on the live site, but to stop. If the file suddenly becomes half its normal size, if the SKU column disappears, if image URLs stop opening, if XPath shows a different record count, or if the supplier changes the category format, postpone the full run. Start with a small sample, compare the structure to the previous file, and only then update the main import.

This matters even more for automated schedules. Automation cannot tell on its own that the supplier sent an incomplete file. That is why critical imports need oversight: at minimum, log review, an alert for abnormal record counts, or a manual check after a format change. WP All Import Pro provides tools to run and update imports, but responsibility for source quality still belongs to the person who owns the process.

Installation, first run, and how the import wizard works

Once the plugin is installed and activated, the working area is under the All Import menu. For a new process, the path is All Import - New Import. The documentation describes three source options: upload a file from your computer, enter a file URL, or select an existing file. In Pro workflows, the URL option is especially useful because it lets you update the import later from the same source and connect it to a schedule.

The first wizard step is choosing the source and the target data type. You can import posts, pages, taxonomies, users, or custom post types added by themes and plugins, including WooCommerce Products. It is important to choose the target correctly from the start: importing into regular posts and importing into WooCommerce products open different sets of settings. If you choose the wrong target at this stage, it is usually better to create a new import than to try to repair an unsuitable template.

At the next step, the plugin shows a preview of the file. For CSV and Google Sheets, verify the delimiter. For XML, verify the selected node. This is not a formality. If the parent node is chosen too high, one "record" may contain the whole file. If it is chosen too low, the plugin may see not a product but only part of one. In CSV, a wrong delimiter can collapse all columns into a single field, making the rest of the mapping meaningless.

Then you reach the main template screen, where elements from the input file are dragged into WordPress fields. This is where the plugin delivers its practical value. You do not need to reshape the source file to fit WordPress, but you do need to connect every important field to the correct destination. The title goes into title, the description into content or excerpt, the image into Images, the category into Taxonomies, SKU and price into the WooCommerce Add-On, and custom fields into Custom Fields or a supported add-on.

How to get through the first import safely

1. Create a small test file and select it in All Import - New Import.
2. Choose the target data type, such as Posts, Pages, the required custom post type, or WooCommerce Products.
3. On the preview screen, make sure the plugin split the file into records correctly and shows the values you expect.
4. Map only the required fields first, then add images, taxonomies, custom fields, and any extra settings.
5. On the settings step, define the unique identifier manually if auto-detection seems questionable.
6. Run the import on the small sample and immediately review the created records in the admin panel and on the public side of the site.
7. Repeat the import with a modified file to confirm that updates work instead of creating duplicates.

Do not enable deletion of missing records, mass updates for every field, or scheduling right away. Those features are useful, but only after the base workflow has proven that the template works correctly. First create records, then update them, then limit which fields may be updated, and only then turn on automation.

Settings map: source, filters, template, updates, and the unique identifier

Setting up WP All Import Pro revolves around five decisions. First, where the file comes from. Second, which records from that file should be imported at all. Third, how the incoming elements are mapped to WordPress fields. Fourth, how the plugin decides that a record already exists. Fifth, which fields are allowed to update on repeat runs. When those decisions are made intentionally, the import becomes manageable.

File source and repeatability

For a one-time migration, you can upload a file from your computer. For recurring updates, it is better to use a URL or an existing server-side file so the source stays consistent between runs. The documentation also covers Google Sheets and external files. What matters is not just whether the file is reachable, but whether its structure is stable. If a supplier sends sku today, SKU tomorrow, and article next week, the template will have to be changed.

If the file is password-protected or requires authentication, do not pass secrets through third-party systems or hardcode them into public locations. For imports from protected sources, use only the plugin's documented mechanisms and keep credentials where the WordPress admin panel expects them. This article intentionally avoids examples with logins, tokens, or private URLs.

Filters and XPath

Filtering is useful when you do not want to import every row. For example, only products with a populated image URL, only records from a certain category, or only items above a specified price threshold. The documentation shows the visual filter builder in Manage Filtering Options, where you choose an element, a rule, and a value, and then apply that rule to XPath. The logic is the same for XML and CSV because CSV is represented in a similar way during processing.

Filters are especially useful for a safe first run. Instead of importing the entire catalog, you can select a few SKUs, one category, or records marked with test. After verification, you remove or change the filter. If the filter is complex, document its purpose in the project notes, because a month later it may be hard to remember why part of the file was intentionally excluded from the site.

Unique identifier

The unique identifier is not a visible field for visitors. It is an internal key the plugin uses to connect a row in the file to a record that was created earlier. The official documentation stresses that it must be unique within the file and remain stable across updates. For products, the best starting point is almost always a SKU or an external ID. For real estate listings, use the property ID from the CRM. For records migrated from an older CMS, use the old identifier or a stable slug.

Auto-detection is convenient, but it should never replace verification. If the import skips every record, creates only one record, or updates the wrong items, the first thing to inspect is the unique identifier and the import history. The documentation explicitly notes that an incorrect, empty, or static identifier can lead to skipped records or behavior that looks like duplication. For anything important, it is better to set the key manually than rely on a field chosen by accident.

What to update on repeat imports

On the settings step, decide which data may be overwritten. For a supplier price feed, it usually makes sense to update price, stock, and availability, while leaving manual SEO descriptions, edited body text, and images alone if an editor has already improved the product page. For a news migration, by contrast, you might import the title, date, body, categories, and image once and never run updates again.

Do not enable mass updates for every field out of habit. On a living site, some data may have been improved after the first import. A good template separates ownership clearly: the supplier controls price and stock, the editor controls text and SEO, WordPress controls publication status, and the store controls categories and attributes. WP All Import Pro lets you configure that separation, but the decision belongs to the administrator.

Deleting records that no longer exist in the file

Features that delete or change records missing from the new file require extra caution. They are useful when the external source truly is the primary catalog and a missing row means the product or listing should no longer be published. But if the supplier temporarily sends an incomplete file, automatic deletion can remove perfectly valid records. Before enabling that logic, confirm that the source guarantees file completeness and test the behavior on a site copy.

Importing images, galleries, taxonomies, and custom fields

Images differ from text fields because WP All Import Pro has to do more than save a value. It has to fetch the file, add it to the Media Library, attach it to the record, and sometimes assign it as the featured image. The official documentation highlights several image sources: URL, Media Library, server, variable numbers of images, metadata, and settings. That is why image problems are often caused not by the template itself, but by file availability, permissions, size, reuse behavior, and naming.

If the image comes from a URL, confirm that it opens without logging in. If the link points to a page containing an image rather than the image file itself, the import may fail to download it. If the source server blocks frequent requests, a bulk import may stop midway. If a row contains multiple images, define the delimiter and ordering ahead of time. The first image can be used as the main image and the rest can go into the gallery, but only if the file structure is clear.

For taxonomies, decide whether the import should create new terms or reuse existing ones. This is critical in stores: "Shoes," "shoes," "Footwear," and "footwear" can become separate terms if the source is not normalized. For hierarchical categories, verify the path format in advance. WP All Import documentation has dedicated material on direct taxonomy import, nested hierarchies, taxonomy meta, and term images. If your category structure is complex, do not leave it until the end: it affects navigation, filters, and SEO.

Custom fields require even more attention. Many themes and plugins store data in post meta, but it is not always obvious what the target field is called or what format it expects. The custom fields documentation recommends creating a published test record with completed values so WP All Import can auto-detect the fields. It is a simple but important trick: instead of guessing the key, you give the plugin a real example to work from.

ACF, Meta Box, JetEngine, and similar field types

If the site uses ACF, Meta Box, or JetEngine, start by looking for a documented add-on or documentation section. Those fields may use special storage formats: repeaters, groups, selections, images, relationships, maps. A simple field can often be written as a regular meta key, but a complex field is better imported through a supported interface. That reduces the risk of ending up with a value that exists in the database but does not show in the admin panel or breaks front-end output.

For ACF Repeater and flexible fields, do not start with the full file. Create one test object, fill every state of the field manually, inspect how it looks in the admin panel, and then build a small import. If the plugin displays the fields and values correctly, expand the sample. If it does not, check the documentation for the specific add-on, because different field types require different input structures.

Images and SEO metadata

WP All Import Pro can work with image metadata, but that is not a reason to generate the same alt text for every file. If the source contains a product name and a brief characteristic, use them to create meaningful alt text. If the source does not provide that context, it is better to leave the field empty and handle the Media Library separately later than to import meaningless repetition. In a catalog with thousands of images, metadata quality affects not just SEO, but also searchability inside the Media Library.

WooCommerce: products, prices, stock, and variations

WooCommerce import is one of the most common reasons to use WP All Import Pro. The documentation includes a dedicated wizard for WooCommerce Products, where selecting the file opens the WooCommerce Add-On section with tabs. For a simple product, the important pieces are usually the name, description, product type, price, sale price, stock, SKU, categories, images, and attributes. For a variable product, you also need the parent-child variation logic.

On the General tab, you configure price, sale price, price adjustment, how to handle currency symbols and decimal separators, and options such as virtual, downloadable, tax status, and tax class. These are not just form fields. If the supplier sends a price with a currency symbol or uses a comma instead of a period, check the price preview before running the import. If the file contains empty prices, decide what should happen: the product is not imported, it is left without a price, it is saved as a draft, or it is handled by a separate rule.

On the Inventory tab, you configure SKU, stock management, and stock status. In most cases, the SKU works best both as the visible product code and as part of the unique import identifier. If the SKU is unstable or the supplier changes it during updates, the store will either receive duplicates or lose continuity with existing products. For stock synchronization in particular, it is important that a repeat import updates only the necessary fields instead of overwriting the entire product.

Attributes and variations need their own logic. WooCommerce stores a variable product as a parent product plus a set of child variations. WP All Import documentation describes multiple grouping methods: by Parent SKU, by Group ID, by title, by rows without parent products, and by child XML elements. The right choice depends on the file structure, not on administrator preference. If the file contains a Parent SKU, use it. If there is no parent but there is a Group ID, group by that. If variations are nested inside the product XML node, point XPath to the variation elements.

How not to break variable products

Most variation problems come from three causes. The first is the lack of a stable parent key. The variations do not know which product they belong to, so they are created incorrectly. The second is mismatched attributes. For example, the file may contain "Blue" while the site already uses "Navy," or one row may say size "L" while another says "Large." The third is missing prices. The documentation notes that WooCommerce will not display variations on the front end if they have no price.

A good variation test looks like this: create one product with two or three variations, inspect the parent product in the admin panel, open the attributes tab, open the variations tab, check the price and SKU for each variation, then open the product page on the site and try selecting an option. If the variation does not appear, the problem may not be the theme display at all. It may be the data: no price, no attribute, the attribute is not marked for variations, or the variation is not linked to the parent.

Updating prices and stock

For a recurring price feed, you do not need to update everything every time. Usually price, sale price, stock quantity, and stock status are enough. Descriptions, images, and categories are often better updated separately because editors may have improved them after the initial import. If the supplier sends only current stock levels, configure the repeat import so it does not wipe out data that is missing from the file.

If you work with multiple suppliers, do not combine them into one import unless there is a strong reason to do so. Each source can have its own SKU format, category structure, and stock rules. It is better to create a separate template for each source than to build one oversized template full of exceptions. That makes troubleshooting easier and lets you disable one import without affecting the others.

Practical example: importing a supplier catalog and updating price and stock

Let us walk through a concrete scenario. There is a WooCommerce store, and the supplier provides a CSV file with the columns external_id, sku, name, description, category_path, regular_price, stock, image_url, brand. The goal is to create products, import images, place products into categories, save the brand in a custom field, and then regularly update only price and stock.

Goal and preparation

The goal is a controlled import that can be rerun without creating duplicates. Before starting, create a staging copy of the site, make a backup, confirm that WooCommerce is enabled, categories can be created, the brand field already exists in the theme or in ACF, and the supplier's images open through direct URLs. From the full file, create a test sample of several products: a standard product with an image, a product without an image, a product with Cyrillic text, a product in a nested category, and a product with zero stock.

Setup steps

1. Open All Import - New Import and upload the test CSV.
2. Select import into WooCommerce Products.
3. On the preview screen, verify that the columns were detected correctly and that each row corresponds to one product.
4. In the template, drag name into the title, description into the description, and category_path into product categories.
5. In the WooCommerce Add-On, set the product type to Simple product and map regular_price, sku, and stock.
6. In the image block, set image_url and configure the first image as the featured image if that matches the catalog structure.
7. In custom fields, map brand to the real brand field after verifying its key or auto-detection.
8. On the settings step, define the unique identifier: preferably external_id or, if it is stable, sku.
9. Run the import only on the test sample.

Checking the result

After the first run, do not stop at the success message. Open the product list in the admin panel and confirm that exactly as many products were created as were present in the test file. Then open one product: the title, description, SKU, price, stock, category, image, and brand field should all be in place. After that, open the public product page, because some errors only show there: the price does not display, the image does not render, the product is hidden from the catalog, the category does not appear in the menu, or the theme does not read the expected custom field.

Next, change the price and stock for one product in the test CSV while keeping the same unique identifier. Run the import again and confirm that the existing product was updated and no duplicate appeared. If a duplicate shows up, the unique identifier or the match existing mode is configured incorrectly. If the product updates but the description is also overwritten, go back to the update settings and limit which fields are allowed to change on repeat runs.

The zero-stock nuance

Zero stock does not always mean a product should be removed. One store may need to hide the product, another may keep it visible as "out of stock," and a third may allow backorders. So do not tie that business decision to the import automatically. Define the store rule first, then configure stock status and visibility. If the supplier temporarily omits a product from the file, do not rush to delete the product page: updating stock or status may be the better choice, especially if you want to preserve the product's SEO history.

Recurring imports, scheduling, and load control

Recurring imports are needed when the source changes: price lists, stock, real estate listings, ads, jobs, courses, events. WP All Import offers two approaches: manual scheduling through cron jobs and the paid Automatic Scheduling Service. The documentation explains that Automatic Scheduling is configured from Manage Imports through Scheduling Options, while manual cron requires server-side setup. The right choice depends on your hosting, cron access, and project requirements.

Before putting an import on a schedule, answer three questions. How often does the source actually change? How long does the import take to run? What happens if one run has not finished before the next one starts? If the supplier updates the file once a day, there is no reason to run the import every few minutes. If the file is large, frequent runs can put unnecessary load on the database, Media Library, and the external image server.

The official troubleshooting documentation notes that artificial limits on script execution time or MySQL query time can prevent imports from finishing. For large files, it is often better to use processing settings, split the task, reduce the batch size, import images separately, or update only the fields you actually need. The quickstart documentation also mentions advanced settings for large XML files, including chunked processing and batch processing.

How to build a safe update cycle

1. Debug the manual import on a small sample.
2. Run the full file manually on staging and measure the execution time.
3. Configure the repeat import so it updates only the fields controlled by the source.
4. Review the history and logs after the first full run.
5. Choose a schedule with enough buffer so a new run does not start on top of the previous one.
6. Add a routine result check: number of updated records, image errors, skipped rows, unexpected duplicates.

If the import is critical to sales, do not leave it unmonitored. Automation reduces manual work, but it does not eliminate the need for oversight. Good practice is to review logs after a file format change, after a plugin update, after a hosting migration, and after new fields are added.

Checking the result after import

Result checking should be just as structured as setup. A successful completion means the plugin finished the process without a fatal error. It does not prove that the data landed in the correct fields, that variations are available on the site, that images were attached, or that old manual edits were preserved. That is why every import needs a set of validation points afterward.

Checks in the admin panel

Start by checking the number of created and updated records. If the test file has 20 rows and only one record was created, the problem is almost certainly the unique identifier or the selected XML node. If more records were created than there are rows, check variations, child elements, and term-creation rules. Then open several records manually: one ordinary record, one with an empty optional field, one with an image, one with multiple categories, and one with an updated value.

In WooCommerce, also check the product tabs: General, Inventory, Attributes, and Variations for variable products. Look not only at whether fields are filled, but whether they are formatted correctly: the price should be numeric, the SKU should be a string with no extra spaces, the stock value should be correct, attributes should be tied to variations, categories should map to the right terms, and you should not see accidental duplicate terms.

Checks on the front end

Open the public post or product page. Check the title, body, image, breadcrumbs, category, filters, variations, price, availability, buttons, theme blocks, and the SEO snippet if metadata was imported. Some fields may be written to the database but still not display because the theme expects a different field name or a different format. This is especially common with custom fields and more complex add-ons.

If the site uses caching, clear it after the import and check the result as a visitor. But do not use cache as the explanation for every problem. If a field is missing in the admin panel, clearing cache will not help. If the field exists in the admin panel but is not visible on the site, then check the theme template, cache layer, display conditions, and compatibility.

Repeat update test

The most important check is a repeat import with a modified file. Creating data is easier than updating it correctly. Change the price, stock, one description, and one category in the test sample. Run the import again and compare the result to your expectation. If only the allowed fields changed, the template is ready to scale up. If manual edits were overwritten, go back to the update settings. If duplicates appeared, go back to the unique identifier and match existing settings.

Common WP All Import Pro problems and how to diagnose them

Most problems have a clear symptom. The key is not to treat everything with a single move like "reinstall the plugin," but to work from symptom to cause: the file, the server, a conflict, the unique identifier, permissions, images, the WooCommerce structure, or the update rule. Below is a practical diagnostic guide based on the documentation and common import scenarios.

The import creates duplicates instead of updating

Symptom: after a repeat run, new posts or products appear even though the old ones were supposed to be updated. One possible cause is that the unique identifier changed, is empty, is not unique, or was chosen from a field the supplier updates. Another possibility is that the import is configured to create new records without matching them to existing ones.

What to check: open All Import - Manage Imports, review the import settings, and inspect the unique identifier field. Compare the key value in the old file and the new file. If it is a SKU, check for spaces, case changes, and hidden characters. If it is a composite key, make sure every part is available in every row.

How to fix it: use a stable external ID, SKU, or a combination of fields that does not change. On staging, remove the test duplicates or restore the database, then rerun the import. If you had to change the key for an existing import, do not do it blindly on the live site: the documentation warns that changing the identifier for an existing process may require deleting previously imported records or reconfiguring the import very carefully.

Only one record gets created, or some rows are skipped

Symptom: the file contains many rows, but the import creates one record, only a handful of records, or reports duplicates. A likely cause is a static unique identifier, the wrong XML node was selected, the CSV was read as a single column, or a filter is excluding most of the data.

What to check: on the file preview step, confirm that the plugin shows the correct number of records. For XML, verify the parent node. For CSV, verify the delimiter. Open the filters in Manage Filtering Options and temporarily disable complex conditions. Review the import history.

How to fix it: select the correct node or delimiter, define the unique identifier from a real field in the record, simplify the filter, and repeat the test on a small sample. If the source is complex, first import without extra fields so you can prove the plugin is seeing the records correctly.

Images do not import or do not become the featured image

Symptom: the records are created, but the Media Library is empty, images are not attached, or the featured image is missing. The cause may be an inaccessible URL, a link to an HTML page instead of a file, source protection, a timeout, a wrong delimiter for multiple images, or incorrect featured-image settings.

What to check: open several image URLs in a private browser window. Make sure the link points directly to the file. Check permissions on uploads and review the import log. If there are many images, make sure the process is not hitting hosting limits.

How to fix it: use direct URLs, reduce the test sample, reconfigure the Images field, verify the option that assigns the first image as the featured image, and rerun the import. If the source blocks downloads, arrange another way to access the files or upload the images to your own server and import them from there.

Drag and drop does not work, or the wizard screen looks broken

Symptom: elements cannot be dragged, the step screen looks broken, or buttons do not respond. The official troubleshooting section recommends first clearing the browser cache or trying another browser, then checking for a theme or plugin conflict. Some themes and extensions may load their own JavaScript or CSS on WP All Import screens and break the interface.

What to check: open the wizard in another browser, temporarily disable browser extensions, and inspect the console for JavaScript errors. On staging, deactivate third-party plugins and switch to a default WordPress theme. If the problem disappears, reactivate extensions one by one to find the conflict.

How to fix it: update the conflicting plugin or theme, limit its scripts from loading in the admin area, or contact the developer or support team. Do not run a bulk import through a broken interface: first restore stable wizard behavior.

The import does not advance to the next step or stops midway

Symptom: the wizard will not move between steps, the import stops, or the process ends before completion. The documentation separately mentions PHP session issues, server limits, script execution time, and MySQL queries. With large files, this is a common cause.

What to check: does a small file work, does the problem reproduce on staging, are there errors in the server logs, and are memory and execution time sufficient? If the import works on a debugging server or another environment, the cause is more likely to be your hosting configuration.

How to fix it: reduce the batch size, split the file, import images separately, disable non-essential update fields, and ask your host to inspect the error log and server limits. If the issue is related to PHP session handling, it is usually something the host needs to resolve, not a template setting.

Cyrillic text, special characters, or prices import incorrectly

Symptom: text turns into incorrect characters, prices are not recognized, or the decimal separator breaks the amount. For CSV, WordPress.org recommends UTF-8 when special-character issues occur, and the WooCommerce Add-On documentation shows settings for stripping currency symbols and converting the decimal separator.

What to check: the file encoding, CSV delimiter, price format, and the presence of currency symbols, spaces, and non-breaking spaces. In WooCommerce, use the price preview if it is available in the settings.

How to fix it: save the file as UTF-8, normalize the price into a predictable format, enable the relevant WooCommerce Add-On settings, or use a safe custom function to transform the value. Always test any transformation on a few rows first.

Safe enhancements and custom functions

WP All Import Pro supports running custom PHP functions against imported values. WordPress.org describes this as passing a value from XPath into a function and returning the processed result. This is useful when the source sends data in a format that is close to usable but not quite there: a price with spaces, units mixed into one string, extra characters, old statuses, or inconsistent versions of "yes/no."

Use these functions only for small, reversible transformations. Do not write code that creates records, changes user permissions, deletes files, or calls external APIs during the import itself. Bulk imports already create load, and complex code executed on every row can slow the process dramatically. If possible, fix the file at the source first. If that is not possible, add a short function in a safe location such as a child theme or a trusted snippets plugin, and test it on staging.

Price normalization example

Suppose the supplier sends the price as $1,299.50, while WooCommerce expects a numeric value. You can use a small function that strips spaces, currency symbols, and thousands separators. This is not a plugin-specific hook - just a regular PHP function that you can then call in an import field using WP All Import syntax.

function cb_normalize_import_price($value) {
    $value = trim((string) $value);
    $value = str_replace(array(' ', "\xc2\xa0", '$', ','), '', $value);
    return is_numeric($value) ? $value : '';
}

In the price field, you can use a call based on the custom-function logic supported by WP All Import: [cb_normalize_import_price({regular_price[1]})]. Before a full run, preview a few rows: a normal price, a price with a comma, an empty price, and a price with a currency symbol. If the function returns an empty value for an unusual row, decide what should happen to that record: skip it, keep the old price, or send the file back for correction.

Rollback is simple: remove the function call from the import template and restore direct field mapping. If the function was added through a snippets plugin, disable only that snippet, not the entire import.

When not to add code

Do not add a PHP function if the issue can be solved with a filter, a field setting, or a CSV correction. Do not add code if you do not understand how many times it will execute. Do not use a function to access private keys, external APIs, or modify the database outside the current field. For more complex business logic, it is usually better to prepare the data before the import, because that is easier to test and repeat.

Product video

For a visual overview, the official WP All Import YouTube video related to WooCommerce data import is useful. It addresses the practical intent of "what importing products with WP All Import Pro actually looks like": choosing the source, mapping the data, and seeing the result in the store. Treat it as a companion to this guide, not a substitute for testing on your own site, because the structure of your CSV or XML will almost certainly be different.

After watching it, check three things in your own setup: whether you chose the correct target import type, whether a repeat run creates duplicates, and which fields are allowed to update. Those decisions usually matter more than copying the interface steps from the video word for word.

When WP All Import Pro is the right choice

WP All Import Pro is worth using when you have a repeatable data source, a clear unique key, and a task that goes beyond simply "upload a few records." It is especially useful for catalogs, WooCommerce stores, sites with custom post types, migrations, image imports, custom-field workflows, and recurring updates from external files. Its value shows up not on the first run, but on controlled repeat imports, when old records update without duplicates and without wiping out manual improvements.

Before running it in production, verify the file, staging, backup, unique identifier, update rules, images, and a few control records on the public side of the site. If everything checks out, you can download the ZIP file and move on to careful setup in your own project. If the data source is unstable or the site uses undocumented custom storage, start with a small sample and do not turn on automation until you understand how every field behaves.

A well-configured import does not look flashy - it just does the job consistently. New records appear where they should, existing ones update through a stable key, images attach correctly, variations are selectable on the site, and the logs do not hide unexpected errors. That is exactly what your WP All Import Pro setup should aim for.