Import WordPress SEO Metadata Without Losing Values

Adding SEO metadata to a WordPress CSV importer means respecting how the SEO plugin stores and interprets each field. A missing column may mean leave the current value alone, while a present blank may mean clear it. Schema fields can also contain template variables or escaped text that should not be decoded and rewritten casually. While adding Rank Math support to a CSV workflow, I put the supported fields and their rules in one shared registry. That let the exporter, importer, interface, and tests use the same names and made a complete export-and-import comparison possible.

Share one field definition between import and export

Import and export had grown separate knowledge of columns. That is how round trips drift: the exporter emits one name, the importer expects another, and documentation describes a third. I introduced a field registry that defines supported columns, storage keys, aliases, normalization, and feature availability in one place.

The registry let reviewers compare the supported fields and made it easier to detect a field present in only the importer or exporter.

Distinguish missing, blank, and false values

A missing CSV column means “this file has no opinion.” A present blank can mean “clear the stored value.” A false-like value may disable a feature. Treating all three as empty either preserves data the operator wanted removed or erases data the file never intended to touch.

I made presence explicit before normalization. That rule is now one of my first checks in any bulk update system, because spreadsheets naturally collapse distinctions that applications depend on.

Resolve aliases and report conflicting columns

Existing exports and hand-built files used different headings for similar SEO concepts. I accepted documented alternative column names and mapped them to one internal field. If two aliases appeared with conflicting values, the importer reported the conflict rather than selecting whichever column happened to be processed last.

Documented aliases support older files while conflict checks prevent unpredictable updates.

Preserve schema text unless conversion is required

SEO fields can contain JSON, templates, variables, or strings that resemble structured data without being standalone JSON documents. An eager decoder can change escaping or reorder data. I preserved raw values unless the documented field rule explicitly required a conversion and tested export-import round trips with quotes, newlines, backslashes, and template tokens.

column absent   => leave existing value alone
column blank    => apply the documented clear behavior
column present  => validate and store through its field rule

That tiny decision table prevented a surprising amount of accidental data loss.

Explain unavailable integrations and skipped fields

The CSV tool should not pretend every integration is active. I surfaced supported SEO columns when the relevant plugin integration was available and kept the base importer usable when it was not. Files containing unknown integration columns produce actionable warnings instead of fatal errors.

This matters on migrations where the source and destination are intentionally different. The operator should be told what was skipped and why.

Protect spreadsheet exports and metadata updates

Exports may be opened in software that interprets values beginning with formula characters. Imports can touch protected metadata at scale. I kept capability and nonce checks around the operation, applied formula-injection handling to output, and avoided allowing an arbitrary meta-key column to bypass the supported registry.

Compare a full export-and-import round trip

I built fixtures containing ordinary values, blanks, aliases, multiline text, schema fragments, and disabled integration states. The strongest assertion was not that each side ran. It was that exporting known WordPress state and importing the result reproduced the intended field values without unrelated changes.

Redirects were a useful example of why field-by-field policy matters. A destination URL, redirect type, and activation flag form one concept; importing only one column can leave a contradictory combination. The registry can validate related fields together and report that the row is incomplete instead of saving a half-configured redirect. Related settings still need to be validated together when they arrive in separate CSV columns.

I also separated portability from completeness. Some plugin state is derived, indexed, or better rebuilt by the destination plugin after import. Exporting every internal key would couple the tool to implementation details and increase the chance of carrying stale caches. The supported set favors editorial inputs and documented integration points. After import, the integration’s own rebuild or reindex path remains authoritative for derived data.

The admin copy names the integration and version assumptions rather than presenting the extra columns as universal WordPress fields. That small language choice prevents operators from expecting the same behavior on a destination with a different SEO stack and makes migration planning more honest.

Document what each integration supports

Before adding an SEO field, document its storage key, accepted column names, empty-value behavior, and any related fields it depends on. Test ordinary values, blanks, conflicting aliases, and schema text with quotes and backslashes. Export known WordPress data and import it into a disposable site, then compare the supported values. Explain which fields were skipped and why. Keep derived indexes and caches under the SEO plugin’s own rebuild process rather than treating every internal key as portable editorial data.

Photo by ThisIsEngineering on Pexels.