When you migrate off WordPress, you treat tag pages by value rather than recreating all of them, because most tag archives are thin, near-duplicate listing pages that add little, while a few may genuinely earn traffic. So the plan is to check your analytics and Search Console, keep and rebuild the handful of tag pages that rank or attract visitors, and retire the rest by mapping their URLs to a 301 pointing at the most relevant real page, usually a category or a hub. A rebuilt site does not auto-generate a tag page for every tag the way WordPress does, which is a good thing, so you decide deliberately which listings are worth having. That way you keep the few valuable ones, avoid a wave of 404s from the retired ones, and stop the crawl-budget drain of dozens of empty tag archives. WPBuildAI extracts every /tag/ URL, helps you split the earners from the empties, and maps each retired one to a verified 301, so nothing valuable is lost and nothing thin is carried forward.
Why WordPress has so many tag pages
The reason you face this decision at all is how WordPress handles tags. Every time you tag a post, WordPress creates or extends an archive page at /tag/whatever/ that lists posts with that tag. Over years, a site accumulates hundreds of these, many holding one or two posts, many overlapping heavily with each other and with category pages. They are generated automatically, not authored, so most site owners never think about them until they appear in a crawl. That automatic generation is the whole issue: it produces a large number of thin, near-duplicate pages that you never deliberately decided to publish, which is exactly why a migration is a good moment to sort them out.
Retire by value, do not recreate wholesale
The right frame is triage, not preservation. Recreating every tag page on the new site would just reproduce the clutter, and a rebuilt site does not generate them by default, so you get to choose. Keep the tag pages that earn their place and retire the rest. This is the same value-based approach used for attachment pages: the thin, auto-generated pages go, and the real content stays. Because traffic and value concentrate on a small share of pages, as the Ahrefs study shows, retiring the empty archives loses essentially nothing while tidying the site, and the platform itself is not the ranking factor, as the Backlinko analysis makes clear.
Find the few tag pages worth keeping
The data tells you which tags earn their keep. Look in your analytics and Search Console for tag URLs that receive visits, impressions, or clicks, and check for any that have attracted inbound links. Those are the ones a real audience uses, perhaps a tag that became a de facto topic hub, and they are worth rebuilding as proper listing pages on the new site. Everything else, which for most sites is the overwhelming majority, is a thin archive no one visits. Deciding from evidence, rather than keeping tags out of habit, is what separates a clean migration from one that drags the clutter along. It also overlaps with the wider job of finding orphan and low-value pages before you rebuild.
Redirect the retired tag URLs
Retiring a tag page does not mean letting its URL break. Any tag URL that was indexed or linked should be sent to a real page with a 301, so residual traffic and links land somewhere useful, exactly as any URL change should be handled. The natural target is the most relevant real page: a related category, a topic hub, or the blog index if nothing more specific fits. To do this completely you need the full list of tag URLs, which is why extracting every URL up front matters. For tags that were never indexed and had no links, a 301 to the blog index is still cleaner than a 404, though a 410 is defensible if you want to signal permanent removal, a distinction covered in 404 versus 410.
Rebuild the keepers as real listing pages
For the tags worth keeping, rebuild them as intentional listing pages rather than auto-generated stubs. On the new site you control what a tag listing looks like, so the ones you keep can be genuinely useful: a clear heading, a short description of the topic, and the relevant posts. Keep the same URL where you can, so any rankings and links transfer directly, and 301 it if the address must change. The result is a small set of tag or topic pages that actually serve visitors, instead of the sprawling set of thin archives WordPress produced. Quality over quantity is the point: a few good listings beat hundreds of empty ones.
Steps to handle tag pages in a migration
- Extract every /tag/ URL so none is missed in the decision.
- Check analytics and Search Console for tags with traffic, impressions, or links.
- Keep and rebuild the earners as intentional listing pages, same URL where possible.
- Retire the rest, mapping each to a 301 toward a relevant category, hub, or the blog index.
- Do not auto-generate empty tag pages on the new site.
- Watch Search Console for tag 404s and consolidation over the next crawls.
Worked example: 200 tags down to eight useful ones
Consider a blog that had accumulated roughly 200 tags over a decade, most attached to one or two posts. Before migrating, the owner pulled the tag URLs and checked the data: eight tags received real search traffic, and the rest saw essentially none. On the new site, those eight became proper topic listing pages with descriptions, keeping their original URLs so their rankings carried over. The other tag URLs were each 301-redirected to the closest category or to the blog index. No empty tag pages were generated on the new build. The result was a cleaner site with eight genuinely useful topic pages, no 404s, and crawl attention focused on content that mattered rather than spread across 200 thin archives.
Limitation: check before assuming a tag is worthless
It is honest to bound this. The default that most tag pages are disposable is true for most sites, but it is a generalization, so check your own data before sweeping them away. Occasionally a tag page has quietly become a ranking topic hub or attracted links, and that one deserves to be kept and rebuilt, not redirected into oblivion. Consolidation of the redirected tags is also gradual, so expect Search Console to work through it over several crawls rather than instantly. The rule is retire-by-value, which means letting evidence, not habit, decide both which tags to keep and which to retire.
Key points
When you migrate off WordPress, you handle tag pages by value rather than recreating them wholesale, because WordPress auto-generates an archive for every tag and most are thin and near-duplicate. Extract every /tag/ URL, use analytics and Search Console to find the few that earn traffic or links, and rebuild those as intentional listing pages, keeping their URLs where you can. Retire the rest with 301s pointing at the most relevant category, hub, or the blog index, so nothing 404s and any residual value is preserved, and do not let the new site auto-generate empty tag pages. Check your own data before assuming a tag is worthless, since the odd one is a real hub, and expect consolidation to take a few crawls. WPBuildAI extracts every /tag/ URL, separates the earners from the empties, and maps each retired one to a verified 301. Send your web address for a free analysis.
Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.