331-URL Legal WordPress Rebuild

Client (end user): Throneberry Law Group — Nationwide mesothelioma and asbestos personal-injury practice
Engagement: White-label development for a US marketing agency
Delivered: May – Oct 2025 · 149 days · 100 hours · on schedule, no overrun

The Craft of a Rebuild

A 331-URL legal website migrating from flat .html paths to a nested clean-URL architecture — 176 asbestos company profiles, 121 mesothelioma city pages, and 883 blog-post redirects to reconcile across 10 Adobe XD templates. The rebuild shipped in 149 days and 100 development hours, with every redirect mapped, every template applied to spec, and all 58 SEO backlog items closed before the agency signed off.

This case study is a record of one such rebuild — a nationwide mesothelioma law firm with 331 content URLs and 883 blog-post redirects to reconcile, delivered for a US marketing agency in the legal segment.

Snapshot

The Brief

The agency had a retained legal client — Throneberry Law Group, a nationwide mesothelioma and asbestos personal-injury practice — whose existing WordPress site needed a full rebuild. The old site ran on flat .html URLs across hundreds of city-specific mesothelioma pages, state-specific asbestos-company profiles, and an extensive blog archive. The agency’s brief was to migrate the entire content surface to a clean, nested URL architecture on Elementor Pro, with every legacy path redirecting to its new target.

The agency handed us a Google Sheets workbook containing every URL to migrate with its target path, every template assignment, every meta title and description to port, a 23-item launch checklist, and pre-populated issues backlogs. The build ran on their WP Engine environment; contact forms ran through Gravity Forms; SEO was managed with Rank Math. Our job was to execute the spec as written — map 331 content URLs to 10 templates, reconcile 883 blog-post redirects, and close both QA backlogs before handoff.

The risk the agency was hedging against was not SEO collapse — they had that handled. The risk was handing the build to a shop that would quietly improvise around the brief: a missed redirect on a city-specific landing page, a template misapplied to a company profile, a budget overrun on a 331-URL scope, a slipped launch window on a time-sensitive legal marketing calendar.

How We Did It

1. Ten templates, 331 pages, one build pipeline. Throneberry Law Group’s pages spread across the agency’s legal template library: About Throneberry (10 pages — about, testimonials, resources, FAQs, and supporting content), Asbestos (176 pages — individual company profiles), Mesothelioma (121 pages — state and city landing pages), Veterans (10 pages), Contact Us (8 pages), plus Attorney, Location Template, Results, Blog Lander, and Article Template pages. Each page was built on its assigned template; no page was hand-rolled outside the template system. We used the agency’s legal template library across all 331 URLs rather than building individual page layouts because template-based consistency meant the site’s URL architecture remained predictable across 176 asbestos company profiles and 121 mesothelioma city landing pages, making the redirect map tractable to verify against the agency’s spec.

2. Spec followed line-for-line, from the agency’s sheet. The agency handed us a Google Sheets workbook with a Current URL → New URL map for every page. Where the old site had abex-corporation.html, the spec called for asbestos-companies/abex-corporation/. Where the old site had flat state pages, the spec called for nested mesothelioma-lawyer/california/los-angeles/ paths. We implemented each row as written. The Hours Estimated column carried the agency’s per-row budget — 46.5 hours across the 331 URL Change rows — and the aggregate came in at the agreed ~100 hours for the full engagement.

The principle behind this is simple: on a rebuild, the spec is the contract between the agency and its client. A dev team’s job is to protect that contract, not to edit it.

**3. Crawl-based verification, not “looks fine to me”.” Before DNS cutover, we ran Screaming Frog on the old production site and the staging rebuild side-by-side. Status codes, broken links, redirect chains, meta-tag differences — every delta reconciled against the agency’s spec. The workbook’s SEO Meta Data tab carried 746 rows of per-URL title, description, and H1 mappings; the SEO Optimizations tab carried 403 rows of refined meta content. Both were implemented row by row. A second crawl after go-live confirmed every internal link resolved on the live domain. Each of the 883 blog-post redirects was a manually verified row in the agency’s sitemap — a missed redirect on a city-specific mesothelioma page or an asbestos-company profile would drop not just link equity but a potential client at a moment when they were searching for legal representation, so no redirect mapping was automated without a reconciliation pass.

4. 23 launch checklist items, closed before handoff. Seven categories: Design, Functionality, Content, SEO & Analytics, Responsive, Misc / Client Specific, and Domain & DNS. Nothing shipped until each line was signed off. Cross-device QA on Chrome / Firefox / Safari / Edge and five viewports (1920 / 1280 / 1024 / iPad / mobile portrait). The checklist explicitly required a Screaming Frog crawl comparison between original and staging sites, redirect verification post-release, and confirmation that all forms submitted correctly with reCAPTCHA.

Working row-by-row from the agency’s sitemap sheet meant slug structure had to be correct before content migration and meta before cutover — the order was imposed by the redirect map, not discretionary. Pavel’s post-import note after 377 pages were live on staging: «для такого сайта – правок минимум» — for a site this scale, that read as the discipline paying out.

Results

The outcome, restated plainly: the agency’s 331-URL rebuild shipped across 10 templates on the WP Engine environment, inside the quoted hours, on the scheduled cutover day. 883 redirects were mapped and verified, 58 SEO backlog items were closed, and the launch checklist was signed off before handoff.

Operational Integrity at handoff

The parity check across all 377 staging pages before handoff caught 6 pages with missing or wrong slugs — fixed before the agency saw the build; meta content on every page came from the agency’s spec table because, as noted during the build, anything off-spec would not pass QA. Pre-handoff QA ran through Site Checker — see our QA discipline for the categories and the fail-zero gate. The agency’s own QA layer — their tools, their process — ran post-handoff and surfaced issues into the shared backlog for our fix loop until they signed off.

Process

Phases overlap (SEO backlog review ran alongside late development and post-launch follow-ons), which is why the calendar timeline is 149 days rather than the sum of individual phases.

Team

Delivery team

• Natalia Bogatel — lead developer across build, template implementation, and post-launch fix rounds
• Pavel Sazhin — QA iterations, copy migration, and backlog closure
• Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)

Agency-side project management and SEO strategy remained with the partner agency throughout. Our team was invisible to the end client.

For agencies considering a white-label WordPress build