Should Blank CSV Cells Erase Existing WordPress Content?

Define the decisions before reviewing cells

Use these four labels in your change sheet. They are editorial decisions, not universal importer syntax:

• Keep: preserve the current saved value because no change is approved.
• Set: replace the current value with a specific approved value.
• Clear: remove the field value without deleting the directory entry.
• Hold: leave the field untouched while its accuracy or intended change remains unresolved.

Keep and hold both leave content unchanged for this batch. Keep is an approved decision; hold requires follow-up.

An unresolved field change calls for a hold on that field. A missing, unmatched or duplicated record identifier is different: exclude the entire record until its identity is resolved.

A missing column also differs from a blank cell. No opening-hours column means the file supplies no opening-hours values. An existing column with an empty cell supplies a blank whose meaning still needs establishing.

Neither has a universal effect across importers. Even a policy that omitted fields should stay unchanged must be verified against the configured import process.

Work through one directory correction

This example is entirely hypothetical. A contributor sends corrections for Riverside Workshop. The editor verifies that identifier directory-042 matches exactly one record in a current export of saved field values. The venue name is only a readable label, not the matching identifier.

The editor preserves the original CSV and reviews each field separately.

Public email: keep

• Saved value: visits@example.org
• Incoming cell: blank
• Source-owner instruction: “We did not supply an email correction. The published address is still correct.”
• Approved action: keep visits@example.org unchanged.

Here, the blank means no correction was supplied. Automatically clearing the field would contradict the instruction.

Opening hours: set

• Saved value: “Tuesday–Thursday, 10am–4pm.”
• Incoming cell: “Tuesday–Friday, 10am–4pm.”
• Source-owner instruction: “These are the approved current hours.”
• Approved action: set the field to “Tuesday–Friday, 10am–4pm.”

A populated cell still needs review. Its presence alone does not establish accuracy or approval.

Access note: hold

• Saved value: “Use the courtyard entrance.”
• Incoming cell: blank
• Source-owner instruction: none supplied.
• Review action: hold this field and request clarification.

Leaving the note untouched does not confirm its accuracy. Assign someone to ask whether it should remain, change or disappear, with a follow-up date.

The file also lacks a description column. In this example, the owner confirms that descriptions are outside the correction request, so the editor records keep for that field.

Turn the review into a precise developer handoff

The remaining correction concerns a booking note. The entry below shows the fuller handoff format to use for each reviewed field. All details, including the field key and approval, belong to the hypothetical example.

Booking note: clear

• Verified record identifier: directory-042, matched to exactly one saved record.
• Developer-confirmed destination field: booking_note.
• Saved value: “Book at least one day ahead.”
• Incoming value or column status: column present; cell blank.
• Action: clear.
• Expected saved result: no booking-note value, while retaining the directory entry.
• Source instruction: contributor says, “Advance booking is no longer required. Remove this note.”
• Approval and date: directory editor, 6 May 2026.

For a set action, include the complete replacement value in the expected result. For a hold, add a follow-up owner and due date; the expected result for this batch is the unchanged saved value.

The booking-note blank looks identical to the email blank, but the approved outcomes differ. Ignoring every blank would preserve the email correctly while retaining an unwanted booking instruction.

Keep source instructions separate from reviewer decisions. Agree on a written policy alongside the change sheet:

• Omitted columns mean no approved change unless separately instructed.
• Unexplained blanks go on hold.
• Populated cells are proposed replacements, subject to review.
• Deletions require explicit, field-specific instructions and approval.

These are review rules, not executable commands. Writing “hold” does not prevent an importer from changing a field. Likewise, do not insert “clear” or a guessed deletion token such as NULL and assume it will remove content.

Verify execution before updating live content

Ask the developer to check the actual importer’s documentation and configuration for record matching, field mapping, missing columns and empty values. Establish how each approved action—and each exclusion—will be implemented.

If the process cannot exclude a held field independently, hold the entire record, including its otherwise approved changes. If it cannot distinguish preservation from deletion, exclude the affected changes from the batch and handle approved changes through separately reviewed manual edits. If safe exclusion is not possible, do not run that batch.

Use this pre-live checklist with the developer:

A staging result applies to the tested configuration and sample; it does not establish that every record will behave identically. Preserve the pre-update state and confirm a usable recovery path before proceeding.

After the live run, compare actual saved values with approved outcomes. Kept and held fields should remain untouched, replacements should match, and approved deletions should take effect. A completion message alone does not establish this.

Start with the first ambiguous blank: create its field entry and ask the source owner whether to preserve, replace or remove the saved value.