Page migrations get planned. Document migrations tend to get discovered, often a few weeks into a redesign. Someone runs a full crawl and finds nine thousand PDFs sitting under the four hundred pages everyone planned for. A good part of the organization’s search traffic may be landing on files nobody has opened since the day they were uploaded. If you need to migrate thousands of documents without losing search visibility, those files need a plan of their own.
Large document libraries are common at municipalities, universities, health authorities and associations, and at any company that publishes reports, manuals or product sheets. Documents rank and attract outside links, yet they usually get moved last, in a hurry. That combination is how a migration ends with a visible drop in traffic.
Why documents behave differently from pages
Four differences shape the rest of the work.
- Search engines index them on their own. A PDF has its own ranking, its own backlinks and its own visitors arriving from search. Moving the page that links to it leaves the file where it was.
- Their links live outside your site. Reports get cited on partner sites, in news articles, in academic papers and in print. You can’t edit any of those links.
- Nobody owns them. A page usually has an author who still works there. A tender document from ten years ago has no one.
- They carry accessibility risk. Untagged PDFs are a common reason an otherwise compliant site fails an accessibility audit. A migration is when that risk comes into view.
Inventory first, and record more than the filename
Crawl the site, pull the file list from the server and compare the two. They will disagree, and the gaps are useful. Files on the server that nothing links to are orphans. Files that are linked but missing are already broken.
For each document, record:
- the current URL, file size and last modified date;
- the pages on your site that link to it;
- whether other sites link to it;
- its impressions and clicks over the past twelve months;
- whether the file is tagged for accessibility.
That last column is usually empty when you start, and it decides what the next phase costs.
Treat the inventory as a deliverable and keep it with the project records. You will check the finished migration against it, and it answers the question someone will ask six months later about why a particular file is gone.
Sort every document into one of four groups
Base each decision on the inventory data rather than on what people remember about a file. Every document goes into one group:
- Move as is. Current, in use, and either tagged already or scheduled for remediation.
- Convert to a page. Documents that should have been web pages from the start: a two-page fee schedule, a list of office hours, a PDF form that could be a web form. A page can be read on a phone, found by site search and edited by staff, and it is far easier to make accessible.
- Archive. Has to stay retrievable for records reasons, but can come out of the navigation and the search index.
- Retire. Replaced, duplicated, or with no traffic, no links and no retention obligation.
The second group is where the site actually gets better. In many libraries, a fair share of the PDFs exist only because a PDF was the easiest thing for the author to publish. Turning them into pages is how a migration ends up improving the site.
The fourth group needs a named approver. Deleting content is a governance decision, so the person who signs off should be someone other than the person running the migration.
Give documents real URLs
Many document libraries have URLs shaped by whatever tool uploaded the files: a dated folder, an export path, a filename with a version number in it. If the new platform is going to change those addresses anyway, pick the new pattern on purpose. A readable URL tells people what they are about to open, in a search result or a citation. Google gives the words in a URL very little ranking weight, so the gain is for readers.
Whatever pattern you choose, keep two rules. Each old URL redirects in a single hop to its new address, with no chains. And the path stays stable from year to year, so next year’s edition of an annual report can live at the same address. WordPress stores uploads in year and month folders by default. A recurring report therefore needs a fixed URL of its own, such as a document page that always serves the current file.
Script the move
Nobody moves nine thousand files by hand without mistakes. Script the transfer, generate the redirects from the inventory with a script, and script the checks too. A scripted migration can run on a staging site, get checked and corrected, then run again. A manual one can’t be repeated, so every error stays and every fix means another pass by hand.
Build the redirect map from the inventory rather than writing it separately. When two people keep two files, the files drift apart, and the drift shows up as 404 errors after launch.
Rewrite the internal links
Redirects are there for the links you can’t change on other sites. Your own links should point straight at the new addresses. A site that leans on its redirect table for its own navigation is slower and harder to audit, and a single server move can wipe that table out.
Update every internal reference, including links inside other documents when you still have their source files. Then crawl again and confirm that no internal link goes through a redirect.
Reconcile, then prove it
A reconciliation report shows, line by line, that the migration happened as planned. Every row of the original inventory ends in one of four states:
- moved and checked at a new URL;
- converted to a named page;
- archived at a stated location;
- retired, with the name of the person who approved it.
Every row should be accounted for, and the totals in the report should match the inventory.
Then run the checks that reconciliation can miss. Request every old URL and confirm it lands on a live file in one hop. Crawl the new site for broken links and redirect chains. Make sure the new document URLs appear in your sitemap. On WordPress that takes some deliberate work, because the built-in sitemap leaves media files out. These checks belong on the same list as the rest of your checks before launch.
Watch the right numbers afterwards
Search engines take longer to reindex documents than pages, so give it more than a week before you judge the result. In Search Console, the old URLs’ impressions should fall while the new URLs’ impressions rise, with the total staying roughly level. Keep an eye on crawl errors and on the number of indexed documents. A dip is normal, and it usually recovers over several weeks.
The number to worry about is a total that never gets back to where it started. The cause is usually a redirect chain, a missing rule for one folder, or a batch of files that failed to transfer without anyone noticing. The reconciliation report is where you find all three.
Whoever runs your migration should hand over the inventory, the redirect map, the reconciliation report and the crawl report along with the site. Our page on content and data migration describes the process in more detail.