If imported WordPress posts show the wrong author, inspect the import's author mapping before importing the file again. The destination account that owns a post can also affect its public byline and author archive. Assigning everything to an administrator is not a neutral default.
Build the mapping before another import
WordPress's import handbook describes mapping imported authors to existing users or creating users during a WordPress import. Review each source identity and choose the approved destination deliberately.
Create a small private worksheet with the source author, source login, intended destination account and desired public credit. Similar display names can belong to different users. Confirm the account identity, not just the label shown in a dropdown.
| Source content |
Destination decision |
| Current team author's posts |
Match the verified existing account |
| Former contributor's articles |
Preserve truthful credit under editorial policy |
| Shared company announcements |
Use the approved organizational identity |
| Unknown source author |
Resolve ownership before assigning or publishing |
Mapping: Source and destination verified. Sample: Draft and published post checked. Archive: Expected author archive checked. Access: No unnecessary role expansion. Explanatory checklist, not a customer test result.
Rehearse a small representative sample
Use private staging with outgoing notifications controlled. Include a published post, a draft and content with a featured image. Record their source titles and intended authors before running the import.
Afterward, inspect both the administrative author field and the rendered byline. Some editorial plugins maintain separate contributor information, so correct core ownership does not guarantee the frontend credit is correct.
Open the author archive and check where the imported article appears. Also confirm that a mapped account has only its approved role. Creating a replacement identity should not become an excuse to grant administrator access.
Repair an existing import without duplicating content
First identify the affected records using the import log, source manifest or a reliable saved list. Do not use a broad date filter alone if staff published unrelated articles during the same window.
Make a recoverable backup and test the reassignment on a small controlled group. Use the site's supported editor or reviewed migration tooling. Verify the result before expanding the change. Avoid directly rewriting every post owned by the administrator, because legitimate older content may share that owner.
Do not delete the mistakenly assigned user just to move posts. The user deletion and reassignment guide explains the additional risks to content and plugin-owned relationships. Correcting authorship rarely requires removing an account.
Check credits, archives and access separately
Confirm the expected author on representative live URLs, in the editor and on relevant archives. Check drafts too, since a mistake can remain invisible until someone publishes them later. If the frontend still shows old information, identify its cache or editorial metadata before repeating the database change.
Retain the final mapping with the migration record. It helps explain who owns content without implying that a newly assigned account wrote historical articles.
HandL WP can repair a scoped import mapping when the wrong ownership spans many records. Bring the source-to-destination worksheet and affected-content list, not a second unreviewed production import.
References reviewed October 7, 2026. Examples are explanatory, not customer test results.