# How to migrate custom taxonomies from WordPress > You migrate custom taxonomies from WordPress by deciding what each one is for, then handling it like tags for its archive URLs and like custom fields for its data. A custom taxonomy, such as genre, brand, or region, groups your content and generates archive pages like /genre/rock/, so the first decision is which of those archives have real value: keep and rebuild the ones that earn traffic, and 301 the rest to a relevant page. The second decision is whether you need the taxonomy as structured data on the new site: if it powers faceted browsing or filtering, export the terms and their assignments to posts as data, so you can rebuild that browsing; if it was only display, a capture of the rendered pages is enough. So it is two questions, archive value and data reuse, answered per taxonomy. WPBuildAI triages your taxonomy archive URLs, exports the terms and assignments where you need structured browsing, and 301s the archives you retire, so nothing valuable is lost. Source: https://wpbuildai.com/how-to-migrate-custom-taxonomies-from-wordpress/ By lawrence-arya ยท 2026-06-03 --- You migrate custom taxonomies from WordPress by deciding what each one is for, then handling it like tags for its archive URLs and like custom fields for its data. A custom taxonomy, such as genre, brand, or region, groups your content and generates archive pages like /genre/rock/, so the first decision is which of those archives have real value: keep and rebuild the ones that earn traffic, and 301 the rest to a relevant page. The second decision is whether you need the taxonomy as structured data on the new site: if it powers faceted browsing or filtering, export the terms and their assignments to posts as data, so you can rebuild that browsing; if it was only display, a capture of the rendered pages is enough. So it is two questions, archive value and data reuse, answered per taxonomy. WPBuildAI triages your taxonomy archive URLs, exports the terms and assignments where you need structured browsing, and 301s the archives you retire, so nothing valuable is lost. ## What a custom taxonomy is doing The reason custom taxonomies need a plan is that they play two roles at once. A custom taxonomy is a grouping beyond the built-in categories and tags, genre, brand, region, added by a theme or plugin, and it does two things: it generates archive URLs like /genre/rock/ that may be indexed, and it may structure how the site works, powering filters and faceted browsing. Those two roles map onto two migration concerns you already know from elsewhere: the archive URLs behave like [tag pages](/what-happens-to-tag-pages-after-migration), and the underlying terms behave like [custom field data](/what-happens-to-custom-fields-acf-after-migration). Seeing a taxonomy as both a set of URLs and a set of structured data is what tells you it needs handling on both fronts. ## Handle the archive URLs by value The URL side is the tag-page playbook. WordPress generated an archive page for each taxonomy term, and as with tags, most are thin while a few earn real traffic, so triage by value: check analytics and Search Console, keep and rebuild the taxonomy archives that rank or attract visitors as intentional listing pages, and retire the rest. A rebuilt site does not auto-generate every taxonomy archive, so you choose deliberately rather than recreating them all. For the ones you retire, 301 their URLs to the most relevant page, a related archive or a hub, so nothing that was indexed or linked ends in a 404, exactly as any [URL change](https://developers.google.com/search/docs/crawling-indexing/301-redirects) should be handled. Since value concentrates on a minority of pages, per the [Ahrefs study](https://ahrefs.com/blog/search-traffic-study/), the few archives worth keeping are usually easy to spot. ## Export the terms when they power functionality The data side is the custom-field playbook. If the taxonomy only labeled or displayed content, capturing the rendered pages carries it across and there is nothing extra to do. But if it powers functionality, filtering, faceted browsing, grouped listings, then the new site needs each term and its assignments to posts as structured data, which means exporting from the source rather than scraping finished pages. The [WordPress REST API](https://developer.wordpress.org/rest-api/) can expose taxonomy terms and their relationships as structured data, overlapping with [exporting custom post types](/how-export-custom-post-types-wordpress-json), and this is exactly the structured export you need when moving to a [content platform like Sanity or Strapi](/migrate-wordpress-content-sanity-strapi). The test is simple: does the new site need to use the taxonomy, or just show it? Use decides export. ## Do not lose faceted browsing by assuming capture covers it The trap here mirrors the custom-fields trap. If your taxonomy powered filtering, a shop filtered by brand, a directory browsable by region, and you only captured the rendered pages, you have the appearance of the old browsing without the term data that made it work, and rebuilding it afterward is painful. So make the use-versus-display decision before you migrate, and where the taxonomy drives browsing, export the terms and assignments while your WordPress access is live. This is a content-integrity safeguard, not an SEO one, since the platform itself is not a ranking factor, but losing the structured terms quietly breaks any feature built on them, which no [careful site move](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) should permit. Decide the data question early, not after launch. ## Rebuild the keepers as intentional structures For the taxonomy archives and browsing you keep, rebuild them as deliberate structures rather than auto-generated stubs. The archives worth keeping become proper listing or hub pages, ideally at the same URLs so their rankings transfer, and the faceted browsing is rebuilt from the exported term data into the new site's templates. The result is a smaller, more intentional set of taxonomy pages and working filters, instead of the sprawl of thin archives WordPress produced automatically. This is the same quality-over-quantity outcome as with tags: a few genuinely useful grouped pages and functional browsing, not hundreds of empty term archives. The migration is the moment to make the taxonomy serve the site deliberately rather than by default. ## Steps to migrate custom taxonomies 1. **List your custom taxonomies** and what each one does: display or functionality. 2. **Triage the archive URLs by value**, keeping the earners and retiring the rest. 3. **301 the retired archive URLs** to relevant pages. 4. **Export terms and assignments as data** where the taxonomy powers browsing. 5. **Rebuild kept archives and faceted browsing** as intentional structures. 6. **Verify** that kept archives resolve and any filtering works after launch. ## Worked example: preserving a browsable directory Consider a directory site using a custom region taxonomy to let visitors browse listings by area, with archive pages per region. Migrating, the team treated the taxonomy on both fronts. On the URL side, they found that several region archives ranked and drew traffic, so those were kept at their URLs and rebuilt as proper hub pages, while a few empty ones were 301-redirected. On the data side, because the region browsing was real functionality, they exported every region term and its listing assignments as structured data through the REST API, then fed that into the new site's templates to rebuild the browse-by-region filtering. The rankings held, and the directory's core feature worked, because they handled both the archives and the data. ## Limitation: complex taxonomy structures need mapping It is honest to bound this. Simple taxonomies migrate cleanly, but complex arrangements, hierarchical taxonomies with parent and child terms, content assigned to many overlapping taxonomies, or terms carrying their own metadata, may not map one to one onto the new platform's content model and need deliberate mapping and testing. The terms can move, but reshaping a rich taxonomy structure to fit the new system is real work, much like migrating complex custom fields. So scope taxonomy-heavy sites honestly: a single display taxonomy is trivial, while a site whose structure and browsing depend on several interrelated taxonomies deserves planning rather than an assumed clean import. Decide the model on the new platform deliberately, not by hoping the old structure transfers unchanged. ## Key points You migrate custom taxonomies by deciding what each is for, then handling it on two fronts: the archive URLs like tag pages, and the term data like custom fields. Triage the archives by value, keeping and rebuilding the ones that earn traffic as intentional pages and 301-ing the rest, since a rebuilt site does not auto-generate them all. Where the taxonomy powers filtering or faceted browsing, export the terms and their assignments as structured data while your WordPress access is live, since a capture of rendered pages gives you the look without the data, and assuming otherwise quietly breaks the browsing. Rebuild the keepers as deliberate structures at their original URLs, and scope complex hierarchical or overlapping taxonomies carefully, since they need real mapping. WPBuildAI triages your taxonomy archive URLs, exports the terms and assignments where you need structured browsing, and 301s the archives you retire, so nothing valuable is lost. Send your web address for a free analysis. Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.