AIT CSV Import-Export - WordPress Plugin

Guide to Configuring and Safely Using AIT CSV Import-Export

AIT CSV Import-Export is useful when WordPress data is easier to move in a spreadsheet than by hand: updating a list of posts, preparing a directory, moving items between sites, checking field structure before a migration, or creating a backup export for editorial work. This guide focuses on the practical workflow rather than marketing copy: how to prepare the site, build the CSV file, map columns to WordPress fields, verify the result, and avoid duplicates, empty entries, or broken characters.

The original AitThemes page for this older product is no longer available for direct verification, so this guide does not make precise claims about current versions, pricing, licensing, or undocumented settings. The practical guidance is based on confirmed AitThemes materials about CSV import for listing items, general WordPress rules, and documentation for similar CSV import tools. That is more honest than inventing an interface that cannot be verified.

The workflow remains practical: first create a site backup and run a test import, then check encoding, delimiter, unique identifier, images, taxonomies, and custom fields. Once that is confirmed, you can move to the live site and treat import/export as a controlled process rather than a one-time risky operation.

Where the Plugin Helps and What Problem It Solves

CSV import and export seem simple until the site contains more than standard posts. In practice, WordPress stores content in layers: title, body, author, status, categories, tags, custom fields, featured images, attachments, custom post types, and sometimes data created by third-party plugins. If you move everything manually, editors quickly make naming mistakes, miss terms, create duplicates, or lose the connection between a post and its images.

AIT CSV Import-Export is best viewed as a tool for spreadsheet-based data management. It does not replace a full database migration and should not be treated as your only backup. Its strong point is repeatable content operations: export data, edit it in a spreadsheet, bring it back in, add new rows, or prepare an import with a clear structure.

The most natural use cases are:

• Bulk creation of posts or directory items. A content manager prepares rows in a spreadsheet, and an administrator imports them into the correct post type.
• Editing existing data. The site exports records to CSV, the editor updates titles, descriptions, statuses, or categories, and the data is imported back using the correct identifier.
• Checking structure before a migration. Export helps you see which fields are actually in use, which are empty, and which need normalization.
• Moving data between WordPress sites. If both installs use a similar structure for post types and fields, CSV gives you a more controlled transfer than manual copying.
• Working with directories and listing sites. AitThemes specifically demonstrates the CSV workflow for Citadela Listing items: choose the CSV file, verify the delimiter, match columns to fields, assign a unique identifier, and run the import.

The main limitation is that CSV does not understand your site's business logic on its own. If the spreadsheet has no stable identifier, if a field is stored in serialized form, or if another plugin creates complex database relationships, a simple import may produce posts that look correct on the surface but are incomplete underneath. That is why this guide spends so much time on preparation, mapping, and verification rather than just the import button.

Who AIT CSV Import-Export Is a Good Fit For, and When Another Approach Is Better

A CSV Import-Export plugin can be useful to site owners, agencies, developers, and editors, but each role benefits differently. The site owner gets a fast way to update a directory or move data. The editor gets a spreadsheet that makes it easier to review titles, addresses, phone numbers, and short descriptions. The developer gets an intermediate format for agreeing on structure with the client. But that format requires discipline: the spreadsheet must be clean, the fields must be clear, and a trial run is mandatory.

When the Tool Makes Sense

Use CSV import when the data can be expressed as rows and columns. A post, page, product, directory item, user, or simple service card usually fits a spreadsheet well. It works especially well when each row has a stable key: SKU, old ID, slug, external code, user email, or another unique value.

CSV export is appropriate when you do not just need to "download the database" but want to give someone an editable subset. For example, export only published directory items, only posts in a specific category, or only the fields that need updating. In those cases, a spreadsheet lowers the risk of accidentally touching unrelated data.

When Not to Start with CSV

CSV is a poor fit for a full site migration with theme settings, menus, widgets, orders, complex metadata, and the media library. For a full move, it is usually better to use a backup, a migration plugin, or built-in hosting tools. CSV also does not solve incompatible structures: if the old site stores an address in one field and the new site requires separate fields for street, city, and coordinates, you need data normalization first.

Practical rule: if an import can change hundreds of records, run it on a site copy first, or at least test it with 5 to 10 rows. A successful file upload does not mean the fields, categories, images, and relationships were restored correctly.

What to Check Before Installation and the First Import

Preparation is not a formality. A CSV operation affects content and sometimes attachments, so mistakes can spread quickly: the wrong encoding breaks characters in every row, the wrong identifier creates duplicates, and the wrong column mapping writes an address into the description field. The larger the file, the more important the checks become.

Backup and Staging Site

Before installing anything, create a backup of both files and the database. WordPress officially recommends confirming that a backup exists before making changes, and data import clearly falls into that category. The ideal option is a staging copy of the site where you can run the import, compare the outcome, and only then repeat the process on production.

If staging is not available, reduce risk: import a small test file, create a separate category or test data type, do not enable updates to existing records on the first pass, and do not delete records missing from the file. Deleting missing rows is useful in a stable sync process, but dangerous for a first run.

Permissions, Memory, and Hosting Limits

Large file imports depend on PHP limits, upload size, execution time, and available memory. In its WordPress troubleshooting materials, AitThemes separately notes that connection issues and missing server functions can interfere with installation and updates. That matters for CSV import as well: the file has to upload, process correctly, and sometimes download images from external URLs.

Check the following:

• Whether the administrator can install plugins through Plugins and upload a ZIP file through Upload Plugin.
• Whether the host blocks outbound connections if the import needs to fetch images or a CSV file by URL.
• Whether the upload limit and execution time are sufficient for your file.
• Whether you have access to error logs if the import ends with a white screen, a server error, or a partial upload.

CSV File Structure

A CSV file needs to be predictable. The first row usually contains column headers. The delimiter should be consistent throughout the file: comma, semicolon, or tab. Text values that contain the delimiter must be properly quoted. For a Russian-language site, use UTF-8 and verify in advance that Excel, Google Sheets, or another editor did not save the file in a problematic encoding.

Create a small field map before importing:

Mini CSV Map Before Import

Column	WordPress Destination	What to Check
title	Post title	No empty rows, no duplicates if the title is used as a key.
slug	URL slug	Latin characters, uniqueness, no spaces.
category	Category or taxonomy	Consistent term names, no accidental extra spaces.
image_url	Featured image or attachment	The URL opens without authentication and does not point to a tiny placeholder image.
external_id	Unique identifier	The value is stable and not repeated across different rows.

Installation and Initial Verification in WordPress

AIT CSV Import-Export should be installed like a regular WordPress plugin. If you have a ZIP archive, open Plugins, go to Add New, choose Upload Plugin, upload the archive, and click Install Now. After installation, activate the plugin through Activate Plugin. WordPress.org documents this as the standard path for plugins installed outside the directory.

If the plugin comes as part of an older AitThemes package or alongside a theme or extensions, do not mix different archives. Upload the plugin ZIP itself, not the full package with documentation, license files, and nested folders. A common manual installation mistake is uploading an "archive inside an archive": WordPress then reports that the plugin does not contain a valid file.

First Signs the Installation Worked Properly

After activation, check three things. First, confirm that a menu item or import/export screen appeared in the admin panel. Second, check for PHP warnings at the top of the dashboard. Third, make sure the plugin screen opens normally and does not load forever. If the screen is blank, enable error logging on a test copy and inspect wp-content/debug.log.

Do not start with a large file. First create a two-row CSV: one standard post and one post with Russian text and a category. That test immediately reveals three critical things: whether the plugin sees the file, whether it reads the encoding correctly, and whether it can create a basic post.

What to Do If the Menu Item Does Not Appear

If the plugin is active but the interface is missing, check the user's role. Import and export are usually available to administrators, not editors. Then clear any admin-side cache the site may use and test for a conflict with another plugin on a site copy. With older commercial plugins, there is also the possibility that the product no longer appears on the developer's current website. In that case, the exact requirements need to be confirmed against the documentation file bundled in the archive or through the developer's support channel.

How to Prepare a CSV So the Import Does Not Create Chaos

The quality of the import is almost always determined by the quality of the spreadsheet. A plugin may provide a convenient mapping interface, but it cannot guess that in one row a category is written as "Directory," in another as " directory," and in a third as "Catalog." In WordPress, those may become different terms or trigger mapping errors.

A Consistent Column Vocabulary

Column names should make sense not only to you, but also to the person who will maintain the import later. A good set looks like this: external_id, post_title, post_content, post_excerpt, post_status, category, tags, featured_image, address, phone, website. Even if AIT CSV Import-Export lets you map arbitrary names, clear headers reduce the chance of mixing fields up.

Do not use random spaces, line breaks, or duplicate names in headers. If two columns are both called image, it becomes hard during setup to tell which controls the featured image and which controls the gallery. If a column exists only for editorial review, name it explicitly, such as editor_note, and do not map it to a WordPress field.

A Stable Unique Identifier

The most important column is the one the importer uses to decide whether it should update an existing post or create a new one. WP All Import documentation explains the same principle: the identifier must be unique for each row and must remain stable across updates. Good candidates are an external ID, SKU, old post ID, or a stable slug. Poor candidates are price, description, update date, or any field that may change over time.

If the file does not include a stable key, do not enable updates to existing posts. Create the key manually first. For a directory, it could be the item code; for a branch list, an internal branch number; for users, an email address; for content, a permanent slug. A title should be used only if you are certain it will never be edited.

Categories, Tags, and Hierarchy

Taxonomies should be standardized before import. If the site uses nested categories, decide in advance how the path will be stored: in separate columns, in a delimited string, or as ready-made terms. Do not assume the importer will correctly build a complex hierarchy from a messy spreadsheet. On the first pass, it is usually better to import terms separately or create the main categories manually first, then attach posts to the existing names.

Images and External URLs

If the CSV contains image URLs, make sure they open without authentication, are not blocked by hotlink protection, and point to an actual file rather than an HTML page. Large media libraries are often better handled in a separate stage. First import posts without images, then add images to a small sample and verify thumbnails, alt text, and file size.

Quick check before upload: open the CSV in a plain text editor, not only in a spreadsheet app. It is much easier to spot extra quotes, strange encoding, accidental line breaks inside cells, and the wrong delimiter that way.

Configuring Field Mapping After Installation

The main screen of any CSV importer is the column mapping screen. This is where the spreadsheet turns into WordPress posts. If you rush through this step, troubleshooting later becomes much harder: the post exists, but the content is in the wrong place, some fields are empty, and some values were written to the wrong meta key.

Choosing the Data Type

Start by selecting what exactly is being imported: posts, pages, directory items, a custom post type, users, or WooCommerce products. In AIT directory scenarios, choosing the correct custom post type is especially important if the site uses a listing structure. In its Citadela Listing guide, AitThemes points out that directory items are based on standard WordPress custom post types and categories, so the CSV tool needs to send rows into the correct type.

If you choose standard posts instead of a directory item type, the data may appear in the admin area but fail to show up in the templates and blocks where it belongs. So after choosing the data type, open one imported record and verify not just the title, but also where WordPress stores it.

Mapping the Core Fields

Map the core fields first: title, content, excerpt, status, slug, and publication date. For safety, keep the status conservative on the first import and use draft or an equivalent unpublished state if the plugin allows it. That gives you time to review the records before publishing. Once the structure is confirmed, you can switch the status to published through a repeat import or a WordPress bulk action.

Custom Fields and Metadata

Custom fields require caution. If a field was created by ACF, Meta Box, JetEngine, or another plugin, it may have not only a visible label but also a technical key, a storage format, and related settings. Do not guess meta keys. Check how the field is named in an existing record, or create one record manually and inspect which values the template expects.

For simple text fields, mapping is usually safe. Galleries, repeaters, coordinates, schedules, and complex blocks need a separate test. If there is no confirmed documentation for the field format, it is better to import a minimal set of values and fill the complex part through the normal interface, or use a tool that explicitly supports that field type.

Update Settings

Updates to existing posts should be as narrow as possible. If you only need to change the phone number and address, do not allow the importer to overwrite the title, content, image, and status. In a well-designed update workflow, you explicitly choose which fields are allowed to change. That protects you from cases where a CSV column is accidentally empty and the import wipes out a field that was previously filled on the site.

Custom Post Types, Taxonomies, and AitThemes Fields

The most common reason people get disappointed with CSV import is assuming all WordPress data works the same way. A standard post is much simpler than a directory item, property card, product, event, or user profile. A custom post type can have its own archive, custom taxonomies, meta fields, display templates, and blocks that read data only from specific keys. For AIT CSV Import-Export, the goal is not just to upload rows, but to land them in the correct site structure.

If the site is built on AitThemes Directory, Citadela Listing, or a similar directory-style setup, start by finding a reference record. Create one item manually through the normal interface: fill in the title, description, category, location, address, contact details, featured image, and every field that actually appears on the public listing page. Then export that record or compare its fields with the available documentation. The reference record shows which values are required, which can stay empty, and which fields should not be touched through CSV unless you fully understand the format.

Why You Cannot Guess the Custom Post Type from Its Label

In the admin panel, a custom post type may have a user-friendly label such as "Items," "Listings," "Places," or "Branches," while its technical name may be something different. If the importer asks you to choose a post type, do not select the one that looks "close enough." Choose the one that actually matches your existing records. This mistake is especially frustrating: the import completes, the records appear, but the correct directory block still does not see them because it queries a different data type.

The check is simple. After a test import, open one created record and compare its admin URL to the reference record. If the address, breadcrumbs, or admin list clearly shows a different type, stop and fix the setting. Do not try to move those records manually from one type to another after a bulk import. Get the creation right with two rows first.

Taxonomies: a Post Category Is Not Always a Directory Category

WordPress has standard categories and tags, but plugins often create their own taxonomies. A listing site may have separate "item categories," "locations," "property types," "service areas," or other vocabularies. If you map a CSV column containing city names to a standard post category, the public location filter will not start working. The data will exist, but not where the interface expects it.

Before importing, list the site's vocabularies. For each one, note its technical purpose, visible name, example value, and the rule for writing it in CSV. If terms are hierarchical, decide how to represent parent and child values. If the terms already exist on the site, use those exact names. If they must be created during import, first test with 3 or 4 values and verify that duplicates do not appear because of spaces or inconsistent capitalization.

A Simple Approach for Categories and Locations

For a directory, it is convenient to separate meaning by group: item_category for service type, item_location for city or neighborhood, and tag for freeform tags. Do not mix them all into a single category column. That kind of universal column may look convenient in the spreadsheet, but it makes filtering, export, and troubleshooting harder later.

Fields That Are Better Left Out of Bulk Updates

Not every field is suitable for repeated CSV updates. Content, phone number, address, and short description can usually be updated safely. Fields that create relationships, galleries, map coordinates, schedule sets, subscriptions, or payment statuses require more caution. If the format is complex, CSV may write a string the template cannot parse. On the surface this looks like "the plugin does not work," when the real issue is that the data was written in an unexpected format.

A safe approach is to split fields into three groups:

• Green zone. Title, excerpt, plain text, phone number, address, external URL, standard status, simple categories.
• Yellow zone. Images, coordinates, SEO fields, and custom meta fields that have already been verified on a reference record.
• Red zone. Serialized fields, repeaters, galleries with internal IDs, payment data, plugin system fields, and anything whose format has not been confirmed.

For the first production operation, keep only the green zone and perhaps 1 or 2 fields from the yellow zone. Leave the red zone alone until you have confirmed documentation or a dedicated test environment with a rollback path.

How to Verify That Blocks and Templates Read the Imported Data

After the import, do not open only the record page itself. Check every place where that record is supposed to appear: the directory archive, related items block, search, location filter, map, category widget, and internal WordPress search. If the record is visible in the admin area but not in a filter, the problem is almost always the taxonomy, publication status, cache, or a meta field used by the template as a display condition.

It helps to keep a small verification matrix. Put 5 test records in the rows and columns such as "admin," "public card," "archive," "search," "filter," "image," and "export after import." That takes ten minutes, but it shows very quickly where the process breaks down. If one record passes every check and another does not, compare their CSV rows. If all records fail in the same part of the interface, look for an error in the mapping or site configuration.

Repeat Updates: How Not to Overwrite Working Content

A one-time import of new records is easier than regular updates. A repeat import has to do more than create missing rows. It must also correctly recognize existing ones, update only the fields you allow, leave manual editor changes alone, and avoid deleting data because of an empty cell. This is exactly where the unique identifier, export, and limited update settings become critical.

Separate "Create" and "Update"

If the file contains both new and existing rows, you do not have to process them in one run. For the first implementation, it is easier to split the CSV into two files: new records and updates. New records can be imported with a wider set of fields because those records are still empty. Updates should be run separately and allowed to change only the columns that truly need editing.

For example, an editor prepares 300 branch records: 40 new and 260 existing ones with updated phone numbers. The import for new rows can create the title, address, city, category, phone, description, and draft status. The import for existing rows should change only the phone and address. If you combine everything in one run and let the importer overwrite descriptions, an accidentally empty column may erase content that was already reviewed.

An Empty Cell Does Not Always Mean "Clear the Field"

In a spreadsheet, an empty value can mean different things. The editor may not know the value, may want to leave the field unchanged, may intend to clear an old value, or may have deleted the content by mistake. For an import, those are different actions, but CSV by itself cannot distinguish them. Agree on the rule in advance: in an update file, does an empty cell mean "do not change" or "clear the field"? If the plugin lets you choose how empty values are handled, use that setting deliberately. If it does not, prepare separate files for field clearing.

A good practice is to omit columns from the update CSV if they are not supposed to change. If you only need to update phone numbers, the file should contain just the key and the phone number. Fewer columns means less risk.

Control Export Before and After

Before a repeat import, export the current records using the same keys and fields you intend to modify. After the import, run a second export and compare the two. Even without special tools, you can see what changed: row count, empty values, duplicate keys, new terms, or unexpectedly changed statuses. That turns the import from a "click and hope" action into a verifiable operation.

If an editor made the changes, have them edit a copy of the exported file rather than rebuilding the spreadsheet from memory. The original export already contains the correct keys, slug, and technical values. That reduces the chance that the same record gets a new identifier and turns into a duplicate.

What to Do with Deleted Rows

Regular synchronization raises an obvious question: if a row is no longer present in the CSV, should the corresponding record be deleted from the site? At the first stage, the answer is almost always no. First mark those records with a special status, category, or meta field. For example, if a supplier no longer sends a branch record, mark it as "needs review" instead of deleting it. Enable deletion only after the process is stable and you are confident that a missing row truly means the item should be removed.

Safe update model: key plus one or two editable fields, test on a copy, then export after import. The broader the update permissions, the stronger the verification needs to be.

Images, Attachments, and the Public-Facing Result

Images often create more problems than text fields. In a CSV, they look simple: one column with a URL or file name. In WordPress, that implies the media library, file upload, thumbnail generation, attachment-to-post relationships, featured image assignment, and sometimes alt text. If any step fails, the post is created but the site card ends up empty or visually broken.

URLs That Can Actually Be Imported

A suitable URL points directly to an image, opens without authentication, and does not require cookies. It should not lead to a preview page, a protected CDN viewer, a temporary account link, or a small preview image. If a link only opens in an administrator's browser session, the importer running on the server may get an access error.

Before importing, take 3 URLs from the beginning, middle, and end of the file. Open them in a private window. Then verify that the URL ends with a recognizable extension or returns the correct file type. This is not a guarantee, but it is a fast filter for the most common problems.

Files with Identical Names

If many images are named image.jpg, photo.jpg, or 1.png, the media library may create renamed copies. That is not always bad, but it makes verification harder. It is better to normalize file names ahead of time with a clear pattern such as branch-001-main.jpg, branch-002-main.jpg, or service-cleaning-01.jpg. For a directory, it is especially useful to reuse the same external ID that appears in the CSV. That way the link between the row and the image is clear without opening WordPress.

Alt Text and SEO

If the plugin supports importing alt text, prepare a separate column for it. Do not mechanically copy the post title into every image. Alt text should briefly describe what is in the image. For a branch office, that might be the office name or building exterior; for a service, the result of the work; for a product, the model and a key characteristic. If your scenario does not support importing alt text, fill it in later through the media library or a separate tool.

Do not tell yourself, "we'll fix it later." In large directories, images without alt text tend to stay that way for a long time. It is better to import fewer fields but prepare the ones that truly matter for the public-facing result.

Checking Thumbnails and Image Sizes

After a test import, open the media library, the post card, and the archive. The image may exist in the media library but not be assigned as the featured image. It may be assigned as the featured image, but the template may read a different field. It may be too small for the card and look blurry. So verify three layers: the file uploaded, the file is attached to the record, and the file displays where the user will actually see it.

If image import is slow, do not expand the file to thousands of rows. Split the process into stages. Import the content without media first, then update images in batches. That makes it easier to see where a failure occurred and prevents you from rerunning the entire import because of one unavailable image server.

Team Workflow: Who Prepares the File, Who Runs the Import, and Who Signs Off

CSV import rarely breaks because of a single button. More often, the problem appears between people: one team member changes the spreadsheet structure, another does not know a column was renamed, a third runs the import using an outdated template, and the site owner sees incomplete cards on the public site. If AIT CSV Import-Export is going to be a real working tool rather than a one-off experiment, define a simple process up front.

The Data Editor's Role

The editor is responsible for the spreadsheet content, not for the import settings. They should be given not an empty file but a template with examples. That template should include column headers, 2 or 3 completed sample rows, rules for required fields, a list of allowed statuses, and notes about which columns must not be changed. If the editor needs to add a new column, they should not do it silently. It should be approved with the administrator who will configure the mapping.

Three rules are especially important for the editor. First, do not change external_id if the record already exists. Second, do not delete a column just because it looks empty until you know whether the import uses it. Third, do not combine multiple meanings in one cell. For example, address, city, and phone number should be separate. The clearer the spreadsheet, the easier the result is to verify.

The WordPress Administrator's Role

The administrator is responsible for installing the plugin, creating the backup, providing the staging site, configuring field mapping, and running the first import. They should not "fix" content by eye directly in the CSV before launch if doing so changes the meaning of the data. Their job is to verify the structure: delimiter, encoding, unique key, post type, taxonomies, fields, update mode, and permissions for changing existing records.

The administrator should also keep a run log. This can be a simple spreadsheet or a note in the task system. The log only needs a few details: file name, row count, import mode, which fields were updated, where the test was run, who verified the result, and which errors were found. A month later, when you need to understand why phone numbers changed on only part of the records, that log saves hours.

The Reviewer's Role

The reviewer should not be the same person who prepared the CSV. They need a list of control records: a few new ones, a few updated ones, one record with an image, one record with Russian text, and one with both a category and a location. The reviewer checks the admin area, the public card, the archive, search, and the export after import. Their job is to confirm not just that the data loaded, but that it actually works in the site interface.

For large directories, spot checking is useful. You cannot manually open a thousand records, but you can review 20 rows from different parts of the file: beginning, middle, end, rows with empty optional values, rows with long descriptions, and rows with images. If errors appear only in one specific group, the problem is usually in the format of those rows, not in the entire import.

File Naming and Versioning

Do not name files import.csv, new.csv, or final-final.csv. Use a clear scheme instead: branches-update-phone-address-v01.csv, catalog-new-items-test.csv, items-export-before-update.csv. The file name should tell you exactly what it does: create new records, update phone numbers, test images, or preserve the export taken before a change.

Keep the original export before edits in a separate place. Do not overwrite it. If an update goes wrong, that file is what will help you understand what the old values were. For a working team, that is far easier than hunting down an old database backup and restoring an entire site just to recover a few fields.

Sharing the File Without Breaking the Format

CSV files are easy to damage during editing and handoff. Spreadsheet editors can change the encoding, remove leading zeros, convert a long numeric ID into scientific notation, or switch the delimiter. If your table contains SKUs, IDs, ZIP codes, and phone numbers, store those columns as text. After export from the editor, open the CSV in a text editor and verify that the values survived intact.

If the team works in Google Sheets, you can keep the master spreadsheet there, but before importing you should still download the CSV and inspect it as a file. Do not import directly from a spreadsheet that people continue editing unless you are certain no one will change the data mid-process. For a production run, freeze a specific CSV version.

How to Accept the Result

Sign-off should be formal but short. After the import, the reviewer answers a few questions: how many rows were in the CSV, how many records were created or updated, whether any key duplicates appeared, whether Cyrillic characters display correctly, whether required fields are filled, whether the records are visible on the site, whether the reverse export passed, and whether the run needs to be repeated. If even one answer is unclear, the import is not complete.

A process does not make the work harder. It protects you from quiet errors: an accidentally renamed column, the wrong key, an empty field in an update file, or a large import run without anyone clearly responsible for the outcome.

Export as a Tool for Control, Backup Extraction, and Editorial Work

Export is often treated as a secondary feature, but in a CSV workflow it matters just as much as import. A good export shows what the site actually stores after the import. It helps you compare the source spreadsheet with the outcome, find empty fields, verify categories, and prepare safe bulk edits.

Which Fields to Export

Do not export everything if the task is narrow. For editorial updates to descriptions, ID, title, slug, status, category, and content are enough. For a directory check, you need address, phone, website, category, coordinates, image, and external ID. For a publication audit, add date, author, and status. The fewer unnecessary columns you include, the lower the risk of accidentally editing a field that should not change.

How to Use Export Before a Repeat Import

A safe cycle looks like this:

1. Export the current records with the unique identifier and only the fields you need.
2. Save the original export separately as a rollback point.
3. Create a copy for editing and change only the necessary columns.
4. Import the copy into the staging site using an update mode limited to the selected fields.
5. Compare several records in the admin area and on the public site.
6. Repeat the import on the live site only after verification.

This cycle is especially useful for content directories where an editor needs to update hundreds of descriptions, addresses, or statuses. It also makes it much easier to undo a bad edit: if you kept the previous export, you can restore part of the fields through a reverse import.

Practical Example: Updating a Branch Directory via CSV

Consider a concrete scenario. The site has a branch directory with a title, city, address, phone number, link to the branch page, category, and featured image. You need to add new branches and update phone numbers on existing ones without touching descriptions or images where those are already filled in.

Goal

Run a controlled import: new rows create new directory items, existing rows update only the phone number and address, no duplicates appear, and records either stay in draft first or are reviewed on a staging copy before publication.

Preparation

First export the existing directory items with the columns external_id, post_title, slug, city, address, phone, category, post_status. If there is no external ID yet, create it before you start. Do not use the phone number as the key, because that is the field you are about to change.

Then prepare the CSV:

• For existing branches, keep the same external_id.
• For new branches, assign new unique values.
• Normalize categories to existing names such as Office, Pickup Point, and Partner.
• Leave fields empty only where you are certain the corresponding field will not be updated.
• Save the file as UTF-8 and verify the Russian characters in a text editor.

Import Steps

1. Open the AIT CSV Import-Export screen and upload the file.
2. Verify that the delimiter is detected correctly and that rows in the preview have not shifted across columns.
3. Select the correct post type for the directory or listing items.
4. Map post_title to the title, slug to the URL slug, category to the taxonomy, and city, address, and phone to the corresponding fields.
5. Use external_id as the unique identifier.
6. In update mode, allow changes only to city, address, and phone. Keep all other fields protected.
7. Run the import first on a test file with 5 to 10 rows.

Verifying the Result

After the import, open the item list in the admin area and check how many new records were created. Then open two existing records and confirm that only the phone number and address changed. After that, open the public directory page: the category filter should find the new items, the card should show the correct city, and the branch link should point to the correct URL.

A Common Gotcha

If duplicates appear after a repeat import, the issue is almost always the key. The external_id value may differ because of a space, different capitalization, a prefix, or an empty string. Fix the key in the spreadsheet, delete the test duplicates on the site copy, and rerun the import. Do not try to treat duplicates by changing titles. That hides the symptom, but it does not fix the cause.

Checking the Result After Import and Export

You need to verify more than just the success message. An import can finish without an obvious error and still create posts with the wrong status, fail to connect categories, skip images, or update the wrong fields. That is why every meaningful run should be followed by a multi-level review.

Checking in the Admin Panel

Open the list of imported records and filter by date, category, author, or status. Review several rows from the beginning, middle, and end of the file. If the import created 500 records, do not stop after checking the first one. Partial errors often appear after a row containing a line break, quotes, an empty category, or an unusual character.

Checking the Public Site

Open the pages the way a visitor would see them. For a directory, check the list, the card, the filter, search, map, and links. For standard posts, check the category archive, the post page, the featured image, and metadata. If the site uses caching, clear it after the test import, but do not enable aggressive optimization before you finish verification.

Checking with a Reverse Export

Export the records you just imported and compare that file with the original CSV. This is the fastest way to see which fields did not save, where term names changed, and where values were cleared. If the export shows an empty column, first confirm that you did not map it incorrectly, and only then start looking for a problem in the site template.

A good import result looks like this: the number of records matches expectations, keys are unique, Russian characters display correctly, categories are attached, images are visible, the public card shows the updated data, and the repeat export confirms the values.

Limitations and Risky Modes You Should Know About Up Front

CSV operations are convenient, but they should not turn into a "manual database." WordPress and plugins may store data in ways that are more complex than a spreadsheet suggests. If you ignore those limitations, the import may look successful on the first screen while problems surface later in filters, templates, search, maps, orders, or SEO fields.

Complex Custom Fields

A plain text field usually imports predictably. Repeaters, galleries, relationship fields, coordinates, schedules, and serialized values require knowledge of the exact format. If the format is not confirmed by product documentation or a sample record, do not bulk-import that data. Create one reference record manually, export it, and see how the field appears in the output.

Deleting Missing Records

Some tools can delete records that do not appear in the new file. This is convenient for synchronizing a directory, but risky during a one-time import. If the file was incomplete, you will delete working records. Enable that mode only after you have a stable unique identifier, have tested the import on a copy, and have saved a backup export.

Media and External Sources

Image import depends on more than the plugin. The external server may block requests, return tiny versions, require authentication, or change the URL. If images are critical, first upload 3 to 5 test files and check the media library. For large media collections, it is better to plan a separate work window because file transfer can take longer than creating the records themselves.

Performance and Cache

A large import puts load on the database, file system, and PHP process. Do not run multiple bulk imports at the same time. On a live site, choose a low-traffic period, temporarily disable unnecessary heavy jobs, and confirm the hosting limits in advance. After the import, clear the cache, but do not use caching as a way to "fix" incomplete data.

Why CSV Import Can Misbehave and How to Diagnose It

Troubleshooting should move from simple to complex: file, delimiter, encoding, identifier, mapping, permissions, server limits, and conflicts with other plugins. Do not change multiple settings at once, or you will not know what actually helped.

The File Uploaded, but the Columns Shifted

Symptom: in the preview, part of the text lands in neighboring columns, headers do not line up, and rows look broken.

Cause: wrong delimiter, unescaped quotes, line breaks inside a cell, or the file was not truly saved as CSV. Check the source file in a text editor and export the spreadsheet again with an explicit CSV UTF-8 setting. If your regional Excel settings use a semicolon, make sure the importer is set to use it too.

Russian Characters Display Incorrectly

Symptom: instead of Cyrillic characters, you see garbled symbols, question marks, or truncated words.

Cause: the file was not saved as UTF-8, or it was reopened and resaved by an editor that changed the encoding. Export the CSV again, inspect it in an editor where you can choose the encoding, and run the import on two rows. If the issue remains, check the database encoding and site settings, but rule out the file first.

Duplicates Are Created Instead of Updates

Symptom: a repeat import adds new records even though it should update existing ones.

Cause: the unique identifier does not match the previous run, is empty in some rows, or was chosen from a field that changes. Check the key column, trim spaces, and compare its values with an export of the current records. If the wrong key was used in the first run, it is safer to roll back on a site copy and repeat the process than to manually clean up hundreds of duplicates.

The Import Skips Some Rows

Symptom: the file contains more rows than the number of created records, but the error message is unclear.

Cause: an empty required title, a duplicate key, a server limit, or an error in a row after a specific point. Split the file into parts and find the range where the failure starts. Check the import log if the plugin provides one, and inspect the WordPress log on the staging copy.

Images Were Not Attached

Symptom: records were created, but featured images are empty or the media library did not receive new files.

Cause: the URLs are unavailable, the server blocks downloads, the files are too large, the link points to an HTML page, or the importer did not map the image field correctly. Open the CSV URL in a private window, check the extension and MIME type, then import a single row with one image. If the source server blocks downloads, upload the images to the media library separately or use an accessible source.

After Import, the Page Looks Correct in Admin but Not on the Site

Symptom: the values are visible in the record, but the template, directory block, or filter does not show them.

Cause: the data was written to the wrong post type, the wrong meta key, the wrong taxonomy, or the cache is serving an old page. Check the reference record created manually and compare its fields with the imported one. Then clear the cache and refresh permalinks if the issue seems related to URLs.

Safe Workflow Improvements Without Editing the Plugin

With AIT CSV Import-Export, it is a mistake to invent hooks or internal APIs unless the documentation confirms them. It is much safer to improve the process around the import: a CSV template, a verification checklist, a test category, a change log, and visual labeling for test records. That gives you practical value without editing WordPress core, the plugin, or the theme.

A Team CSV Template

Create a reference CSV file with a header row and 2 or 3 examples. Add a separate document next to it with clear notes: which fields are required, which values are allowed, where to get the unique ID, how to write categories, and which columns must not be changed. For editors, that is much clearer than re-explaining the import settings in the admin area every time.

A Test Label for New Records

For the first run, add an import_batch column or a separate category called "CSV Review." If the plugin allows you to map it to a meta field or category, you will be able to quickly filter the imported records. After review, the label can be removed with a repeat import or a bulk action.

A Small CSS Tweak for Visually Checking Test Cards

If test records appear on a public page, you can temporarily highlight them through a category class or a theme status element. Do not edit the plugin file. Add the CSS through Appearance -> Customize -> Additional CSS or through a child theme if the theme supports that workflow.

.category-csv-test .entry-title::before {
  content: "CSV TEST";
  display: inline-block;
  margin-right: 8px;
  padding: 2px 6px;
  font-size: 12px;
  line-height: 1.4;
  color: #fff;
  background: #cc4a2f;
  border-radius: 3px;
}

The check is simple: open the test category archive and confirm that the marker appears next to the titles. Once the test is complete, remove the CSS and the test category, or unassign that category from the records. This approach does not depend on internal AIT CSV Import-Export functions and is easy to roll back.

Questions to Resolve Before a Production Run

Can AIT CSV Import-Export be used as a full site migration tool?

No. That expectation is risky. CSV works well for tabular data, but it is not a full copy of the database, files, theme settings, menus, widgets, and complex relationships. For a complete migration, use a backup or a dedicated migration tool, and reserve CSV for controlled content sets.

Which identifier should I use to update records?

Choose a value that is unique and stable: an external ID, SKU, old ID, user email, or a consistent slug. Do not choose price, description, phone number, date, or title if those fields can be edited. If there is no stable key yet, add it to the spreadsheet first.

Why is it better to start with drafts?

Draft status gives you time to review a record before publishing it. If the import immediately publishes hundreds of rows, visitors and search engines may see incomplete cards, missing images, or incorrect categories. After verification, the status can be updated in a separate import or through a bulk action.

Can images be imported by URL?

Usually CSV tools support that workflow, but the result depends on the specific plugin and whether the URL is accessible. Test a single file first: the link should open without authentication, point to a real image, and not be blocked by the source server. If there are many images, move them in a separate stage.

What should I do if documentation for the old AIT CSV Import-Export is unavailable?

Do not guess the settings. Use archived documentation included with the plugin package, the developer's support, or safe WordPress logic: a staging site, a small file, export after import, and log review. Unconfirmed features should not be part of the production workflow.

Do I need to disable cache before importing?

Cache may not interfere with the import itself, but it can hide the result on the public site. After the import, clear the cache and check the page in a private window. If the problem appears only on the site while the admin data looks correct, cache is one of the first things to investigate.

Can I run the import on the live site without a copy?

Technically yes, but it is bad practice for large files. At minimum, have a backup and a test import on a few rows. For bulk updates to existing records, a staging copy should be standard procedure, not a luxury.

When AIT CSV Import-Export Is a Good Choice

AIT CSV Import-Export makes sense if you need spreadsheet-level control over WordPress content and are willing to work carefully: prepare the CSV, choose a stable key, verify field mapping, run a test import, and compare the result through export. This approach works especially well for directories, branch lists, collections of standard posts, simple custom post types, and repeatable editorial updates.

If the task is broader, such as a full site migration, complex fields, WooCommerce variations, regular synchronizations, or integrations with external services, compare AIT CSV Import-Export with more specialized solutions. Even then, the principles in this guide stay the same: backup, test file, unique identifier, limited field updates, public-site verification, and reverse export.

Once the preparation is complete and you understand exactly which data you will move, you can download the installation file and test it on a site copy. Do not begin with the entire live directory. Start with a short cycle: two rows, one post type, one key, one review. If that cycle is stable, scaling up becomes much calmer.