Mapping tells the plugin which column in your file belongs in which WooCommerce field. It is step 4 of an Advanced import, and it is where most import problems are either created or avoided.
What the screen shows #
Every header from your file appears on the left. Beside each one sits a dropdown listing the destination fields available for the data type you are importing. The plugin pre-selects the ones it recognises, so a file exported by the plugin arrives fully mapped and needs no work.
Leave a dropdown empty and that column is ignored. This is how you import a supplier file that contains twelve columns when you only care about three.
How the automatic matching works #
Header names are normalised before matching. Spaces and hyphens become underscores, and everything is lowercased. Regular Price, regular price and REGULAR_PRICE all resolve to the same field.
The plugin also understands both naming conventions for products. Name and post_title map to the same place, as do Description and post_content, and Status and post_status. If your file uses one and you expected the other, the import still works.
Identifier columns #
The most important mapping on the screen is the identifier. For products that is ID or SKU. For orders it is Order ID. For categories and tags it is the term ID or the slug.
Without a mapped identifier, every row looks new. Your update becomes an insert, and you end up with two of everything. If an import created duplicates rather than updating, an unmapped identifier is almost always the cause.
Identifier fields are protected during mapping. If two columns map to the same identifier, the first non-empty value wins and later ones cannot overwrite it, so a stray blank column does not wipe out a product ID.
Mapping custom fields #
Columns whose names begin with meta followed by a colon are treated as custom fields and written to post meta under that key. This is how data from other plugins survives a round trip. Export with custom meta enabled, edit, and import the same columns back.
You can also create custom fields that did not exist before by naming a column with the meta prefix and the key you want.
Product-specific notes #
Variations #
Variation rows need Parent SKU mapped, and the parent product must exist, either already in the store or as a row earlier in the same file. Map the product type column too, so variation rows are recognised as variations rather than becoming standalone simple products.
Categories and tags #
Multiple values in one cell are separated by commas. Nested categories use a greater-than sign between levels, so a value like Clothing greater-than Shirts creates or matches the child under its parent. Categories that do not exist yet are created during the import.
Images #
Image columns take URLs, separated by commas when there are several. The first is the featured image and the rest go to the gallery. The URLs must be reachable from your server, not just from your browser. Images download in background jobs after the row itself is written, so an import can report complete while images are still arriving.
Prices and stock #
Prices should be plain numbers with a dot as the decimal separator. Strip currency symbols and thousands separators in the spreadsheet before importing. A blank sale price column clears any existing sale price, so leave the column out entirely if you do not want to touch sale prices.
Order-specific notes #
Orders carry structural columns that have no single destination field, because a line item is not one value. Line items, shipping lines, fee lines, tax lines, coupon lines, refunds and order notes each pack all of an order’s entries into one column.
You do not map these one by one. The importer recognises them by their column names and carries them through automatically, as long as you have not remapped those columns to something else. Leave them alone and they work.
Map the billing email and the customer ID if you want orders attached to existing customer accounts. Without them, orders arrive as guest orders.
Saving a mapping #
Save the mapping as a template on this step and you can load it on a later import. For a recurring supplier file with unusual column names, this removes the weekly job of remembering what maps to what, and it removes the chance of somebody mapping it differently.
Checking before you commit #
- Is the identifier mapped?
- Are two columns pointing at the same destination field by accident?
- Are the columns you meant to ignore actually set to empty?
- For products, is Parent SKU mapped if the file contains variations?
- For orders, are the totals columns mapped?
Run ten rows first. The mapping screen looks right far more often than the result does.
