WrestlingWorld

WrestlingWorld is a wrestling news and rumors destination covering WWE, AEW, TNA, NJPW, and more. A news brand like this lives or dies on velocity: breaking stories, show results the morning after, and PPV schedules that readers check on their phones.

The WordPress build it ran on could publish articles, but that was about all it did well. Plugin debt and theme bloat made every page heavier than it needed to be, and anything structured — Quick Results by show, promotion tabs, event calendars — had to be faked with shortcodes and hand-edited posts. Shipping a new content module meant fighting the stack instead of extending it.

The stakes were commercial: an ad-supported news site loses readers, rankings, and revenue when pages are slow, and loses editorial output when writers wrestle the CMS instead of writing. I was brought in to migrate the platform and I continue to maintain it in production.

Goals & Success Criteria

“Done and good” meant four things: writers publish breaking news with no developer in the loop; results, shows, and events live as structured data instead of formatted text; SEO-critical URLs survive the migration intact; and the high-traffic surfaces — homepage, article pages — get meaningfully faster than the WordPress build they replaced.

Approach & Key Decisions

Payload CMS over staying on WordPress or going headless-WP. Keeping WordPress as a headless backend was the low-risk option and I considered it seriously — it would have preserved the editorial UI writers knew. I rejected it because the real problem was the content model: results and events needed to be first-class collections with their own fields, not posts with markup conventions. Payload gave me a code-defined schema — news, shows, results, events, media — and an admin UI generated from it. The trade-off I accepted: writers had to learn a new admin, so I kept the editorial workflow (drafts, categories, featured flags) close to their WordPress habits to soften the switch.

Structured results over formatted articles. Quick Results was previously a manually formatted post per show. I modeled winners, matches, and shows as data, which is more work per schema but means one entry powers the homepage module, the show tabs, and the archive simultaneously — and can never drift out of sync with itself.

Static-first rendering with targeted revalidation. News sites tempt you toward fully dynamic rendering, but most traffic hits pages that change rarely. I made article and archive pages statically generated with cache revalidation on publish, keeping dynamic rendering only where freshness genuinely matters. The trade-off: a just-published story can take a moment to propagate, which is acceptable for minutes-level news and irrelevant for evergreen pages.

URL preservation. Years of Google rankings lived in the old permalink structure, so the migration mapped every legacy URL to the new routes rather than starting clean.

Challenges

The migration itself was the hard part: years of WordPress posts full of shortcodes, embedded tweets, and inconsistent image handling had to become clean structured content in Payload. A straight export-import would have shipped the mess to the new system, so I wrote migration scripts that converted content programmatically and flagged articles that needed human review instead of silently guessing.

The second challenge was ongoing rather than one-time: shipping new modules — promotion filters, the PPV schedule, results tabs — on a site that publishes daily. Every change deploys against live editorial traffic, which forced a discipline of small, reversible releases.

Results & Impact

The platform is live at wrestlingworld.co and has run in production since the migration. Writers publish daily across four-plus promotions without developer involvement; Quick Results, show tabs, and the PPV schedule run from structured data; and the client has kept me on for ongoing maintenance and feature work — the plainest signal that the migration delivered what it promised.

What I’d Do Differently

I would invest in the content-migration tooling earlier. The first migration pass underestimated how inconsistent a decade of WordPress content can be, and I rebuilt the scripts mid-project. Starting with a validate-and-flag pipeline from day one would have saved a round of rework.