WordPress güçlü ve esnek bir içerik yönetim sistemi olsa da bir sitenin teknik SEO performansı yalnızca WordPress çekirdeğine bağlı değildir. Tema, eklentiler, sayfa oluşturucular, özel şablonlar, hosting altyapısı ve site mimarisi birlikte çalışarak arama motorlarına sunulan nihai teknik çıktıyı oluşturur.
Bu nedenle WordPress teknik SEO çalışması, bir SEO eklentisinin ayarlarını kontrol etmekten çok daha kapsamlıdır. Önemli sayfaların indekslenebilirliği, kategori ve etiket arşivlerinin amacı, canonical etiketleri, XML site haritaları, yönlendirmeler, iç bağlantılar, yapılandırılmış veri ve performans şablon düzeyinde incelenmelidir.
Bu WordPress teknik SEO kontrol listesi, sitenizdeki sorunların tema, eklenti, içerik türü, site yapısı veya performans kaynaklı olup olmadığını belirlemenize yardımcı olur.
Shopify altyapısı kullanan mağazalarda ürün, koleksiyon ve filtre URL’leri farklı davranır; bu yapı için Shopify Teknik SEO Kontrol Listesini kullanın.
Kısa WordPress Teknik SEO Kontrol Listesi
İncelemeye aşağıdaki temel sorularla başlayın:
- WordPress’in Arama Motoru Görünürlüğü ayarı kapalı mı?
- Önemli sayfalarda yanlışlıkla noindex bulunuyor mu?
- Hangi yazı türleri, kategoriler ve arşivler indeksleniyor?
- Gereksiz etiket, yazar veya tarih arşivleri URL şişmesine neden oluyor mu?
- Canonical etiketleri doğru URL’leri gösteriyor mu?
- Tek ve tutarlı bir XML sitemap sistemi kullanılıyor mu?
- Sitemap içinde yalnızca canonical ve indekslenebilir URL’ler mi bulunuyor?
- Kalıcı bağlantı değişiklikleri doğru 301 yönlendirmeleriyle yönetilmiş mi?
- Önemli sayfalar yeterli iç bağlantı alıyor mu?
- Tema, eklentiler veya sayfa oluşturucu yinelenen teknik çıktılar üretiyor mu?
- Core Web Vitals sorunları belirli sayfa şablonlarında yoğunlaşıyor mu?
- Schema markup ve JSON-LD çıktıları görünür içerikle uyumlu mu?
- Yapılan düzeltmeler Search Console ve yeniden tarama ile doğrulanmış mı?
Bütün URL’lerin indekslenmesi veya bütün araç uyarılarının sıfırlanması hedeflenmemelidir. Öncelik, kullanıcı ve işletme açısından değerli canonical sayfaların doğru biçimde taranması, indekslenmesi ve site içinde desteklenmesidir.
WordPress Teknik SEO Nedir?
WordPress teknik SEO; WordPress sitesinin arama motorları tarafından erişilebilir, taranabilir, indekslenebilir ve anlaşılabilir olmasını etkileyen teknik yapıların incelenmesidir.
Çalışma yalnızca eklenti ayarlarından oluşmaz. Aşağıdaki bileşenlerin ürettiği nihai çıktı birlikte değerlendirilir:
- WordPress core
- Tema ve child theme
- SEO ve performans eklentileri
- Sayfa oluşturucular
- Özel yazı türleri
- Taksonomiler
- Sayfa şablonları
- Hosting ve sunucu ayarları
- CDN ve cache sistemleri
- İçerik ve iç bağlantı yapısı
WordPress; sayfalar, yazılar, kategoriler, etiketler, yazarlar ve özel içerik türleri için ayrı URL’ler oluşturabilir. Kategoriler benzer yazıları gruplandırmaya yardımcı olurken etiketler de kendi arşiv sayfalarını oluşturabilir. Bu URL türlerinin her biri otomatik olarak indekslenmemeli veya otomatik olarak noindex yapılmamalıdır; bağımsız arama değeri taşıyıp taşımadıkları değerlendirilmelidir. (WordPress.org)
1. Arama Motoru Görünürlüğü Ayarını Kontrol Edin
WordPress indeksleme sorunlarında ilk kontrol edilmesi gereken alanlardan biri:
Ayarlar → Okuma → Arama Motoru Görünürlüğü
bölümüdür.
“Arama motorlarının bu siteyi indekslemesini engellemeye çalış” seçeneği etkinse WordPress, arama motorlarından siteyi indekslememelerini ister ve sayfaların <head> bölümüne noindex yönergesi ekleyebilir. Bu ayar özellikle geliştirme veya staging ortamından canlı siteye geçiş sırasında açık unutulabilir. (WordPress.org)
Bu seçeneğin işaretli olması siteyi ziyaretçilere kapatmaz. Dolayısıyla web sitesi tarayıcıda normal görünürken Google tarafından indekslenmiyor olabilir.
Kontrol sırasında şunlara bakın:
- Arama Motoru Görünürlüğü seçeneği işaretli mi?
- Ayar canlı sitede mi, staging ortamında mı uygulanıyor?
- Tema gerekli wp_head() fonksiyonunu doğru biçimde çağırıyor mu?
- SEO eklentisi ayrıca site genelinde noindex üretiyor mu?
- CDN veya cache eski noindex çıktısını göstermeye devam ediyor mu?
- HTTP yanıt başlığında X-Robots-Tag: noindex bulunuyor mu?
Ayarı değiştirdikten sonra yalnızca WordPress yönetim paneline güvenmeyin. Sayfanın kaynak kodunu, HTTP başlıklarını ve Google Search Console’daki URL Denetleme çıktısını kontrol edin.
2. Meta Robots ve X-Robots-Tag Yönergelerini İnceleyin
WordPress sitelerinde noindex farklı kaynaklardan üretilebilir:
- WordPress’in genel görünürlük ayarı
- SEO eklentisinin sayfa ayarı
- Yazı türü veya taksonomi ayarı
- Tema şablonu
- Özel kod
- Hosting veya sunucu yapılandırması
- HTTP yanıtındaki X-Robots-Tag
Standart HTML uygulaması şu şekildedir:
<meta name="robots" content="noindex">HTML dışındaki dosyalarda veya sunucu düzeyindeki uygulamalarda aynı yönerge HTTP başlığıyla gönderilebilir:
X-Robots-Tag: noindexGoogle’ın noindex yönergesini işleyebilmesi için sayfayı tarayabilmesi gerekir. URL robots.txt tarafından engellenmişse Googlebot sayfaya erişemeyebilir ve noindex etiketini göremeyebilir. Google ayrıca robots.txt içinde noindex kullanımını desteklemez. (Google for Developers)
WordPress sitenizde önemli bir sayfa indekslenmiyorsa şu kaynakları ayrı ayrı kontrol edin:
- Oluşturulan HTML
- Tema dosyaları
- SEO eklentisinin gelişmiş ayarları
- Kategori ve etiket ayarları
- Özel yazı türü ayarları
- HTTP response header
- Cache edilmiş sayfa sürümü
- Search Console URL Denetleme verisi
3. Hangi WordPress Sayfaları İndekslenmelidir?
WordPress sitelerinde her içerik türü için tek bir indeksleme kuralı uygulanmamalıdır.
İndekslenme kararı şu soruya göre verilmelidir:
Bu URL, kullanıcının arama sonuçlarında bağımsız olarak görmek isteyebileceği özgün ve faydalı bir sayfa mı?
Sayfalar
Hizmet, ürün, kategori, iletişim veya bilgi amaçlı temel sayfalar genellikle indekslenmelidir.
Ancak şu sayfalar indeks dışında bırakılabilir:
- Teşekkür sayfaları
- Form sonucu sayfaları
- Dahili kampanya varyasyonları
- Üyelik veya hesap sayfaları
- İnce ve geçici açılış sayfaları
- Staging veya test sayfaları
Yazılar
Özgün bilgi sunan ve belirli bir arama niyetini karşılayan blog yazıları indekslenmelidir.
Şunlar kontrol edilmelidir:
- Yazı başka bir içerikle aynı sorguyu mu hedefliyor?
- Canonical etiketi kendisini mi gösteriyor?
- Kategori ve ilgili yazılardan iç bağlantı alıyor mu?
- Güncel ve bağımsız değer sunuyor mu?
- Sitemap içinde bulunuyor mu?
Özel Yazı Türleri
Tema veya eklentiler şu türlerde özel yazı tipleri oluşturabilir:
- Portföy
- Ekip üyeleri
- Referanslar
- Etkinlikler
- Kurslar
- Lokasyonlar
- Ürünler
- Şablonlar
Bir özel yazı türünün WordPress yönetim panelinde bulunması, arama sonuçlarında görünmesi gerektiği anlamına gelmez.
Her özel yazı türü için şu kararlar ayrı verilmelidir:
- Tekil sayfalar indekslenecek mi?
- Arşiv sayfası indekslenecek mi?
- Sitemap’e dâhil edilecek mi?
- İç bağlantılarla desteklenecek mi?
- Canonical ve schema çıktısı doğru mu?
Medya ve Ek Dosya Sayfaları
WordPress, yüklenen medya dosyaları için ayrı ek dosya sayfaları oluşturabilir. Bu sayfalar çoğu sitede yalnızca görsel veya dosya başlığı içeren düşük değerli URL’lere dönüşebilir.
Kontrol edin:
- Medya ek sayfaları aktif mi?
- Eski ek sayfaları hâlâ indeksleniyor mu?
- Ek sayfaları medya dosyasına veya ilgili içeriğe yönlendiriliyor mu?
- Görseller için ayrı indekslenebilir sayfa oluşturmak gerçekten gerekli mi?
4. WordPress Kategori ve Etiket Sayfaları İndekslenmeli mi?
Kategori ve etiket arşivleri için evrensel bir doğru cevap yoktur.
WordPress kategorileri yazıları konu grupları altında düzenler. Etiketler ise hiyerarşik olmayan ek sınıflandırmalar sunar ve her etiket kendi arşiv URL’sini oluşturabilir. (WordPress.org)
Kategori Sayfaları Ne Zaman İndekslenebilir?
Kategori sayfası aşağıdaki koşulları karşılıyorsa bağımsız arama değeri taşıyabilir:
- Net ve özgün bir konuya odaklanıyorsa
- Birden fazla ilgili içeriği anlamlı biçimde gruplandırıyorsa
- Açıklayıcı kategori metni bulunuyorsa
- Kullanıcıların arama sonuçlarından erişmek isteyebileceği bir merkez sayfaysa
- Düzenli olarak güncelleniyorsa
- İlgili yazılara mantıklı bağlantılar sunuyorsa
- Başka kategori veya hizmet sayfasıyla aynı amacı taşımıyorsa
Örneğin “Teknik SEO” kategorisi; indeksleme, site taşıma, Core Web Vitals ve schema rehberlerini mantıklı biçimde gruplandırıyorsa değerli bir konu merkezi olabilir.
Etiket Sayfaları Ne Zaman Sorun Oluşturur?
Etiket arşivleri şu durumlarda URL şişmesine neden olabilir:
- Her yazı için yeni etiket oluşturuluyorsa
- Etiketlerin yalnızca bir yazısı bulunuyorsa
- Kategori ve etiket aynı içerikleri listeliyorsa
- Etiketler aynı veya çok benzer anlamlara sahipse
- Etiket arşivlerinde açıklama veya özgün değer yoksa
- Yazı başlıkları ve özetleri dışında içerik sunulmuyorsa
Bu URL’ler otomatik olarak silinmemeli veya noindex yapılmamalıdır. Önce trafik, iç bağlantılar, içerik kapsamı ve site mimarisindeki rolleri değerlendirilmelidir.
Yazar Arşivleri
Tek yazarlı sitelerde yazar arşivi çoğu zaman blog ana sayfası veya genel yazı arşiviyle büyük ölçüde aynı içerikleri listeler.
Çok yazarlı sitelerde ise yazar sayfaları şu unsurlarla değer kazanabilir:
- Yazar biyografisi
- Uzmanlık alanı
- Profesyonel profil bağlantıları
- Yazarlık deneyimi
- Yayınlanan içerikler
- Person veya ProfilePage schema
Tek yazarlı bir sitede yazar arşivini indekslemek yerine yazar bilgisini makalelerde ve ayrı bir hakkımda sayfasında sunmak daha anlamlı olabilir.
Tarih Arşivleri
Aylık veya yıllık tarih arşivleri genellikle kullanıcıların konuya göre gezinmesine yardımcı olmaz. Özellikle evergreen içerik sitelerinde benzer yazı listeleri oluşturarak gereksiz URL sayısını artırabilir.
Ancak haber veya yoğun kronolojik yayın yapan sitelerde tarih arşivlerinin işlevi farklı olabilir.
Site İçi Arama Sonuçları
Site içi arama sonuçları genellikle:
Çok sayıda URL varyasyonu üretir.
Yinelenen veya düşük değerli listeler oluşturur.
Kullanıcı sorgularını URL parametrelerinde çoğaltır.
Google’ın gereksiz URL’leri taramasına neden olabilir.
Bu nedenle site içi arama sonuçlarının çoğu projede indekslenmemesi tercih edilir.
5. Arşiv ve Taksonomi Şişmesini Kontrol Edin
WordPress teknik SEO hatalarının önemli bir bölümü, içerik sayısından çok daha fazla arşiv ve taksonomi URL’si üretilmesinden kaynaklanır.
Örneğin 100 yazılı bir sitede aynı anda şu URL türleri bulunabilir:
- 100 yazı
- 15 kategori
- 150 etiket
- Yazar arşivleri
- Tarih arşivleri
- Sayfalama URL’leri
- Özel taksonomiler
- Medya ek sayfaları
- Site içi arama sonuçları
Bu yapı, yüzlerce zayıf veya yinelenen URL oluşturabilir.
Kontrol edilmesi gereken başlıca durumlar:
- Yalnızca bir içerik barındıran kategoriler
- Tek kullanımlık etiketler
- Aynı kelimenin tekil ve çoğul etiketleri
- Kategoriyle aynı konuyu hedefleyen etiketler
- Eklentilerin oluşturduğu kullanılmayan taksonomiler
- Boş arşivler
- İnce sayfalama URL’leri
- Aynı içerikleri listeleyen yazar ve tarih arşivleri
Her URL türü için dört seçenek değerlendirilmelidir:
İndekslenebilir biçimde geliştir.
noindex, follow uygula.
Daha güçlü bir sayfayla birleştir ve yönlendir.
Kullanılmıyorsa tamamen kaldır.
Karar yalnızca URL sayısını azaltmak için verilmemelidir. Kullanıcı deneyimi, mevcut trafik, backlinkler ve site içi navigasyon birlikte değerlendirilmelidir.
6. Kalıcı Bağlantı Yapısını İnceleyin
WordPress kalıcı bağlantıları; yazıların, sayfaların, kategorilerin ve diğer arşivlerin kalıcı URL’leridir. WordPress dokümantasyonu, kalıcı bağlantıların insanlar ve arama motorları tarafından anlaşılabilir URL yapıları oluşturmasına yardımcı olduğunu ve kalıcı olarak düşünülmesi gerektiğini belirtir. (WordPress.org)
WordPress yönetim panelinde:
Ayarlar → Kalıcı Bağlantılar
alanından URL yapısı değiştirilebilir.
Ancak yayındaki bir sitede kalıcı bağlantı yapısını değiştirmek yalnızca bir ayar değişikliği değildir. Eski URL’ler için yönlendirme planı gerekir.
Kontrol Edilecek Alanlar
- Yazı URL’lerinde gereksiz tarih veya kategori kullanımı
- Çok uzun ve anlamsız slug’lar
- Türkçe karakterlerden kaynaklanan tutarsızlıklar
- Büyük-küçük harf varyasyonları
- Trailing slash tutarlılığı
- HTTP–HTTPS yönlendirmeleri
- WWW ve non-WWW sürümleri
- Kategori ve etiket tabanları
- Özel yazı türü rewrite kuralları
- Eski slug’lardan yeni URL’lere yönlendirmeler
Slug Değiştirildiğinde Ne Yapılmalıdır?
Yayınlanmış bir sayfanın slug’ı değiştirildiğinde:
Eski URL yeni URL’ye 301 ile yönlendirilmelidir.
Eski URL’ye giden iç bağlantılar güncellenmelidir.
XML sitemap yalnızca yeni URL’yi içermelidir.
Canonical yeni URL’yi göstermelidir.
Yönlendirme zinciri oluşmadığı doğrulanmalıdır.
Search Console’da eski ve yeni URL’ler kontrol edilmelidir.
Her eski URL’yi ana sayfaya yönlendirmek doğru değildir. Yönlendirme, kullanıcı niyetini karşılayan en yakın eşdeğer sayfaya yapılmalıdır.
7. Yönlendirme Zincirlerini ve Kırık Bağlantıları Kontrol Edin
WordPress sitelerinde içerik başlıkları, slug’lar ve kategori yapıları zaman içinde değişebilir. Bazı yönlendirme eklentileri veya hosting araçları bu değişiklikleri otomatik olarak kaydedebilir.
Zamanla şu zincir oluşabilir:
/eski-url/
→ /onceki-url/
→ /yeni-url/
İç bağlantılar hâlâ ilk URL’ye gidiyorsa kullanıcılar ve arama motorları gereksiz yönlendirme adımlarından geçer.
Kontrol edin:
- 301 yönlendirme zincirleri
- 302 ile kalıcı olarak yönlendirilen URL’ler
- Yönlendirme döngüleri
- Kırık iç bağlantılar
- Silinmiş görsel ve dosya URL’leri
- Eski kategori bağlantıları
- Menüdeki yönlendirilmiş adresler
- Canonical etiketiyle çelişen yönlendirmeler
- HTTP’den HTTPS’ye birden fazla adım
İç bağlantılar mümkün olduğunda doğrudan son canonical URL’ye güncellenmelidir.
8. Canonical Etiketlerini Kontrol Edin
Canonical etiketi, yinelenen veya çok benzer URL’ler arasında tercih edilen adresi belirtmeye yardımcı olur.
Google canonical seçerken yalnızca rel="canonical" etiketini değil; yönlendirmeler, XML sitemap, iç bağlantılar ve içerik benzerliği gibi sinyalleri birlikte değerlendirebilir. Bu sinyaller aynı URL etrafında birleştiğinde canonical tercihi daha tutarlı hâle gelir. (Google for Developers)
WordPress sitelerinde canonical etiketi şu kaynaklardan üretilebilir:
- WordPress çekirdeği
- SEO eklentisi
- Tema
- Özel kod
- E-ticaret eklentisi
- Çok dilli site eklentisi
Yaygın Canonical Sorunları
- Aynı sayfada birden fazla canonical etiketi
- Canonical URL’nin yönlendirme yapması
- Canonical URL’nin 404 olması
- Kategorilerin ana sayfaya canonical vermesi
- Sayfalama URL’lerinin yanlışlıkla ilk sayfaya canonical vermesi
- HTTP ve HTTPS sürümlerinin çakışması
- Parametreli URL’nin kendisini canonical göstermesi
- Sitemap ve iç bağlantıların farklı URL sürümünü kullanması
- Çok dilli sayfalarda yanlış dil sürümüne canonical verilmesi
Her indekslenebilir sayfada otomatik olarak self-referencing canonical bulunması yeterli değildir. Sitemap, yönlendirme ve iç bağlantı sinyallerinin de aynı URL’yi desteklemesi gerekir.
9. XML Sitemap Yapısını Kontrol Edin
WordPress 5.5’ten itibaren WordPress çekirdeği temel ve genişletilebilir bir XML sitemap sistemi içerir. Varsayılan sitemap index adresi genellikle:
/wp-sitemap.xmlşeklindedir. WordPress’in temel sitemap sistemi varsayılan olarak herkese açık yazı türleri, taksonomiler, ana sayfa ve yazar arşivleri için sitemap üretebilir. (Make WordPress)
SEO eklentileri kendi sitemap sistemlerini sunabilir ve bazıları WordPress core sitemap’ini devre dışı bırakarak kendi çıktısını kullanır. Bu nedenle yalnızca /sitemap.xml adresini kontrol etmek yeterli değildir. Aktif sitemap sisteminin hangisi olduğunu belirlemek gerekir. (Make WordPress)
Kontrol Edilecek Sitemap Sorunları
- WordPress core ve eklenti sitemap’lerinin aynı anda açık olması
- Search Console’a eski sitemap’in gönderilmiş olması
- noindex URL’lerin sitemap içinde yer alması
- Yönlendirme yapan URL’ler
- 404 sayfaları
- Canonical olmayan URL’ler
- Gereksiz etiket ve yazar sitemap’leri
- Özel yazı türlerinin yanlışlıkla dâhil edilmesi
- İndekslenmesi gereken özel yazı türlerinin eksik olması
- HTTP veya alan adı varyasyonları
- Son güncelleme verilerinin hatalı olması
Google, sitemap içinde tercih edilen canonical URL’lerin bulunmasını önerir. Sitemap göndermek yalnızca bir sinyaldir; URL’lerin taranmasını veya indekslenmesini garanti etmez. (Google for Developers)
Sağlıklı bir WordPress sitemap’inde mümkün olduğunca:
WordPress sitenizdeki teknik sorunları uzmanına bırakın.
İndeksleme, canonical, sitemap, tema, eklenti ve performans sorunlarını tespit ediyor; gerekli düzeltmeleri uyguluyor veya geliştirici ekibiniz için net teknik görevler hazırlıyorum.
- 200 OK döndüren
- Canonical
- İndekslenebilir
- Arama sonuçlarında bulunması istenen
URL’ler yer almalıdır.
10. Birden Fazla SEO Eklentisi Kullanmayın
WordPress sitelerinde iki veya daha fazla kapsamlı SEO eklentisinin aynı anda etkin olması şu çıktıları çoğaltabilir:
- Canonical etiketleri
- Meta robots yönergeleri
- XML sitemap’ler
- Open Graph etiketleri
- Twitter metadata
- Schema ve JSON-LD
- Breadcrumb işaretlemeleri
Örneğin bir eklenti sayfayı index olarak ayarlarken diğeri noindex üretebilir. Tema ayrıca ayrı bir canonical veya Article schema ekleyebilir.
Denetim sırasında:
Aktif SEO eklentilerini listeleyin.
Her birinin hangi teknik çıktıları ürettiğini belirleyin.
Tema içindeki SEO işlevlerini kontrol edin.
Gereksiz veya yinelenen sistemi devre dışı bırakın.
Cache’i temizleyin.
Oluşturulan kaynak kodu yeniden inceleyin.
Tek bir SEO eklentisi kullanılması da ayarların otomatik olarak doğru olduğu anlamına gelmez. Yazı türleri, arşivler, sitemap ve schema ayarları site yapısına göre yapılandırılmalıdır.
11. Tema ve Sayfa Oluşturucular Teknik SEO’yu Nasıl Etkiler?
WordPress teması yalnızca görsel tasarımı belirlemez. Sayfanın HTML yapısını, heading kullanımını, script yükünü, görsel boyutlarını ve bazı teknik etiketleri de etkileyebilir.
Elementor, WPBakery, Divi, Beaver Builder ve benzeri sayfa oluşturucular da ek HTML, CSS ve JavaScript üretebilir.
Tema Kaynaklı Olası Sorunlar
- Birden fazla H1
- Başlıkların görsel boyuta göre yanlış seçilmesi
- Eksik veya yinelenen canonical
- Tema tarafından üretilen schema
- Mobil menü bağlantılarının taranamaması
- Sayfalama bağlantılarının hatalı olması
- İçeriğin JavaScript sonrasında yüklenmesi
- Büyük hero görselleri
- Gereksiz font ve script dosyaları
- Görseller için boyut tanımlanmaması
- Breadcrumb yapısının hatalı olması
Sayfa Oluşturucu Kaynaklı Olası Sorunlar
- Aşırı DOM boyutu
- Kullanılmayan CSS
- Çok sayıda JavaScript dosyası
- Üçüncü taraf widget’lar
- Görünmeyen mobil ve masaüstü öğelerin birlikte yüklenmesi
- Arka plan görsellerinin geç yüklenmesi
- Hero içeriğinin istemci tarafında oluşturulması
- Layout shift
- Aynı bileşenin birçok kez tekrar edilmesi
Sorun yalnızca “Elementor yavaş” veya “tema ağır” şeklinde değerlendirilmemelidir. Hangi şablonun, widget’ın veya kaynağın performans sorununa neden olduğu URL ve template düzeyinde belirlenmelidir.
12. WordPress Site Yapısı Nasıl Düzenlenmelidir?
Sağlıklı bir WordPress site yapısı, önemli sayfaların hem kullanıcılar hem de arama motorları tarafından mantıklı yollar üzerinden bulunmasını sağlar.
Örnek bir hizmet sitesi yapısı:
- Ana Sayfa
- ├── Hizmetler
- │ ├── Teknik SEO
- │ ├── WordPress Teknik SEO
- │ └── Google Search Console Desteği
- ├── Projeler
- ├── Hakkımda
- └── Blog
- ├── İndeksleme
- ├── Site Performansı
- └── Site Mimarisi
Kontrol Edilecek Site Mimarisi Alanları
- Ana hizmet sayfaları menüden erişilebilir mi?
- Alt sayfalar mantıklı üst sayfalara bağlı mı?
- Blog kategorileri gerçek konu kümelerini yansıtıyor mu?
- Önemli sayfalar ana sayfadan çok fazla tıklama uzakta mı?
- Yetim sayfalar bulunuyor mu?
- Breadcrumb yapısı site hiyerarşisiyle uyumlu mu?
- Footer yüzlerce gereksiz bağlantı içeriyor mu?
- Aynı konu için birden fazla merkez sayfa oluşturulmuş mu?
- İç bağlantılar canonical URL’lere mi gidiyor?
Site mimarisi yalnızca URL klasörleriyle belirlenmez. İç bağlantılar, menüler, breadcrumb’lar ve sayfalar arasındaki anlamsal ilişkiler birlikte değerlendirilmelidir.
13. WordPress İç Bağlantıları Nasıl Kontrol Edilmelidir?
WordPress otomatik olarak kategori, etiket, son yazılar ve ilgili içerik bağlantıları üretebilir. Ancak bu modüller her zaman stratejik iç bağlantı yapısı oluşturmaz.
İncelenecek İç Bağlantı Türleri
- Ana menü
- Footer
- Breadcrumb
- Kategori arşivleri
- Yazı içi bağlantılar
- İlgili yazılar
- Sidebar
- Üst ve alt sayfalar
- HTML sitemap
- Otomatik bağlantı eklentileri
Yaygın İç Bağlantı Sorunları
- Önemli sayfaların yalnızca sitemap içinde bulunması
- Bir sayfaya site içinden hiç bağlantı verilmemesi
- İlgisiz anchor text kullanılması
- Yönlendirilmiş URL’lere bağlantı verilmesi
- Canonical olmayan sürümlere bağlantı verilmesi
- Her sayfadan aynı çok sayıda bağlantının tekrarlanması
- JavaScript tıklamasıyla çalışan ancak gerçek href içermeyen öğeler
- Eski içeriklerden yeni önemli sayfalara bağlantı verilmemesi
Bir sayfanın yalnızca XML sitemap’e eklenmesi, güçlü bir iç bağlantı yapısının yerini tutmaz.
14. WordPress Performans Sorunları Nasıl Teşhis Edilir?
WordPress site hızı sorunları genellikle tek bir nedene bağlı değildir.
Performans şu bileşenlerin birleşiminden etkilenebilir:
- Hosting yanıt süresi
- Tema
- Sayfa oluşturucu
- Eklentiler
- Veritabanı sorguları
- Cache
- CDN
- Görseller
- Fontlar
- JavaScript
- CSS
- Üçüncü taraf scriptleri
Google’ın Core Web Vitals metrikleri gerçek kullanıcı deneyimindeki yükleme performansı, etkileşim ve görsel kararlılığı ölçer:
- Largest Contentful Paint: Yükleme performansı
- Interaction to Next Paint: Etkileşim duyarlılığı
- Cumulative Layout Shift: Görsel kararlılık
Google’ın önerdiği iyi eşikler LCP için 2,5 saniye veya daha düşük, INP için 200 milisaniye veya daha düşük ve CLS için 0,1 veya daha düşüktür. (Google for Developers)
Performansı Şablon Düzeyinde İnceleyin
Yalnızca ana sayfayı test etmek yeterli değildir.
Şu sayfa türlerinden örnekler seçin:
- Ana sayfa
- Hizmet sayfası
- Blog yazısı
- Kategori sayfası
- İletişim sayfası
- Özel yazı türü
- Ürün veya listeleme sayfası
Aynı şablonu kullanan URL’lerde ortak sorunlar bulunabilir.
LCP Sorunlarının Yaygın Nedenleri
- Büyük hero görseli
- Görselin geç keşfedilmesi
- Yavaş sunucu yanıtı
- Render-blocking CSS
- Ana içeriğin JavaScript ile oluşturulması
- Web fontlarının yüklemeyi geciktirmesi
- Cache eksikliği
INP Sorunlarının Yaygın Nedenleri
- Uzun JavaScript görevleri
- Ağır sayfa oluşturucu scriptleri
- Çok sayıda üçüncü taraf araç
- Karmaşık menü veya form kodu
- Ana iş parçacığının yoğun kullanımı
- Gereksiz event listener’lar
CLS Sorunlarının Yaygın Nedenleri
- Boyutları tanımlanmamış görseller
- Sonradan yüklenen banner’lar
- Font değişimleri
- Cookie banner’ları
- Dinamik formlar
- Reklam veya embed alanları
- Yapışkan header’ın sayfayı kaydırması
PageSpeed Insights laboratuvar verileri ile Search Console’daki gerçek kullanıcı verileri birbirinden ayrılmalıdır. Tek bir performans puanı yerine sorunlu metrik, şablon ve kaynak belirlenmelidir.
15. Görsel Optimizasyonunu Kontrol Edin
WordPress görselleri farklı boyutlarda otomatik olarak oluşturabilir; ancak tema veya eklentiler doğru boyutu kullanmıyorsa tarayıcı gereğinden büyük dosya indirebilir.
Kontrol edin:
- Görsel dosya boyutları
- WebP veya uygun modern format kullanımı
- Responsive srcset çıktısı
- Width ve height nitelikleri
- Hero görselinin boyutu
- Lazy loading davranışı
- Ekranın üst kısmındaki görsellere yanlış lazy loading uygulanması
- Kullanılmayan görsel varyasyonları
- Görsel URL’lerinin CDN üzerinden doğru sunulması
- Alt metinlerin görsel içeriğini açıklaması
Bütün görselleri en düşük kaliteye sıkıştırmak doğru yaklaşım değildir. Görüntü kalitesi, dosya boyutu ve kullanıldığı ekran boyutu birlikte değerlendirilmelidir.
16. Cache, CDN ve Hosting Ayarlarını İnceleyin
Bir cache eklentisi kullanmak WordPress sitesinin otomatik olarak hızlı olmasını sağlamaz.
Kontrol edilmesi gerekenler:
- Sayfa cache’i çalışıyor mu?
- Giriş yapmamış ziyaretçilere cache edilmiş sayfa sunuluyor mu?
- Cache süresi gereğinden kısa mı?
- Değişikliklerden sonra cache temizleniyor mu?
- Object cache gerçekten etkin mi?
- CDN doğru kaynakları sunuyor mu?
- HTML yanlışlıkla uzun süre cache’leniyor mu?
- Canonical veya noindex değişikliği eski cache’te kalıyor mu?
- Sunucu yanıt süresi yüksek mi?
- Çok sayıda ağır veritabanı sorgusu bulunuyor mu?
Performans eklentilerindeki “bütün seçenekleri etkinleştir” yaklaşımı JavaScript hatalarına, bozuk tasarıma veya indekslenebilir içerik kaybına neden olabilir. Her optimizasyon sonrasında hem görsel hem teknik QA yapılmalıdır.
17. Schema Markup ve JSON-LD Çıktılarını Kontrol Edin
WordPress sitelerinde yapılandırılmış veri şu kaynaklardan gelebilir:
- SEO eklentisi
- Tema
- E-ticaret eklentisi
- Breadcrumb eklentisi
- İnceleme eklentisi
- Özel kod
- Sayfa oluşturucu
Bu durum aynı sayfada birden fazla ve birbiriyle çelişen JSON-LD çıktısı oluşturabilir.
Yaygın WordPress Schema Sorunları
- Birden fazla Organization
- Birden fazla WebSite
- Çakışan Article veya BlogPosting
- Yanlış yazar bilgisi
- Makale sayfasında ürün schema kullanılması
- Breadcrumb ile görünür navigasyonun eşleşmemesi
- Görünmeyen FAQ içeriği için FAQPage
- Desteklenmeyen değerlendirme puanları
- Tema ve SEO eklentisinin aynı entity’yi farklı @id ile üretmesi
- Yanlış logo veya görsel URL’si
- Canonical ile schema URL’sinin farklı olması
İlk hedef mümkün olduğunca fazla schema türü eklemek değil, görünür içerikle uyumlu, geçerli ve tutarlı bir entity yapısı oluşturmaktır.
JSON-LD kontrolünde:
- Schema Markup Validator
- Rich Results Test
- Sayfanın oluşturulan kaynak kodu
- Search Console geliştirme raporları
birlikte kullanılabilir.
18. Çok Dilli WordPress Sitelerini Kontrol Edin
Weglot, WPML, Polylang veya özel çok dilli yapılar şu teknik alanları etkileyebilir:
- Canonical etiketleri
- Hreflang
- Dil URL’leri
- Sitemap’ler
- Yönlendirmeler
- Menü bağlantıları
- Schema dili
- İç bağlantılar
Google, farklı dil sürümlerinin birbirlerini ve kendilerini karşılıklı hreflang ile belirtmesini önerir. Alternatif URL’ler tam adres olarak kullanılmalı ve karşılıklı bağlantılar tutarlı olmalıdır. (Google for Developers)
Kontrol edin:
- Her dil sayfası kendisini canonical gösteriyor mu?
- Hreflang farklı dildeki gerçek eşdeğer sayfaya mı gidiyor?
- Tüm dil sürümleri karşılıklı mı?
- Yanlış ülke veya dil kodu kullanılıyor mu?
- Dil değiştirici taranabilir bağlantı mı?
- Her dilin kendi sitemap’i bulunuyor mu?
- Çevrilmemiş içerikler yanlışlıkla ayrı dil URL’sinde mi açılıyor?
- Schema inLanguage değeri doğru mu?
Hreflang, canonical yerine kullanılmaz. Her dil sayfası normalde kendi dil sürümünü canonical göstermeli, diğer diller hreflang ile belirtilmelidir.
19. Google Search Console ile WordPress Sorunlarını Teşhis Edin
WordPress yönetim panelindeki ayarlar yalnızca niyeti gösterir. Google’ın gerçekten hangi çıktıyı gördüğünü Search Console ile doğrulamak gerekir.
Sayfa Dizine Ekleme Raporu
Şu durumları URL gruplarına ayırın:
- Tarandı – şu anda dizine eklenmiş değil
- Keşfedildi – şu anda dizine eklenmiş değil
- Noindex tarafından hariç tutuldu
- Alternatif sayfa
- Yönlendirmeli sayfa
- Robots.txt tarafından engellendi
- Soft 404
- Bulunamadı 404
URL örneklerini sayfa türlerine göre sınıflandırın:
Yazılar
Sayfalar
- Kategoriler
- Etiketler
- Yazar arşivleri
- Medya sayfaları
- Özel yazı türleri
Bu yöntem, sorunun tek sayfada mı yoksa WordPress şablon veya eklenti düzeyinde mi olduğunu anlamayı kolaylaştırır.
URL Denetleme
Önemli bir URL için kontrol edin:
- URL Google’da mevcut mu?
- Tarama izni var mı?
- İndekslemeye izin veriliyor mu?
- Kullanıcı canonical nedir?
- Google canonical nedir?
- URL hangi sitemap’te bulunmuş?
- Son tarama ne zaman yapılmış?
- Oluşturulan HTML ana içeriği içeriyor mu?
WordPress’e özgü bir neden bulamazsanız genel teşhis akışı için Google İndeksleme Sorunları: Nedenleri, Teşhis ve Çözümleri rehberine geçilmelidir.
20. WordPress Teknik SEO Sorunları Nasıl Önceliklendirilir?
Her teknik hata aynı etkiye sahip değildir.
Önceliklendirmeyi şu sırayla yapın:
1. Site Genelini Etkileyen Engeller
- Site genelinde noindex
- Robots engeli
- Sunucu hataları
- Yanlış alan adı yönlendirmeleri
- HTTPS sorunları
- Canlı sitede bakım modu
2. Önemli Sayfaları Etkileyen İndeksleme Sorunları
- Hizmet veya ürün sayfasında noindex
- Yanlış canonical
- Sitemap dışı önemli URL’ler
- Yetim sayfalar
- Şablon düzeyinde indeksleme hataları
3. Canonical ve URL Tutarsızlıkları
- Birden fazla URL sürümü
- Yönlendirme zincirleri
- Çelişkili sitemap ve iç bağlantılar
- Kategori veya parametre varyasyonları
4. Site Yapısı ve İç Bağlantılar
- Önemli sayfaların derinde kalması
- Yetim sayfalar
- Gereksiz taksonomiler
- Zayıf kategori yapısı
5. Performans ve Schema İyileştirmeleri
- Kritik Core Web Vitals sorunları
- Tema veya eklenti yükü
- Çakışan JSON-LD
- Görsel optimizasyonu
Önce siteyi taranamaz veya indekslenemez hâle getiren sorunları çözün. Ardından canonical, site yapısı, performans ve geliştirme alanlarına geçin.
21. WordPress Teknik SEO Düzeltmeleri Nasıl Doğrulanır?
Teknik değişiklik yalnızca WordPress panelinde kaydedildiği için tamamlanmış sayılmaz.
Yeniden Tarama Yapın
Kontrol edin:
- Eski hatalar devam ediyor mu?
- Yeni 404 veya yönlendirme oluştu mu?
- Canonical çıktısı değişti mi?
- Sitemap güncellendi mi?
- noindex kaldırıldı mı?
- İç bağlantılar doğru hedefe gidiyor mu?
- Schema çakışmaları giderildi mi?
Cache Katmanlarını Temizleyin
Aşağıdaki katmanların biri eski çıktıyı göstermeye devam edebilir:
- WordPress cache eklentisi
- Hosting cache’i
- CDN
- Tarayıcı cache’i
- Object cache
- Sayfa oluşturucu CSS cache’i
Yayındaki HTML’yi Kontrol Edin
Yönetim panelindeki ayar yerine ziyaretçiye ve Googlebot’a sunulan çıktıyı inceleyin:
- Meta robots
- Canonical
- Hreflang
- Schema/JSON-LD
- Heading yapısı
- İç bağlantılar
- HTTP durum kodu
Search Console ile Doğrulayın
Yayındaki URL’yi test edin.
Gerekli URL’ler için yeniden dizine ekleme isteği gönderin.
Son tarama tarihini takip edin.
Google canonical seçimini kontrol edin.
Sayfa Dizine Ekleme raporundaki değişimi izleyin.
Gösterim ve tıklamaların doğru URL’ye geçtiğini doğrulayın.
Performansı Yeniden Ölçün
Laboratuvar testinin yanında gerçek kullanıcı verilerini de izleyin.
Aynı şablondan birden fazla URL test ederek iyileştirmenin tek sayfaya mı yoksa bütün şablona mı yansıdığını kontrol edin.
WordPress Teknik SEO’da Sık Yapılan Hatalar
- Arama Motoru Görünürlüğü ayarını canlı sitede açık bırakmak
- Her kategori ve etiketi otomatik olarak indekslemek
- Her arşivi topluca noindex yapmak
- Birden fazla SEO eklentisi kullanmak
- WordPress core ve eklenti sitemap’lerini birlikte yönetmemek
- Sitemap’e noindex, 404 veya yönlendirilmiş URL eklemek
- Kalıcı bağlantı yapısını yönlendirme planı olmadan değiştirmek
- Bütün eski URL’leri ana sayfaya yönlendirmek
- Canonical etiketi varken iç bağlantıları farklı URL’ye vermek
- Performans eklentisindeki tüm ayarları test etmeden açmak
- Ana sayfa puanını bütün sitenin performansı kabul etmek
- Schema hatalarını yalnızca doğrulama aracındaki uyarı sayısına göre değerlendirmek
- WordPress panelindeki ayarları kontrol edip canlı HTML’yi incelememek
- Düzeltmelerden sonra yeniden tarama ve Search Console doğrulaması yapmamak
WordPress Teknik SEO Kontrol Tablosu
| Kontrol alanı | Beklenen durum |
|---|---|
| Arama Motoru Görünürlüğü | Canlı sitede indeksleme engeli bulunmamalı |
| HTTP yanıtı | İndekslenmesi gereken URL’ler 200 vermeli |
| Meta robots | Önemli sayfalarda noindex bulunmamalı |
| Canonical | Tercih edilen ve erişilebilir URL’yi göstermeli |
| XML sitemap | Yalnızca canonical ve indekslenebilir URL’ler |
| Kalıcı bağlantılar | Tutarlı ve uzun vadeli URL yapısı |
| Yönlendirmeler | Doğrudan ve ilgili hedefe 301 |
| Kategoriler | Anlamlı konu merkezleri |
| Etiketler | Gereksiz URL şişmesi oluşturmamalı |
| Yazar arşivleri | Gerçek bağımsız değer taşımalı |
| İç bağlantılar | Önemli sayfaları desteklemeli |
| Tema ve eklentiler | Yinelenen teknik çıktı üretmemeli |
| Core Web Vitals | Şablon düzeyinde analiz edilmeli |
| Schema/JSON-LD | Görünür içerikle uyumlu ve tutarlı |
| Doğrulama | Yeniden tarama ve Search Console kontrolü |
