Phase 2: Plan the WordPress Architecture

Planning a WordPress architecture means transforming the audit into a concrete WordPress structure before you move any content. Focusing on this will get things right and save rework and restructuring after the launch.

Mapping Sitecore to WordPress

Sitecore and WordPress organize content differently. Before you can migrate anything, you need a clear map of how each Sitecore concept translates into its WordPress equivalent.

Map Your Content Types

Sitecore uses templates for different content types. For example, a blog post template might have a headline, author, body, and featured image field.

WordPress lets you use posts for blog posts on your website, while the About Us, Services, etc. can be added to pages. For content types like case studies, products, events, etc., you may need pages with a specific layout. These can be created using custom post types.

Here’s the list of content types and the Sitecore template you are using, with the corresponding WordPress equivalent you can use.

Sitecore	WordPress Post Type
Sitecore Item	Post
Sitecore Item	Page
Sitecore Item	Custom Post Type: “Case Studies”
Sitecore Item	Custom Post Type: “Products”
Sitecore Item	Custom Post Type: “Team”
Media Library Items	WordPress Media Library Assets

Plan Categories and Taxonomies

Sitecore organizes content partly through its folder structure and content relationships. WordPress uses taxonomies, categories, and tags.

Decide early how you’ll categorize each content type. You can use categories for topics (“Marketing,” “Product Updates”) and tags for finer detail. This is where you scan the folders in Sitecore and map them to categories and taxonomies you want to set in WordPress.

Map Built-in Functionality to Plugins.

Sitecore bundles functionalities like personalization, analytics, and forms directly into the platform. WordPress, on the other hand, gives you a lean core that you can extend by using plugins you need.

Map the functionalities you use on the current site and list the WordPress plugins you can use on the new site.

Sitecore Functionality	WordPress Equivalent
Forms	Gravity Forms, WPForms, SureForms
SEO/metadata management	Yoast SEO, Rank Math
Digital asset management	WordPress Media Library, third-party DAMs
Basic personalization	Jetpack, HubSpot, Salesforce Marketing Cloud, or third-party tools Mutiny, VWO

Make a Note of Personalization and Marketing Stack Tools

Personalization added through Sitecore’s xDB cannot be replaced directly in WordPress. In WordPress, you can handle this using marketing automation platforms and CDPs like HubSpot and Salesforce Marketing Cloud.

It’s best to get your marketing team involved rather than just the developers.

Map User Roles and Permissions

Sitecore offers a role-based access system. WordPress has 5 built-in roles: Administrator, Editor, Author, Contributor, and Subscriber. Most of the time, this will be enough. If needed, you can create custom roles in WordPress.

But if your Sitecore site has a more in-depth permission structure (for example, an approval workflow requiring sign-off before publishing), you can use plugins like User Role Editor or PublishPress to add that pinch of control.

Choose Your Architecture: Single Site or Multisite?

If you manage more than one website, brand, or a regional site in Sitecore, you need to decide how this goes in WordPress.

To make this decision well, it helps to understand how Sitecore structures multi-site setups and then map each piece to its WordPress equivalent.

How Sitecore Handles Multiple Sites: Tenants and Site Collections

In Sitecore XM Cloud, multi-site management is organized around tenants. A Tenant is the top-level container for an organization’s Sitecore environment. It holds one or more Sites (sometimes referred to as a Site Collection), each representing an individual website or brand.

All Sites within a Tenant share the same underlying Sitecore instance, Content Tree, and set of templates and renderings, even though each Site can have its own domain, content, and design.

If your organization is still on Sitecore’s on-premises XP or XM platform rather than XM Cloud, the same idea exists under a different name: a multi-site configuration. Here, a single Sitecore instance hosts multiple site definitions, each configured through Sitecore’s Sites.config (or a config patch file).In Sitecore XM Cloud, multi-site management is organized around Site Collections. A Site Collection is the top-level container for an organization’s sites within Sitecore XM Cloud. It holds one or more Sites, each representing an individual website or brand.

All Sites within a Site Collection share the same underlying Sitecore instance, the same Content Tree, and the same set of templates and renderings — even though each Site can have its own domain, content, and design. Importantly, data templates, rendering items, and content can only be shared by Sites within the same Site Collection. Sites in different Site Collections cannot share these resources.

If your organization is still on Sitecore’s on-premises XP or XM platform rather than XM Cloud, the equivalent concept exists under a different name: a Tenant in SXA (Sitecore Experience Accelerator). Here, a single Sitecore instance hosts multiple site definitions under a Tenant, each configured through Sitecore’s Sites.config or a config patch file.

How This Maps to WordPress Multisite

WordPress Multisite is WordPress’s equivalent to Sitecore’s multi-tenant model, though the terminology is different enough that it’s worth mapping carefully:

Sitecore Concept	WordPress Multisite Equivalent
Tenant	Network (the overall Multisite installation)
Site Collection	Site (an individual site within the Network)
Site definition (hostName, rootPath, startItem)	Site’s domain or subdomain, and its home page
Shared Content Tree, templates, and renderings	Network-activated themes and plugins, shared across all Sites
Master / Web / Core databases (shared across sites)	A single WordPress database, with each Site’s content stored in its own set of prefixed tables (e.g., wp_2_posts, wp_3_posts)
Sitecore administrator with cross-site access	Super Admin (Network Admin) manages the entire Network
Site-level content author or editor	Site Admin manages a single Site within the Network
Cross-site content referencing/shared datasource items	Content syndication across Sites, typically via a plugin such as Distributor or Broadcast, since WordPress Multisite doesn’t share content across Sites natively

In WordPress Multisite, you can run multiple websites from a single WordPress installation, sharing the same core files and plugins, while keeping the content separate.

You can pick:

• Single site: If you manage one website or when all the others are independent.
• Multisite: If you manage multiple related sites (regional versions, sub-brands) that benefit from shared plugins, centralized updates, and consistent design

Choose Your Hosting

Hosting plays a big role in how well your WordPress site performs. Enterprise teams usually choose between two paths.

• Managed hosting: If you want performance and security handled for you, and you’re willing to pay for that convenience
• Self-managed VPS: If you have (or plan to hire) technical resources in-house and want full control over server configuration and cost

When migrating from Sitecore to WordPress, you already have a lot on your plate. So, it’s best to opt for managed hosting in the beginning. You can shift to a self-managed host later.

Decide the Site Structure

Once you’ve listed the content types, categories, taxonomies, hosting, etc., it’s time to decide the site structure, such as the navigation, URL hierarchy, and how pages relate to each other.

• Group related content logically (all case studies under /case-studies/, all products under /products/)
• Decide on a consistent URL structure that’s clean and predictable
• Plan your main navigation menu around what visitors actually look for, not around your internal org chart
• Identify where old Sitecore URLs will need to map to new WordPress URLs
• 301 redirect the old URLs to the new ones

Having a clear structure now will help you avoid just dumping content into the WordPress website.

What You Should Have When This Phase Is Done

By the end of Phase 2, you should have:

• A complete map of Sitecore Items to WordPress post types
• A defined taxonomy and category structure
• A plugin list replacing your Sitecore built-in functionality or custom implementation
• User roles and permissions plan
• A decision on single site vs. multisite
• A hosting choice and provider
• A documented site structure (sitemap) and URL hierarchy

With these in hand, you’re ready to move with the migration without losing the SEO value you’ve built up over years.