Özet
Fatih'te bir diş kliniği için Next.js + Cloudflare Pages üzerinde TR/EN çift dilli kurumsal site geliştirdim. Route groups ile statik dil ayırımı, MedicalProcedure/Physician/BreadcrumbList schema markup ve yerel SEO odaklı NAP tutarlılığı ile her iki dilde de Lighthouse 90+ performans elde ettik.
İstanbul'da yerel bir diş kliniği için web sitesi yapmak, ilk bakışta sıradan bir kurumsal web sitesi projesi gibi görünür. Ama doğru yapıldığında çok daha fazlasıdır: Google'da semt bazlı aramalarda öne çıkan, telefonla aramaları azaltıp randevu taleplerini artıran, kliniğin uzman kadrosunu hastaya tanıtan bir satış kanalına dönüşür.
Günaydın Diş Kliniği, Fatih'te (Akşemsettin Mahallesi, Halıcılar Caddesi) hizmet veren bir ağız ve diş sağlığı polikliniğidir. Hedef: Fatih ve çevresindeki ilçelerden gelen hastaları yakalamak, "fatih diş kliniği" ve "istanbul implant" gibi yerel-ticari aramalarda görünür olmak, kliniğin uzman kadrosunu (implant, ortodonti, estetik diş hekimliği) zengin içeriklerle tanıtmak.
Bu yazı, projenin teknik mimarisini ve yerel işletmeler için kurumsal web sitesi yapımındaki kritik kararları detaylandırıyor.
Proje Gereksinimleri
İlk müşteri görüşmesinde dört temel gereksinim ortaya çıktı:
İlki yerel SEO odaklı yapı. Klinik Fatih'te konumlanıyor ve hedef kitlesi büyük oranda Fatih ile çevre ilçelerden (Eyüpsultan, Bayrampaşa, Zeytinburnu) geliyor. URL yapısı, içerik organizasyonu ve schema markup bu yerel hedefe göre kurulmalıydı. Hizmet yelpazesi de geniş — implant, ortodonti, şeffaf plak tedavisi, beyazlatma, kanal tedavisi, çocuk diş hekimliği — her birinin kendi ranking potansiyeli var.
İkincisi çift dilli içerik — Türkçe ana site, İngilizce sürüm de erişilebilirlik için. Klinikte zaman zaman İstanbul'da yaşayan yabancı hastalar randevu alıyor, onlara ana sayfayı kendi dillerinde sunmak fark yaratıyor. Asıl hacim TR'den geliyor, bu yüzden TR-öncelikli ama EN ihmal edilmemiş bir yapı kuruldu.
Üçüncüsü tıbbi içerik için yapısal veri. Diş tedavi türleri (implant, ortodonti, beyazlatma, kanal tedavisi), klinik kadrosu ve hizmet sayfaları arama sonuçlarında zengin önizlemelerle çıkmalıydı. Bu da schema.org işaretlemesi gerektiriyordu.
Dördüncüsü mobil performans. Yerel arama davranışı çoğunlukla mobil cihazda gerçekleşiyor — bir hasta diş apsesi gibi acil bir durumda "fatih diş kliniği nöbetçi" araması yaparken sayfa açılışını beklemiyor. Kötü performans = yüksek bounce rate = kaybedilen randevu.
Teknik Stack
Platform için Next.js seçtim. Diğer freelance projelerimde — Hotel Perula, Optima Gravitas, MCG Hukuk gibi — kanıtlanmış bir stack'ti. Static export modunda Cloudflare Pages üzerinde sıfır server maliyeti ile yayınlanabiliyor, edge'de saniyenin altında açılıyor, SEO açısından server-side rendered HTML ile çalışıyor.
Tailwind CSS v4 ile arayüz, TypeScript ile tip güvenliği. Görseller WebP formatında, hero görseli için priority flag'i ve fetchpriority="high" ile LCP optimizasyonu. Klinik formlu bir iletişim akışı yerine WhatsApp üzerinden hasta görüşmesi yapmayı tercih ettiği için site mimarisinde form sistemi bilinçli olarak yok — bu da sayfa yükünü daha da hafifletti.
Bu stack'in en büyük avantajı static output. Build sırasında her sayfa HTML olarak üretiliyor, Cloudflare CDN'in 300+ edge node'una yayılıyor, kullanıcıya en yakın node'dan servis ediliyor. Veritabanı yok, sunucu işlemi yok, latency neredeyse sıfır.
Çoklu Dil Mimarisi: Route Groups
Çift dilli sitelerde en yaygın hata <html lang> etiketinin doğru ayarlanmaması. Tek bir layout dosyasında <html lang="tr"> yazılırsa İngilizce sayfalar yine lang="tr" olarak görünür. Google bu sayfaların İngilizce olduğunu anlamaz, screen reader'lar yanlış telaffuz eder, hreflang etiketleri çalışmaz.
İlk yaklaşımım Next.js middleware ile dinamik bir çözümdü: pathname'den dili çıkar, response header'a yaz, layout'a aktar. Mantıklı görünüyordu ama Cloudflare Pages build'i kırdı. Static export modunda dinamik middleware çalışmıyor — bu sayfaların build sırasında HTML olarak render edilmesi gerekiyor, runtime'da değil.
Çözüm Next.js'in route groups özelliği oldu. Klasör yapısını şu şekilde ayrıştırdım:
app/
├── (tr)/
│ ├── layout.tsx ← <html lang="tr"> + TR metadata
│ └── tr/
│ ├── page.tsx
│ └── hizmetler/
└── (en)/
├── layout.tsx ← <html lang="en"> + EN metadata
└── en/
├── page.tsx
└── services/
Parantez içindeki (tr) ve (en) URL'e yansımıyor — sadece organizasyon için. Her grubun kendi layout.tsx'i var ve her layout <html lang> etiketini kendi diline göre statik olarak yazıyor. Build çıktısında /tr/... sayfaları gerçekten lang="tr", /en/... sayfaları gerçekten lang="en" HTML üretiyor.
Aynı yapıyı kendi sitemde de kullanıyorum — bu yazıyı okuduğunuz efegerek.com bunun üzerinde çalışıyor.
Hreflang ve Sitemap
Çift dilli SEO'nun ikinci kritik parçası hreflang. Her sayfanın diğer dildeki muadiline işaret etmesi gerekiyor:
<link rel="alternate" hreflang="tr" href="https://gunaydindentalclinic.com/tr/hizmetler" />
<link rel="alternate" hreflang="en" href="https://gunaydindentalclinic.com/en/services" />
<link rel="alternate" hreflang="x-default" href="https://gunaydindentalclinic.com/tr/hizmetler" />
x-default kritik bir etiket — dili tespit edilemeyen bir kullanıcı (örneğin VPN üzerinden gelen, dil ayarı bilinmeyen bir tarayıcı) hangi sayfaya yönlendirilecek? Yerel pazara odaklanan bir klinik için bu varsayılan TR olmalı. Hata yapan birçok bilingüel site x-default değerini yanlış ayarlayıp ana hedef pazarlarındaki sıralamalarını düşürüyor.
Sitemap için her dilin kendi sitemap.xml'i var: /tr-sitemap.xml ve /en-sitemap.xml. Ana sitemap_index.xml her ikisini referans ediyor. Bu yapı Google Search Console'da iki ayrı "property" gibi izlenmesini sağlıyor — Türkçe trafiği ve İngilizce trafiği bağımsız analiz edebiliyorum.
Tıbbi Schema Markup
En çok kafa yorduğum bölüm structured data oldu. Bir diş kliniği için doğru schema kombinasyonu şu:
MedicalBusiness — kliniğin kendisi. Adres, telefon, açılış saatleri, kabul edilen ödeme türleri.
MedicalProcedure — sunulan her tedavi (implant, ortodonti, kanal tedavisi, beyazlatma, zirkonyum kron, lamine, çocuk diş hekimliği) ayrı bir schema. Tedavinin adı, açıklaması, hazırlık gereksinimleri.
Physician — klinik kadrosundaki her doktor. Uzmanlık alanı, mezuniyet bilgileri, çalıştığı klinik.
BreadcrumbList — her sayfanın navigasyon hiyerarşisi. Google arama sonuçlarında "Ana Sayfa > Hizmetler > İmplant Tedavisi" şeklinde breadcrumb gösteriyor.
FAQPage — sıkça sorulan sorular. Klinik fiyatları, randevu süreçleri, sigorta kapsamları gibi başlıklar Google'da rich result olarak çıkıyor.
Tüm schema'ları her sayfanın <head> kısmında JSON-LD olarak yerleştirdim. Google'ın Rich Results Test aracında her sayfayı tek tek doğruladım. Bu işin manuel yapılması zor — bu yüzden schema oluşturma sürecini otomatize ettim. Yeni bir tedavi sayfası eklediğimde sadece içerik girmem yetiyor, schema markup otomatik üretiliyor.
SEO hizmetleri sürecinde bu tarz teknik SEO öğeleri kontrol listemin başında geliyor.
Yerel SEO: Fatih ve Çevre İlçeler
Yerel işletme SEO'sunda en kritik unsur Google Business Profile ile websitesi arasındaki uyum. Klinik adı, adres, telefon (NAP) bilgileri tam olarak aynı yazılış ile her iki yerde de bulunmalı. Bir karakter farkı bile Google'ın bu iki kaynağın aynı işletmeye ait olduğundan emin olmasını engelliyor.
Site yapısında bu uyumu garantilemek için:
- Footer'da klinik adı, tam adres ve telefon — Google Business Profile ile birebir aynı format
LocalBusinessschema'sında aynı bilgiler structured data olarak- İletişim sayfasında Google Maps gömülü harita — koordinatlar Business Profile ile eşleşiyor
Bunlara ek olarak içerik tarafında Fatih'in çevre ilçeleriyle bağlantı kuran sayfalar oluşturduk. "Eyüpsultan'da diş kliniği arayanlar için Günaydın", "Bayrampaşa'dan en yakın diş hekimi" gibi yerel coğrafi bağlam içeren içerikler — bunlar İstanbul ilçeleri için web tasarım yaklaşımının küçük bir versiyonu.
Cloudflare Pages Deploy Süreci
Build pipeline şu şekilde çalışıyor: GitHub'a push → Cloudflare Pages otomatik build tetikliyor → next build çalışıyor → out/ klasörü Cloudflare CDN'e dağıtılıyor → 30 saniye sonra canlıda.
İlk build'de iki sorun çıktı.
Birincisi next.config.js'de unoptimized: true flag'i. Cloudflare Pages static export modunda Next.js'in image optimization servisi çalışmıyor — çünkü çalışan bir Node sunucu yok. Bu flag olmadan build başarısız oluyor. Image optimization yerine görselleri build öncesi WebP formatında elle hazırladım, farklı çözünürlüklerde önbelleğe aldım.
İkincisi middleware. İlk denememde dil tespiti için middleware kullanmıştım. Static export bunu desteklemediği için route groups yaklaşımına geçtim — yukarıda anlattığım çözüm.
Build süresi şu anda ortalama 90 saniye, deploy 20 saniye. Push'tan canlıya iki dakikadan az sürede geçiyor. Bu hız hem hata düzeltme hem de içerik güncelleme süreçlerini çok rahatlattı.
Performans Sonuçları
Lighthouse mobil skorları (her iki dilde de):
- Performance: 90+
- Accessibility: 100
- Best Practices: 100
- SEO: 100
Core Web Vitals hedefleri tutturuldu — LCP, CLS, INP üçü de Google'ın "Good" eşiklerinin altında. Bu rakamlar Cloudflare CDN + statik HTML + WebP görseller + minimal JavaScript kombinasyonunun doğal sonucu.
İlk üç ayda Google Search Console'da Türkçe yerel sorgularda görünürlük belirgin şekilde arttı. "Fatih diş kliniği", "fatih implant", "akşemsettin diş hekimi" gibi yerel uzun kuyruk kelimelerde ilk sayfada birden fazla sayfa çıkmaya başladı. Telefonla aramaların yanı sıra WhatsApp üzerinden gelen randevu talepleri katlandı.
Öğrenilen Dersler
Static export sınırlamalarını başta düşünün. Middleware, image optimization API, server actions — bunların hiçbiri Cloudflare Pages static modda çalışmıyor. Mimari kararları önceden bilerek almak iki haftalık geri dönüş çalışmasından kurtarıyor.
Schema markup'ı baştan planlayın. Sayfayı yapıp sonradan schema eklemek yerine, içerik mimarisini schema türlerine göre tasarlamak çok daha temiz oluyor. Bir hizmet sayfası MedicalProcedure olacaksa, içerik bölümleri de bu schema'nın alanlarına uygun olmalı.
Yerel SEO için NAP tutarlılığı kritik. Google Business Profile, web sitesi footer'ı, schema markup, harita servisleri (Yandex, Apple Maps) — hepsinde tam olarak aynı isim, adres, telefon olmalı. Bir karakterlik tutarsızlık ranking'i ciddi şekilde düşürüyor.
Statik site = uzun ömürlü site. Sunucu yok, veritabanı yok, runtime bağımlılığı yok. Bu siteyi 3 yıl sonra hiç dokunmadan açabilirim ve aynı şekilde çalışacak. Müşterilerime bu anlamda gönül rahatlığı veriyor — hosting iflas etse bile kod elimde, başka bir CDN'e dakikalar içinde taşınır.
Sonuç
Yerel bir diş kliniği için web sitesi yapmak güzel bir tasarımla bitmiyor — yerel SEO altyapısı, doğru schema işaretlemesi ve hızlı performans birlikte çalışmak zorunda. Günaydın Diş Kliniği projesi bu üç boyutta da titiz çalışmayı gerektirdi.
Diğer benzer projelerimi referanslar sayfasında görebilirsiniz. Klinik, otel, hukuk bürosu veya başka bir kurumsal web sitesi düşünüyorsanız iletişim formu üzerinden konuşalım — proje gereksinimlerinizi birlikte değerlendirebiliriz.
