How rows are matched to items on your site
How Content Uploader decides that a row is new or the same item as before: by record ID, or by slug or title with the category as tiebreaker.
- 4 min read
- Updated October 14, 2026
Every time a file is checked, each row is matched against what Content Uploader published to this site and content type before. That decides whether the row is new or an update of an item it knows.
With a record ID column#
The row's ID is looked up among the items published to this site and content type. If found, the row is that item (an update, or unchanged). If not, it is new.
- The comparison is exact:
HLJ-001andhlj-001are different IDs (spaces at the ends are ignored). - It does not matter which configuration published an item, or which file, or when: the item belongs to the site, and any configuration for the same site and content type that uses the same IDs reaches it.
- It does not matter where the row is in the file.
Without a record ID column#
The row is identified by its slug if it has one, otherwise by its title, compared the way people compare them: capital letters, extra spaces, markup and character references do not matter. That text becomes a fingerprint kept with the item.
When the category is known, it breaks ties. The row's category, with its parents, is a second fingerprint used only when titles are not unique:
- A row takes the published item that has its title and the same category.
- When a single row and a single item are left over, they belong together: the category was changed, so the item is updated and not published twice.
- When several rows and items are left over, which is which would be a guess, so those rows are new and the items stay as they are.
- Two rows with the same title and category in one file cannot be told apart: the first counts and the later ones are rejected (duplicate rows).
Each new item gets a generated identifier (cu- and a code), made once the whole file is prepared, which goes to your site as the item's external identifier and stays with it for good. The review hides these identifiers, since you have no such column.
Limits of matching by title: a changed title (or slug, when there is one) is a new item and the old one stays on your site, and nothing is ever deleted. Adding a slug column later makes every row look new, because the fingerprint changes from title to slug; the review lists them as new before anything is published. Rows are matched among everything published for the site and content type, including items that another configuration published with IDs.
What is not matched#
Content Uploader knows only the items it published. Something that was already on your site before, or that someone created by hand, is not matched by title, slug or ID: a row with the same title creates a new item next to it. See choosing the record ID.
WooCommerce products: matched by SKU#
On a WooCommerce shop, a row can also be matched with a product the shop already has, by its SKU, when the configuration says so (update products already on your shop). The SKU is read from the shop each time a file is checked. A SKU that belongs to a product the configuration does not update, or a GTIN that another product has, is a row error and never a second product.
The item itself#
After a match, Content Uploader also asks your site about the item (is it still there, is it in the trash, can the account still edit it, is someone editing it) so that the review shows an honest picture:
- It was deleted on the site: the row is shown as updated with The destination item was deleted, so it is created again. and creates it again under the same ID.
- It is in the trash: the item is skipped (In the destination's trash…).
- Two items claim the same ID on the site: skipped (Another destination item already uses this record ID.).
A file with a few rows#
The comparison looks only at the rows in the file. Items that are not in it are neither deleted nor changed, so a file can be a partial update (updating existing content).
Two files at the same time#
Two files that contain the same new item must not both publish it: the second to publish is refused as out of date (Another file was published after this one was checked.) and is checked again, which then shows the item as updated or unchanged (when publishing is refused).
Was this article helpful?
Related articles
- Importing dataChoose the record IDThe record ID column lets next week's file update an item instead of creating it twice: what makes a good ID, how matching works without one, and what changing it does.
- Preparing your spreadsheetDuplicate IDs, titles and rowsWhat happens when two rows share an ID or a title in one file, the error each gets, why the first row wins, and why the same item next week is an update, not a duplicate.
- Mapping columnsUpdating content that is already publishedWhat happens to an item you published earlier when its row changes: the review lists the changed fields, every mapped field is sent, and the address and ID stay.
- Reviewing and publishingHow Content Uploader avoids duplicates, and when duplicates can still happenThe safeguards that stop an item being published twice (record IDs, the review, the last check, safe retries) and the few cases where two copies can still happen.