Bağlam ve sorun
Myra Dental, kendi sektörünün en güçlü içerik havuzlarından birine sahipti: yıllar içinde biriken kapsamlı tedavi içerikleri, çok dilli hasta hikâyeleri ve uluslararası pazarda gerçekten değer taşıyan bir SEO otoritesi. Ne var ki bu birikimi taşıyan teknik altyapı çoktan yorulmuştu.
myradental.com ve myradental.co.uk'yi besleyen iki ayrı WordPress kurulumu; yıllar içinde üst üste eklenmiş plugin'ler, tema yamaları ve birbirinden kopmuş yapılandırmalarla dağınık bir hâle gelmişti. Sorun üç ayrı noktada belirginleşiyordu: arama performansı, içerik ekibinin hızı ve operasyonel risk.
SEO açısından çıkmazlar
Yavaş Core Web Vitals skorları, eksik ve tutarsız structured data, plugin'ler arasında çakışan canonical ve hreflang etiketleri, kontrolden çıkmış sayfa şablonları ve aynı içeriğin iki domain arasında yarı-duplicate olarak indekslenmesi — bütün bu sorunlar organik trafiği sessizce baskılıyordu.
İçerik yönetiminde yavaşlık
Plugin bağımlılığı nedeniyle basit bir içerik alanı eklemek bile geliştirici müdahalesi gerektiriyordu. Mevcut içerik şeması da ekibin gerçek çalışma akışıyla örtüşmüyordu.
Operasyonel risk
Güncellenmemiş plugin'ler, kritik patch'lerde uyumsuzluklar, deployment sırasında yaşanan kesintiler ve elle yürütülen yedekleme süreçleri.
Hedefler
Proje, dört net hedef etrafında şekillendi. Bu hedeflerin sıralaması da çok önemliydi: çünkü mevcut bir SEO varlığını korumak, sıfırdan yeni bir site açmaktan tamamen farklı bir iştir.
SEO mirasını koruyup güçlendirmek
Mevcut sıralamaları kaybetmeden altyapıyı modern arama gereksinimlerine taşımak — structured data, semantic HTML, performans ve LLM görünürlüğü dahil olmak üzere.
Editöryel özerklik
Pazarlama ve içerik ekibinin geliştirici beklemek zorunda kalmadan sayfa, kampanya ve tedavi içeriği yayımlayabilmesi.
Sürdürülebilirlik
Tek bir kod tabanından beslenen, plugin bağımlılığı olmayan ve içerik şeması versiyon kontrolünde tutulan sürdürülebilir bir altyapı.
Güvenilirlik
Yayın akışını kesintiye uğratmamak; deployment ve yedekleme süreçlerini şeffaf ve geri alınabilir hâle getirmek.
Çözüm: Payload CMS üzerine modern bir mimari
Yeni altyapıyı Next.js ve Payload CMS üzerine kurduk. Payload'un code-first content modeling yaklaşımı sayesinde içerik şemaları doğrudan versiyon kontrolüne girdi. Pazarlama ekibinin ihtiyaç duyduğu zengin block tabanlı sayfa kurgusu, medya kütüphanesi ve yayın akışı; tek bir şema tanımından üretildi.
Müşterinin operasyonel tercihi gereği .com ve .co.uk siteleri; iki ayrı Payload kurulumu olarak, iki ayrı sunucuda ve iki ayrı admin paneli üzerinden yönetiliyor. Bu, multi-tenant bir kurulum yerine bilinçli olarak alınmış bir izolasyon kararıydı:
Pazar bağımsızlığı
İngiltere ve Türkiye pazarları; birbirinden farklı düzenleyici çerçevelerle, farklı kampanya takvimleriyle ve farklı içerik tonlarıyla çalışıyor. Türkçe ve İngilizce içerikler birbirinin lokalize edilmiş hâli değil — her biri kendi pazarına özgü, bağımsız kurgular.
Hata izolasyonu
Bir tarafta yapılan içerik veya yapılandırma hatası diğer tarafa sızmıyor. Deployment sorunları ve trafik dalgalanmaları da domain bazında izole kalıyor.
Erişim ve yetki ayrımı
Her pazarın ekibi yalnızca kendi içerik kütüphanesini ve medya varlıklarını görüyor; pazarlar arası içerik kazaları yapısal olarak imkânsız hâle geliyor.
Tek codebase, paylaşılan disiplin
İki kurulum birbirinden kopmuyor — çünkü kopmaması gereken ne varsa paylaşılıyor:
Tek codebase, iki deployment hattı
Aynı Next.js ve Payload kod tabanı, environment-aware konfigürasyonla iki ayrı sunucuya deploy ediliyor. Mimari kararlar, content block tipleri, SEO altyapısı, performans iyileştirmeleri ve hata düzeltmeleri tek bir yerden üretiliyor; iki tarafa da eşit biçimde ulaşıyor.
İçerik şeması paritesi
TypeScript content modelleri her iki kurulumda da aynı. Pazarlar farklı içerik üretse bile yapısal alanlar tutarlı kalıyor.
DevOps standardı
Atomic deployment, preview environment ve yedekleme süreçleri her iki sunucuda da aynı standartlara göre işliyor.
SEO migration — sıfır trafik kaybı disiplini
Migration sürecini SEO ekibiyle haftalık koordinasyon içinde yürüttük. Bu, projenin ürün yönetimi tarafındaki en hassas iş kalemiydi: sıralamaları korumak yalnızca teknik bir redirect haritası kurmakla bitmiyordu — içerik, görsel ve URL hiyerarşisi arasındaki anlamsal bütünlüğün de bozulmadan taşınması gerekiyordu.
URL ve redirect haritası
Tüm eski URL'leri tek bir referans listede topladık. Ardından yapısal eşleşmeyle kategori ve breadcrumb mantığını birlikte kullanarak bu listeyi birebir 301 redirect haritasına dönüştürdük.
Breadcrumb ve kategori hiyerarşisi
Eski WordPress kurulumundaki kategori derinliğini ve breadcrumb yapısını, Payload tarafında ilişkisel collection'lar olarak yeniden modelledik. Böylece dahili link otoritesi ve arama motorlarının crawl yolları olduğu gibi korundu.
Görsel taşıma
Eski medya kütüphanesini taşırken görselleri AVIF ve WebP formatlarına dönüştürdük. Alt metinleri olduğu gibi koruduk ve tüm medyayı Next.js'in görsel optimizasyon pipeline'ına bağladık.
Sayfa bazlı structured data
Tedavi sayfaları için MedicalProcedure, doktor profilleri için Physician, hasta hikâyeleri için Review, kurumsal sayfalar içinse Organization ve LocalBusiness schema'larını her sayfa için otomatik üretiyoruz.
llms.txt ve LLM görünürlüğü
Siteyi, LLM tabanlı arama ajanlarının doğru içeriği keşfedebilmesi için bir llms.txt ile yapılandırdık. İçerik özetleri ve kanonik bağlantılar bu dosya üzerinden açıkça sunuluyor.
Hreflang ve cross-domain canonical
İki domain arasındaki dil ve pazar ilişkisini hreflang ile net biçimde tanımladık. Önceden duplicate content olarak işaretlenen sayfalar artık birbirini güçlendiriyor.
Sitemap, RSS, Open Graph
Sitemap, RSS ve Open Graph gibi tüm meta yapılar Payload içeriğinden otomatik üretiliyor. Editör bir sayfayı yayına aldığında ayrıca SEO adımı yürütmesine gerek kalmıyor.
Deployment ve operasyon
Deployment hattını eski sürecin en kırılgan noktalarına göre tasarladık: yayın sırasında oluşan kesintiler, elle yürütülen yedekleme süreçleri ve öngörülemeyen plugin güncellemeleri.
Atomic, sıfır kesintili deployment
Yeni bir build sağlık kontrolünden geçmeden trafik o sürüme yönlendirilmiyor. Bir hata durumunda da önceki sürüme tek bir komutla dönülebiliyor.
Önizleme ortamı
Her içerik değişikliği, yayına çıkmadan önce ekibin görebileceği bir önizleme URL'inde render ediliyor.
Render ve cache stratejisi
Sayfalar server-side render ediliyor; bir kez üretildikten sonra çıktılar hem Next.js'in iç cache'inde hem de Cloudflare edge cache üzerinde tutuluyor. İçerik ekibi Payload üzerinden bir güncelleme yaptığında, yalnızca ilgili sayfaların cache'i on-demand olarak invalide ediliyor ve sadece o sayfalar yeniden üretiliyor. Kullanıcılar çoğu istekte cache'ten hızlı yanıt alıyor, editörün yaptığı değişiklikler ise anında yayına yansıyor.
İzleme
Performans, trafik ve hata takibi Cloudflare Analytics ve Google Analytics üzerinden yürütülüyor. Özel bir dashboard ya da otomatik raporlama altyapısı kurmadık — yayın sonrası izleme, ekibin mevcut araçları üzerinden günlük rutinin içinde devam ediyor.
Product management açısı
Bu proje yalnızca bir teknoloji değişiminden ibaret değildi — aynı zamanda bir risk yönetimi, paydaş koordinasyonu ve süreç tasarımı projesiydi.
Risk
En büyük risk, organik trafik kaybıydı. Migration boyunca SEO ekibiyle haftalık check-point'ler kurduk; yayın gününden bir gün önce staging ortamı üzerinde tam crawl çalıştırarak redirect haritasını ve structured data'yı baştan sona doğruladık.
Paydaş yönetimi
Pazarlama, SEO, içerik ve klinik ekiplerini bir araya getirip içerik şemasını bu ekiplerin gerçek çalışma akışlarına göre tasarladık. Müşterinin 'iki pazar, iki panel' tercihini de bu koordinasyonun içinde teknik bir kısıt olarak değil, operasyonel bir gereksinim olarak çerçeveledik.
İçerik ekibine devir
Yayın sonrasında içerik ekibine eğitim ve detaylı dokümantasyon hazırladık. Böylece geliştiriciye olan bağımlılık yalnızca kod düzeyinde değil, operasyonel düzeyde de kırılmış oldu.