Repeatable Content Imports into WordPress: IDs, Relationships and Safe Re-runs

A small website can be moved by copying a few pages. A catalogue containing hundreds of records needs a different approach. The difficult part is rarely getting the first import to succeed; it is making the second import behave sensibly. Without a deliberate matching strategy, another run produces duplicates, overwrites editorial corrections or detaches images from their records. A migration job should therefore be designed as a repeatable process, not as a one-time upload that nobody wants to touch again. This matters particularly when an AI-built frontend displays content supplied by a spreadsheet, an external database or a separate content service.

Find the real content source

Start by distinguishing displayed content from authoritative data. A browser snapshot can show a product description, but it may omit internal references, unpublished entries and relationships. Export from the system that owns those records whenever authorised access is available. Document what the export contains and what it leaves behind. A visual conversion through Convert2WP.net addresses the presentation layer; it should not be treated as an export of private databases, user accounts or payment history. Those need their own authorised migration process. Keep a dated source snapshot so that later disagreements can be traced to an actual input rather than a memory.

Give every record an identity

Titles and slugs are poor identifiers because editors change them. Prefer a stable source key, stored in dedicated post metadata alongside a source-system name. The combination identifies a record even when its public URL changes. Before writing anything, reject missing keys and detect duplicate keys within the input. If two source systems both use record 42, their namespace keeps them separate. A mapping table then connects source keys to WordPress post IDs. WordPress IDs are local implementation details; do not assume the same ID exists on staging and production, or that restoring selected records preserves every numeric reference.

Agree which system owns each field

A repeatable importer needs more than a matching key. It needs a contract stating which values may be overwritten. Perhaps the external catalogue owns availability and reference numbers while WordPress editors own introductions and search descriptions. Mark those responsibilities explicitly. Otherwise a routine refresh silently removes improvements made after launch. A useful import report distinguishes new records, changed source-owned fields, unchanged records and conflicts requiring a decision. Do not interpret an empty spreadsheet cell as permission to erase content unless that behaviour is agreed. Missing, empty and deliberately deleted are three different states that deserve different handling.

Normalise before you write

Clean data outside the destination database where possible. Standardise encoding, trim accidental whitespace and preserve meaningful line breaks. Treat dates with their source timezone, rather than letting a server guess. Convert boolean values through an explicit accepted-value list; the string false is not automatically a false value in every programming language. Validate allowed statuses and content types. HTML fields require an agreed sanitisation policy, particularly when the source permits scripts or embedded widgets. A preview file showing the proposed WordPress values makes review cheaper than repeatedly inspecting imported pages. Preserve the raw export separately so transformations remain reversible.

Import relationships in a controlled order

Parent pages, taxonomy terms and linked records introduce dependencies. Import foundational records first, then resolve relationships through the source-key mapping. A second pass can attach related case studies, authors or locations once all required IDs exist. Never rely on CSV row order as the sole explanation of a relationship. Define what happens when a parent is absent: reject the child, leave it pending or place it in a clearly marked fallback category. Each option has editorial consequences. Circular references should be flagged rather than repeatedly retried. The migration is easier to maintain when relationship rules live beside the import configuration.

Treat media as records too

Repeatedly downloading the same image creates attachment clutter and unnecessary processing. Match media using a trusted source identifier or a carefully defined file fingerprint. A matching filename alone is insufficient when different folders contain logo.png. Import alt text and captions separately from the filename, and retain licensing information where available. Confirm that remote files are authorised to fetch before downloading them. Size limits, permitted file types and timeouts protect the import worker. When a file fails, record that failure against its content item instead of pretending the record is complete. Missing decorative artwork can be repaired later without duplicating the whole entry.

Use bounded batches and visible checkpoints

Large imports should run in manageable batches through an established importer or a controlled command-line job. A long browser request is vulnerable to timeouts and offers poor recovery. Record the current batch, successful source keys and recoverable failures. If an interrupted run resumes, already completed records should not be duplicated. The operation also needs a clear definition of success: a post saved successfully does not guarantee that its relationships or media were attached. Separate those steps in the report. Avoid keeping one enormous database transaction open across remote downloads; it combines slow network work with long-held database resources.

Decide what disappearance means

A record missing from the next export might be deleted, temporarily filtered or accidentally omitted. Automatic deletion is therefore a dangerous default. Compare source inventories and produce a removal proposal before changing publication status. For content that really is retired, choose whether it becomes a draft, an archive entry or a deleted post, and handle its public URL according to editorial relevance. Product availability is not the same as deleting a product. Keep the decision independent of the import mechanism. A human-readable list of proposed removals usually catches business misunderstandings faster than a complicated technical dashboard.

Rehearse the second run, not just the first

A representative staging sample should include an existing record, a renamed record, a missing parent, a duplicate key and a failed image. Run the same input twice and compare the resulting counts. Then change one source-owned field and one editor-owned field to confirm the intended ownership. This focused rehearsal proves the central behaviour without spending time opening every page. Keep a backup and a record of the import configuration before production writes. Importing content should not simultaneously send customer messages or trigger unrelated workflows. Disable or isolate those side effects deliberately, using the relevant plugin's supported controls.

A migration process worth keeping

The best outcome is an import routine that remains useful after the initial move. Store its mapping rules, accepted inputs and recovery instructions where the next maintainer can find them. Link this work to the content modelling guide so that imported records have an appropriate home in WordPress. Keep presentation conversion and data transfer as separate responsibilities. Small visual differences are normal and can often be refined later through theme settings or a suitable plugin. Stable identities, explicit ownership and repeatable batches are less glamorous than a polished screenshot, but they determine whether the migrated site stays manageable.