Context and problem
Myra Dental had one of the strongest content libraries in its sector — years of treatment content, multilingual patient stories and meaningful SEO authority across international markets. But the technical foundation underneath could no longer carry it.
The two WordPress installations powering myradental.com and myradental.co.uk had drifted apart through layers of plugins, theme patches and configurations that no longer talked to each other. The cracks showed up in three places: search performance, editorial speed, and operational risk.
SEO bottlenecks
Slow Core Web Vitals, inconsistent structured data, conflicting canonical and hreflang tags, runaway page templates and near-duplicate indexing across the two domains were quietly suppressing organic traffic.
Editorial friction
Plugin dependencies meant even adding a simple content field required developer involvement; the schema didn't reflect the way the team actually worked.
Operational risk
Outdated plugins, conflicts on critical patches, deployments that caused downtime, and backups that ran by hand.
Goals
The project was framed around four clear goals — and the order of these goals mattered, because protecting an existing SEO asset is a very different kind of project from launching a greenfield site.
Preserve and strengthen the SEO legacy
Carry the existing rankings forward into a stack that meets modern search expectations — structured data, semantic HTML, performance, and LLM visibility.
Editorial autonomy
Let marketing and content publish pages, campaigns and treatment material without needing a developer.
Sustainability
A single codebase, no plugin dependency hell, schema in version control.
Reliability
No publish-time downtime; deployments and backups that are transparent and reversible.
A modern architecture on Payload CMS
The new platform was built on Next.js and Payload CMS. Payload's code-first content modeling put the schema into version control, and the rich block-based page composition the marketing team needed came out of a single schema definition.
At the client's request, the .com and .co.uk sites run as two separate Payload installations on two separate servers, each with its own admin panel. This was a deliberate isolation choice rather than a multi-tenant build:
Market independence
The UK and Turkish markets work under different regulatory frameworks, different campaign cadences and different content tones. The Turkish and English content aren't localised mirrors of each other — they're independently authored for their own audience.
Failure isolation
A content or configuration mistake on one side doesn't bleed into the other; deployment issues and traffic spikes stay scoped to their domain.
Access boundaries
Each market's team only sees its own content library and media assets — cross-market mishaps are simply impossible.
One shared codebase
The two installations don't drift, because they share everything that should be shared:
One codebase, two deployment pipelines
Architecture patterns, content blocks, the SEO layer, performance improvements and bug fixes are produced once and roll out evenly to both deployments through environment-aware configuration.
Schema parity
TypeScript content models are identical on both sides; the markets produce different content, but the structural fields stay consistent.
DevOps standard
Atomic deployment, preview environments and backups follow the same standard on both servers.
SEO migration — a zero-traffic-loss discipline
The migration ran in weekly lockstep with the SEO team. From a product management point of view this was the most sensitive workstream: protecting the rankings wasn't just a technical redirect map, it required preserving the semantic integrity of content, media and URL hierarchy.
URL and redirect map
Every legacy URL was collected into a single source-of-truth list and converted, through structural and category-aware mapping, into a 1:1 301 redirect map.
Breadcrumb and category hierarchy
The legacy WordPress category depth and breadcrumb structure was modelled in Payload as relational collections, so internal link authority and crawl paths stayed intact.
Media migration
The media library was re-encoded to AVIF/WebP, alt text was preserved, and everything was wired into Next.js's image optimization pipeline.
Page-level structured data
Treatment pages emit MedicalProcedure, doctor profiles emit Physician, patient stories emit Review, and corporate pages emit Organization and LocalBusiness — all generated automatically from Payload content.
llms.txt and LLM visibility
The site exposes an llms.txt so LLM-based search agents can discover canonical content and summaries cleanly.
Hreflang and cross-domain canonical
The language/market relationship between the two domains is now explicit via hreflang; pages that used to be flagged as duplicates now reinforce each other.
Sitemap, RSS, Open Graph
All meta structures are derived from Payload content — when an editor publishes, there's no separate SEO step.
Deployment and operations
The deployment pipeline was designed against the legacy stack's worst pain points — downtime during releases, manual backups and unpredictable plugin upgrades.
Atomic, zero-downtime deployment
Traffic only switches once a new build passes its health checks, and rollback is one command away.
Preview environment
Every content change is rendered in a preview URL the team can review before publish.
Render and cache strategy
Pages are server-rendered; outputs are then held in Next.js cache and Cloudflare's edge cache. When the editorial team publishes through Payload, the affected pages' caches are invalidated on demand and only those pages are regenerated. Users get cache-fast responses on most requests, and editor changes go live immediately.
Monitoring
Performance, traffic and error tracking run through Cloudflare Analytics and Google Analytics. There's no custom dashboard or reporting automation — post-launch oversight stays inside the team's existing daily flow.
The product management lens
This wasn't only a technology change — it was a project in risk management, stakeholder coordination and process design.
Risk
Loss of organic traffic was the dominant risk. The migration ran with weekly checkpoints with the SEO team, and the redirect map and structured data were validated against a full crawl on staging the day before go-live.
Stakeholder management
Marketing, SEO, content and clinical teams sat at the same table while the content schema was designed — so the schema reflects how those teams actually work. The client's preference for two panels was framed inside that conversation as an operational requirement, not a technical constraint.
Editorial handoff
After launch the content team was given training and documentation; developer dependence was broken in operations, not just in code.