How to Move a Document Archive Onto WordPress Without Six Weeks of Copy-Paste

There is a shared drive somewhere with four hundred Word documents in it. Course notes. Case studies. Research papers. Standard operating procedures. Client deliverables going back nine years.

Somebody has decided all of it should be on the website. That somebody is probably not the person who has to do it.

This guide is for the person who has to do it.

It is not a tool tutorial. It is the project plan around the tool, because the tool is the easy part. Most archive migrations go wrong in the decisions made before anything gets uploaded.

First, do not migrate all of it

The instinct is to move everything. Resist it.

Open a spreadsheet and list every document with four columns: filename, last modified date, is it still accurate, and does anyone actually need it.

You will find three groups.

Still useful. Migrate these.

Out of date but historically important. Migrate these, but plan to mark them clearly. A 2017 policy document published with no date context will confuse people and will rank in search for a query it should not answer.

Dead. Superseded, duplicated, drafts, or things nobody has opened since 2019. Do not migrate these. Every one you move is a page you have to maintain forever.

In most archives, somewhere between a quarter and a half of the files fall into the third group. Cutting them is the biggest time saving available and it happens before you touch WordPress.

Second, decide where the content lives

Do not default to Posts. Posts are a blog. An archive is usually not a blog.

Ask what the content is:

• A knowledge base or documentation set wants a custom post type with its own taxonomy. Users will browse and search it, not read it in date order.
• Course material wants a custom post type per course, or a hierarchy under Pages.
• Research papers and case studies want a custom post type so you can add fields for author, year, department and topic.
• Genuinely dated content, like newsletters or press releases, is fine as Posts.

Get this wrong and you find out three hundred posts later, when someone asks for the archive filtered by department and there is no field to filter on.

Decide the post type, the taxonomies and any custom fields before you import a single file.

Third, fix your filenames

This is the most boring step and the one that saves the most time.

Whatever you use to import, filenames become the raw material for URLs, titles and image matching. Getting them right up front removes hours of manual correction later.

Rename everything to a single pattern before importing. Something like:

2024-hr-remote-work-policy.docx
2024-hr-expenses-policy.docx
2023-legal-data-retention.docx

Lowercase, hyphens, no spaces, no brackets, no version suffixes like _FINAL_v3_REVISED.

If your importer can match an image to a document by filename, this is what makes that work. 2024-hr-remote-work-policy.jpg sitting beside 2024-hr-remote-work-policy.docx becomes that post's featured image automatically. Four hundred documents means four hundred featured images you did not have to set by hand.

Do the renaming in bulk. On Windows use PowerRename from PowerToys. On Mac select all the files, right click, and choose Rename. Ten minutes for the whole set.

Fourth, fix the source documents

Import tools read structure. If the structure is not there, it cannot be imported.

Three checks, and you can do them fast across many files:

Heading styles. Open a document and press the Navigation Pane in Word's View tab. If the outline appears, headings are real. If it is empty, the headings are just big bold text and they will import as plain paragraphs.

In an old archive, expect maybe half the documents to have this problem. Word's Styles pane can fix a document in under a minute once you know what you are looking at.

Lists. Click into a bullet. If the list button is highlighted, it is a real list. If not, someone typed a dash.

Table headers. Click in a table, go to Table Design, tick Header Row.

You do not need to do this to all four hundred at once. Sample twenty documents. If most are fine, import and fix the exceptions afterwards. If most are broken, budget the time now rather than discovering it at document ninety.

There is more detail on preparing documents in the step by step import guide.

Fifth, import in batches, not all at once

Do not run four hundred documents in one go.

Run twenty. Then stop and look at the result properly.

Check the same six things on every batch:

1. Heading levels nest correctly
2. Nested lists did not flatten
3. Table headers survived
4. Images landed in the right place with alt text
5. Special characters, curly quotes and accents render properly
6. The code view has no leftover styling you did not put there

Twenty is the right size because it is enough to reveal a systematic problem and small enough to redo without pain. If something is wrong at document five, it is wrong at document three hundred and five, and you want to know now.

Once two consecutive batches come back clean, increase the batch size.

Whatever tool you use, make sure it can reverse an entire run in one action. In a migration this size, something will be wrong. Undoing eighty posts by hand is a bad afternoon.

The mechanics of running a batch are covered in the bulk import walkthrough.

Sixth, do not publish it all on the same day

This is where most archive migrations quietly damage themselves.

Four hundred posts appearing with the same publish timestamp is a bad signal in three separate ways.

For readers. Your archive listing shows four hundred items all dated today. Nobody can tell what is new. The "recent" section is meaningless. Anyone subscribed to your feed gets four hundred items at once.

For search. A site that published nine posts last year and four hundred today looks unusual. It is not automatically penalised, but it gives a crawler no reason to treat any single item as important, and your crawl budget gets spread thin across four hundred pages that all appeared from nowhere.

For your own sanity. If something is wrong with the template, it is wrong on four hundred live pages at once.

Spread them out instead. Drip publishing gives every imported document its own publish date on a schedule you set. Two posts per weekday for the whole batch. Or, if the content genuinely has original dates, set each post's date to when the document was actually written. For an archive of dated material, that is the honest option and it makes the archive genuinely browsable by year.

The bulk scheduling guide covers how to set an interval and skip weekends.

Seventh, handle SEO at scale, not per post

Writing four hundred meta descriptions by hand is not going to happen. You will write forty good ones and then start pasting the same thing.

Use templates instead. Most importers that write to Yoast or Rank Math let you build the SEO title and meta description from placeholders, something like {title} | {sitename} for the title and the document excerpt for the description.

Templates get you to good enough on all four hundred. Then override by hand on the twenty pages that actually matter, which you already know from your spreadsheet.

One thing templates cannot fix: if two hundred documents in your archive cover similar ground, you now have two hundred pages competing with each other for the same queries. That is a content problem, not an import problem. Solve it by consolidating during the audit in step one, not after publishing.

Eighth, deal with the old links

Documents in an archive link to each other. Those links point at file paths on a shared drive. On the web they are dead.

After importing, run a search for .docx, .pdf, file:// and any internal server path in your post content. Repoint each one at the WordPress URL of the migrated version.

If the old documents were publicly downloadable at real URLs, set up 301 redirects from the old file URLs to the new posts. Otherwise every link anyone has ever shared or bookmarked breaks on migration day.

A realistic timeline

For four hundred documents, with reasonably consistent source files:

Call it three to five days of real work.

Done by copy-paste at twenty minutes a document, it is roughly six weeks.

The gap is not the import tool. It is the six hours of decisions at the start that stop you from doing the wrong work four hundred times.

---

Ready to run the import itself? Here is the bulk import walkthrough, screen by screen.