Klinik web sitesi SEO kontrol listesi: 20 teknik ve içerik kontrolü

Klinik web siteniz telefonda açılıyor, tasarımı düzgün görünüyor ve SEO aracından yüksek puan alıyor olabilir. Yine de önemli bir tedavi sayfası Google'ın dizininde bulunmayabilir; organik ziyaretçi formu gönderemeyebilir. Bu kontrol listesi, görünürlük sorunuyla iletişim sorununu birbirine karıştırmadan incelemek için hazırlandı.

Başlamadan önce ana sayfa, bir tedavi sayfası, bir hekim veya klinik bilgisi sayfası, bir rehber ve iletişim sayfasını seçin. Bunlar ilk örnekleminiz olsun; farklı şablon ve dil sürümlerini ayrıca ekleyin. Her kontrolü 'geçti', 'sorun var' veya 'doğrulanamadı' diye kaydedin. Ekran görüntüsü ya da test çıktısı olmayan maddeyi tamamlandı saymayın.

Bu yazı yeni bir SEO stratejisi kurmaktan çok mevcut sitenin çalışmasını denetler. Yerel görünürlük ve uluslararası dil mimarisi için aşağıdaki iki ayrı rehberi kullanabilirsiniz; buradaki liste ise bu yapıların teknik ve işlevsel kontrollerine odaklanır.

• Diş kliniği SEO stratejisi ve yerel görünürlük →
• Sağlık turizmi SEO: ülke ve dil mimarisi →

1. Erişim ve indeksleme: Google sayfayı görebiliyor mu?

• ✓ 1 — Sayfa doğru HTTP yanıtını veriyor mu?

  Yayımlanacak URL'yi oturum açmadan ziyaret edin. İçerik yerine hata ekranı dönen 200 yanıtını başarı saymayın. Sunucu hatalarını, yönlendirme döngülerini ve yanlış hedefe giden eski adresleri URL bazında kaydedin.

• ✓ 2 — robots.txt ile noindex birbirine karıştırılmış mı?

  Önemli sayfalarda istemeden kalmış robots engeli, meta robots veya X-Robots-Tag noindex kuralı arayın. robots.txt taramayı yönetir; tek başına dizinden çıkarma talimatı değildir. Google noindex kuralını okuyabilmek için sayfayı tarayabilmelidir. Özel veriyi korumak için bunlara değil erişim denetimine ihtiyaç vardır.

• ✓ 3 — Dizindeki kayıt ile canlı test ayrılmış mı?

  Search Console URL İnceleme'de Google'ın kayıtlı sürümünü ve canlı URL testini ayrı okuyun. Son tarama tarihi ile test tarihini yazın. Canlı testin başarılı olması, URL'nin zaten dizinde olduğunu veya kesinlikle dizine alınacağını göstermez.

• ✓ 4 — Ana içerik işlenmiş HTML'de bulunuyor mu?

  URL İnceleme'nin test edilen sayfa HTML'sinde başlığı, ana metni ve önemli bağlantıları arayın. Google JavaScript çalıştırabilir; ancak engellenen dosya veya kod hatası içeriğin oluşmasını önleyebilir. Kendi tarayıcınızda görünen metni Google da kesin gördü diye varsaymayın.

2. URL ve bağlantılar: doğru sayfa mı öne çıkıyor?

• ✓ 5 — Canonical tercihi tutarlı mı?

  Canonical, benzer içeriklerin tercih edilen adresini bildirir. Tedavi sayfasının yanlışlıkla ana sayfayı göstermediğini; yönlendirme, canonical ve iç linklerin aynı URL'yi desteklediğini kontrol edin. Google'ın seçtiği canonical farklı olabilir; bunu URL İnceleme'den karşılaştırın, etiketi kesin emir saymayın.

• ✓ 6 — Sitemap yalnız tercih edilen yayın adreslerini mi içeriyor?

  XML sitemap'te taşınmış, 404 veren veya dizine alınmasını istemediğiniz URL'leri ayıklayın. Önemli içerik değişikliğinde lastmod tarihini gerçeğe uygun güncelleyin. Sitemap göndermek, bütün sayfaların taranacağı veya dizine alınacağı garantisi değildir.

• ✓ 7 — Önemli sayfalara normal bağlantıyla ulaşılabiliyor mu?

  Tedavi, hekim ve iletişim sayfalarını menüden veya ilgili içerikten açın. Bağlantı gerçek bir href adresi taşımalı; hedefi yalnız tıklama kodunun içinde saklamayın. Link metni, gidilecek sayfayı anlaşılır biçimde adlandırsın. Sitemap'te bulunması bir sayfanın site içinde bağlantısız kalmasını çözmez.

• ✓ 8 — Başlık ve açıklama sayfanın gerçek amacını anlatıyor mu?

  Her öncelikli URL'nin title, ana başlık ve meta açıklamasını yan yana çıkarın. Aynı şablon metnini bütün tedavilere taşımayın. Google arama başlığını ve açıklama parçasını farklı kaynaklardan oluşturabilir; panelde yazdığınız metnin aramada aynen çıkacağını vaat etmeyin.

3. İçerik: ziyaretçi bilgiyi ve kaynağını doğrulayabiliyor mu?

• ✓ 9 — Her sayfanın ayrı bir kullanıcı ihtiyacı var mı?

  İki URL aynı soruya aynı cevabı veriyorsa niyetlerini karşılaştırın. Biri tedaviyi, diğeri belirli bir hazırlık sorusunu açıklayabilir. Yalnız ilçe adı veya birkaç anahtar kelime değiştirilmiş sayfaları çoğaltmak yerine mevcut içeriğin eksik cevabını tamamlayın.

• ✓ 10 — Sağlık içeriğinin kaynağı ve inceleyeni gerçek mi?

  Tıbbi ifadeleri yetkili mesleki incelemeye yönlendirin; kullanılan kaynakları ve gerçek güncelleme tarihini gösterin. Yazıyı incelemeyen hekime onay atfetmeyin. Google, sağlığı etkileyebilecek içeriklerde güvenilirliğe önem verir; yalnız yazar kutusu eklemek bu güveni veya sıralamayı garanti etmez.

• ✓ 11 — Klinik, hekim ve iletişim bilgileri tutarlı mı?

  Sayfadaki ad, doğrulanabilir unvan, adres, telefon ve hizmet bilgisini kliniğin güncel kayıtlarıyla karşılaştırın. Eski hekimin, kapanmış şubenin veya değişmiş numaranın yalnız footer'da değil içerik ve yapılandırılmış veride de kalmadığını kontrol edin.

• ✓ 12 — Yapılandırılmış veri görünür içerikle eşleşiyor mu?

  JSON-LD içindeki kurum, kişi, yazı ve iletişim bilgilerini sayfadaki metinle karşılaştırın. Görünmeyen puan, yorum veya uzmanlık eklemeyin. Rich Results Test yalnız desteklediği arama özelliklerini denetler; temiz sonuç her schema türünün doğrulandığı veya zengin sonuç gösterileceği anlamına gelmez.

4. Mobil kullanım: ziyaretçi iletişim adımını tamamlayabiliyor mu?

Bu bölümdeki form ve menü kontrolleri doğrudan sıralama faktörü listesi değildir. Organik aramayla gelen kişinin sayfayı kullanabilmesini denetler. Otomatik tarama ile gerçek cihazda yapılan testi raporda ayrı işaretleyin.

• ✓ 13 — Mobil menü ve iletişim bağlantıları gerçekten çalışıyor mu?

  Menüyü açıp kapatın, her bağlantıya basın ve geri dönün. Yatay ekranı, metin büyütmeyi ve klavyeyle gezinmeyi deneyin. Telefon klavyesi açıldığında gönder düğmesi veya hata mesajı ekran dışında kalıyor mu bakın. Yalnız taşma taramasının temiz olması işlev testi değildir.

• ✓ 14 — Hız ölçümünde laboratuvar ve gerçek kullanıcı ayrılmış mı?

  Core Web Vitals için iyi hedefler LCP'de en fazla 2,5 saniye, INP'de en fazla 200 milisaniye ve CLS'de en fazla 0,1'dir. Gerçek kullanıcı değerlendirmesi 75. yüzdelikte yapılır. PageSpeed'de alan verisi yoksa laboratuvar sonucunu onun yerine yazmayın; Lighthouse puanı tek başına saha performansı değildir.

• ✓ 15 — Formun hata ve başarı akışı doğrulandı mı?

  Boş ve hatalı giriş, ağ kesintisi, çift tıklama ve başarılı gönderimi izinli test ortamında deneyin. Hata sonrası bilgiler korunmalı; başarısız işlem başarılı gösterilmemeli. Taklit başarı yanıtı, e-postanın veya CRM kaydının gerçekten teslim edildiğini kanıtlamaz; teslimatı ayrıca doğrulayın.

• ✓ 16 — WhatsApp tıklaması gerçek mesajdan ayrılıyor mu?

  Butonun doğru numarayı ve gerekiyorsa doğru hazır metni açtığını kontrol edin. WhatsApp'a geçiş, kullanıcının mesajı gönderdiği anlamına gelmez. Tıklama, sohbet başlangıcı ve randevuyu aynı dönüşüm adı altında toplamayın; hangi adımı ölçebildiğinizi açıkça yazın.

• Form ve iletişim akışları için ayrıntılı dönüşüm kontrolü →

5. Rapor ve öncelik: hangi sorun önce düzeltilmeli?

• ✓ 17 — Organik kaynak bilgisi başvuruya kadar korunuyor mu?

  Arama üzerinden açılan sayfadan iletişime geçen örnek yolculuğu takip edin. İlk açılış sayfası ile başvurunun yapıldığı sayfayı ayırın. Analitik olaylarına ad, telefon, e-posta veya sağlık bilgisi eklemek yerine olay adı ve sayfa gibi gerekli teknik bağlamı kullanın; veri işleme uygunluğunu ayrıca değerlendirin.

• ✓ 18 — Arama görünürlüğü ile iş sonucu ayrı raporlanıyor mu?

  Search Console'da sorgu, sayfa, cihaz, ülke, gösterim ve tıklamaları inceleyin. Bunları aynı dönemdeki organik başvuru ve randevu sonuçlarıyla birlikte okuyun; bir tıklamayı bir hasta saymayın. Düşen ortalama konumu tek başına teknik hata kanıtı kabul etmeyin.

• ✓ 19 — Her bulgunun kanıtı, sahibi ve önceliği var mı?

  URL, tekrar üretim adımı, beklenen ve görülen sonuç, tarih, sorumlu kişi ve yeniden test ölçütünü tek kayda yazın. 'SEO zayıf' yerine 'iletişim formu ağ hatasında başarı mesajı gösteriyor' gibi çözülebilir bir iş tanımlayın.

• ✓ 20 — Düzeltme yayından sonra yeniden test edildi mi?

  Önizlemede çalışan düzeltmeyi canlı URL'de de doğrulayın. Menü veya ortak şablon değiştiyse farklı sayfa türlerini yeniden örnekleyin. Google'ın yeniden taraması gereken değişikliklerde teknik doğrulama tarihini, dizin güncellemesini ve performans sonucunu ayrı izleyin.

Örneğin tedavi sayfası Google'da görünmüyorsa önce erişim, indeksleme ve canonical kanıtlarını inceleyin. Sayfa tıklama alıyor fakat iletişim oluşmuyorsa mesaj, mobil kullanım, form ve ölçümü araştırın. Aynı belirti farklı nedenlerden doğabilir; daha fazla blog yazmak her iki durumun da otomatik çözümü değildir.

• Klinik web sitesinde KVKK, çerez ve aydınlatma →
• Sağlık tanıtımında ayrı mevzuat kontrolü →
• Ücretsiz performans analizi al →