A WordPress rebuild can look like a design project from the outside. In practice, the riskiest work begins before anyone chooses a component, writes a template, or moves a page. The first job is to understand what the current site is actually doing.
A website is more than the pages visible in its navigation. It may include campaign landing pages, form routing, redirects, custom fields, scheduled content, analytics events, search behavior, third-party feeds, and years of decisions that are not obvious from the homepage. If those details are discovered late, a rebuild becomes slower, more expensive, and harder to launch safely.
Start With the Public Surface
Begin by crawling the current site and building a page inventory. A sitemap is useful, but it is not enough on its own. Sitemaps can omit orphaned pages, utility URLs, paginated archives, media attachments, and paths that are only linked from campaigns or external sources.
For each URL, record its page type, purpose, traffic importance, owner, and intended destination. The goal is not to preserve every page automatically. The goal is to make every keep, merge, rewrite, redirect, or retire decision visible.
- Core pages: homepage, services, about, contact, and conversion paths.
- Content collections: posts, projects, resources, events, products, and staff profiles.
- Utility states: search, 404, archives, thank-you pages, and gated content.
- Campaign pages: paid landing pages, email destinations, and time-sensitive promotions.
- Media and downloads: PDFs, documents, videos, and files with external backlinks.
Map Templates, Not Just URLs
A long list of pages becomes manageable when it is grouped into reusable patterns. Identify which pages share a template and where the current site breaks that pattern. Those exceptions often reveal the real requirements for the new system.
For example, ten service pages may appear similar, but two may need calculators, one may require a location selector, and another may be the destination for a paid campaign. A single generic template will not necessarily support all four jobs.
The useful question is not “How many pages are there?” It is “How many distinct publishing and interaction patterns must the new system support?”
Audit the Data Behind the Pages
Next, inspect how content is stored. In WordPress, presentation and content can become tightly coupled through page builders, shortcodes, widgets, reusable blocks, custom fields, and theme options. A page may render correctly while depending on a plugin or global setting that is easy to miss.
Document custom post types, taxonomies, custom fields, relationships, reusable patterns, menus, sidebars, forms, and theme settings. Note which fields are genuinely useful to editors and which exist only because of an older implementation. This is the moment to simplify the content model before old complexity is copied into a new design.
Trace Integrations and Operational Dependencies
Forms deserve their own inventory. Record where each form sends data, who receives notifications, which confirmation states appear, and whether submissions connect to a CRM, email platform, payment service, webhook, or internal workflow.
Do the same for analytics, consent tools, search, ecommerce, membership, calendars, feeds, maps, and authentication. Capture DNS, CDN, SSL, transactional email, backup, and monitoring responsibilities as well. These systems may not be visible in a design file, but they determine whether the rebuilt site works after launch.
Build the Redirect Plan Early
Redirect mapping should begin during discovery, not on launch day. Once the current URL inventory and future information architecture exist, every changed path can be mapped deliberately. This protects useful backlinks, search visibility, bookmarks, and campaign traffic.
The redirect sheet should include the old URL, new destination, decision reason, and validation status. Avoid sending large groups of unrelated pages to the homepage. When content no longer has a direct replacement, choose the closest genuinely useful destination or return the appropriate removal status.
Understand the Editorial Workflow
A rebuild also changes how people work. Ask who creates content, who reviews it, which fields are required, how previews are shared, and what must remain locked. A visually polished frontend can still be a poor system if editors need workarounds to publish routine updates.
- Which updates happen weekly, monthly, or only during campaigns?
- Which sections should be reusable, and which should be intentionally constrained?
- What can editors change without developer help today?
- Where do current workflows create mistakes or duplicated effort?
- What training and documentation will the new build require?
Define a Launch Baseline
Before development starts, capture the current site’s measurable baseline: key templates, responsive behavior, accessibility issues, Core Web Vitals, search visibility, indexed URLs, analytics events, form submissions, and known technical defects. The baseline makes later QA objective and helps separate existing problems from rebuild regressions.
A good inventory does not eliminate every surprise. It reduces avoidable ones. It turns the rebuild from a collection of assumptions into a controlled migration with clear scope, traceable decisions, and a safer launch.
A Practical Deliverable Set
For most rebuilds, discovery should leave behind a URL inventory, template matrix, content model, integration map, redirect plan, ownership list, launch checklist, and risk register. Those documents are not administrative overhead. They are the technical foundation that lets design and development move quickly without losing important details.
If your current site runs on a hosted website builder, start with what to plan before moving to WordPress. For hands-on help, explore my WordPress development services.