Bir web sitesine düzenli içerik üretmek, dijital görünürlüğü büyütmenin önemli bir parçası. Ancak bu içeriklerin sunulduğu sayfanın geç açılması, yüklenirken yer değiştirmesi veya bağlantılarının ne işe yaradığını teknik olarak açıklayamaması, içerik yatırımının önünde engel oluşturabilir.
Mochatouch’un Türkçe, Almanca ve İngilizce WordPress sitelerinde yaptığımız çalışmada bu konuları birlikte ele aldık: sayfa performansı, görsel kararlılık ve AI ajanlarının arayüzü anlayabilmesi.
Mevcut WordPress, Elementor ve tema yapısını koruyarak Türkçe ana sayfada iki ardışık PageSpeed Insights testinde mobil 90, masaüstü 99 puana ulaştık. Almanca ve İngilizce ana sayfalarda ise Agentic Browsing denetimleri hem mobilde hem masaüstünde 3/3 oldu.
Bu vaka, WordPress hızlandırmanın nasıl ölçülebilir bir teknik iyileştirme sürecine dönüştürülebileceğini ve GEO hizmetinin altyapı tarafında nasıl konumlandırılabileceğini gösteriyor.
WordPress hızlandırmaya nereden başladık?
İlk adımımız ana sayfa, hizmetler listesi, hizmet detayları, blog listesi ve blog yazılarını ayrı ayrı incelemek oldu. Çok dilli yapıda aynı şablonun farklı alan adlarında nasıl çalıştığını da kontrol ettik.
Bu ayrım önemliydi. Ana sayfanın animasyonlu başlığı, bir hizmet sayfasının büyük görseli ve blog yazısının eklenti kaynakları farklı yükleme sorunları oluşturabiliyordu. Ana sayfaya uygulanan bir düzeltme de diğer dillerdeki sayfa kimliklerini veya önbellek kopyalarını otomatik olarak kapsamıyordu.
İncelemeyi toplam performans puanının ötesine taşıyarak şu sorulara odakladık:
- İlk ekrandaki ana içerik ne zaman görünür oluyor?
- Sayfa açılırken hangi öğeler yer değiştiriyor?
- Kritik görseller ve fontlar doğru zamanda yükleniyor mu?
- JavaScript kaynakları çalışıyor mu, yoksa hata veriyor mu?
- Güncel HTML bütün dil sürümlerinde ziyaretçiye ulaşıyor mu?
- Bağlantıların ve açılır içeriklerin erişilebilir adları ve durumları doğru mu?
Sayfa hızı, SEO ve Core Web Vitals ilişkisi
Google, Core Web Vitals metriklerini yükleme performansı, etkileşime yanıt verme ve görsel kararlılık üzerinden tanımlar. İyi kullanıcı deneyimi için LCP’de 2,5 saniye, INP’de 200 milisaniye ve CLS’de 0,1 sınırlarını hedeflemek gerekir. Bu deneyim, Google’ın sıralama sistemlerinin ödüllendirmeyi amaçladığı sayfa deneyimiyle ilişkilidir. Google’ın Core Web Vitals açıklaması.
Bu metriklerin karşılığı basittir: LCP ana içeriğin görünmesini, INP bir etkileşimin ardından arayüzün yanıt vermesini, CLS ise beklenmedik yerleşim kaymalarını ölçer.
PageSpeed Insights’taki 100 üzerinden performans puanı ise ayrı bir laboratuvar özetidir. Tek başına Google sıralaması veya bütün Core Web Vitals ölçütlerinin sağlandığı anlamına gelmez. Bizim Türkçe ana sayfa testimiz bunun somut bir örneği: mobil puan 90’a ulaşırken LCP yaklaşık 3,60 saniyeydi. Dolayısıyla ana içeriğin yüklenme süresinde hâlâ geliştirme alanı vardı.
1. İlk ekrandaki yerleşim kaymalarını azalttık
En belirgin sorunlardan biri, sayfanın ilk çizimiyle son görünümü arasındaki farktı. Bazı stiller geç uygulanıyor; görseller, dekoratif bölüm ayırıcıları ve değişen başlık kelimeleri sonradan yerleşiyordu.
Bu davranışı düzeltmek için temanın ilk ekranı oluşturmakta kullandığı kritik CSS kurallarını erkenden sunduk. Üst üste konumlanan görsellerin kaplayacağı alanı belirledik ve görsel oranlarını ilk çizimde koruduk. Kelimeleri değişen başlıkta, en geniş kelimenin ihtiyaç duyduğu alanı baştan ayırdık.
İlk ekrandaki bazı içeriklerin görünmek için animasyon sırasını beklemesini de kaldırdık. Böylece ziyaretçi ana içeriği görmek için ek bir görsel efektin başlamasını beklemiyordu.
Ölçümlerde Türkçe hizmetler listesinin masaüstü CLS değeri 0,608’den 0,010’a, Almanca ana sayfanınki 1,005’ten 0,007’ye, İngilizce ana sayfanınki 1,015’ten 0,017’ye geriledi.
Bu değişikliklerin kullanıcıya karşılığı, metin ve görsellerin daha kararlı bir yerleşimle açılmasıdır.
2. Görsellerin boyutunu ve yükleme önceliğini düzenledik
WordPress hızlandırmada görselin dosya boyutu kadar, tarayıcının o görseli ne zaman istemeye başladığı da önemlidir.
Ana sayfanın ilk ekranındaki görsellerin HTML çıktısını sunucu tarafında düzenledik. Bu görsellerde gecikmeli yüklemeyi kaldırdık; ilk görsele yüksek indirme önceliği verdik. Ekranın aşağısındaki görsellerde gecikmeli yükleme yaklaşımını koruduk.
LinkedIn hizmet sayfasındaki bir görseli, 600 × 400 piksel ölçülerini koruyarak yeniden optimize ettik. Dosya boyutu 226.724 bayttan 16.632 bayta indi: yaklaşık %92,7 küçülme.
Bu sayı, ilgili görsel dosyasındaki küçülmeyi ifade ediyor. Sayfanın tamamının aynı oranda hızlandığını söylemek mümkün değil; fontlar, JavaScript, diğer görseller ve sunucu yanıtı da yükleme sürecine katılıyor.
Elementor çıktısını ayrıca kontrol ettik. Bazı bileşenler WordPress üzerinden verilen yükleme niteliklerinin tamamını korumuyordu. Bu nedenle ayarın kodda bulunmasıyla yetinmeyip, ziyaretçiye ulaşan HTML’de gerçekten yer aldığını doğruladık.
3. Fontları ve JavaScript kaynaklarını gözden geçirdik
İlk ekranda kullanılan yerel Manrope ve Poppins font dosyaları için hedefli ön yükleme uyguladık. Yalnızca gerekli fontları seçtik ve ön yükleme adreslerini mevcut font CSS’inin kullandığı URL’lerle eşleştirdik.
Canlı ortamda SCRIPT_DEBUG ayarını kapatarak WordPress ve Elementor’un küçültülmüş JavaScript dosyalarını kullanmasını sağladık.
Ayrıca Akismet’in bir JavaScript kaynağında sunucu optimizasyonundan kaynaklanan bir sorun tespit ettik. Apache mod_pagespeed tarafından dönüştürülen adres 403 hatası verirken özgün kaynak çalışıyordu. İlgili dosyayı bu dönüşümün dışında bıraktık ve kaynağın HTTP 200 yanıtıyla yüklenmesini doğruladık.
Bu müdahale, antispam işlevini koruyarak hatalı kaynak isteğini giderdi. Tek başına büyük bir hız artışı sağladığını gösteren bir ölçümümüz bulunmuyor.
4. Önbelleği bütün dil sürümlerinde kontrol ettik
Önbellek çalışması kapsamında WP Super Cache ile üretilen HTML kopyalarını, Elementor’un oluşturduğu dosyaları ve statik kaynakların tarayıcı önbellek kurallarını ele aldık.
Çok dilli yapıda önemli bir ayrıntıyla karşılaştık: yönetim panelinden yapılan normal önbellek temizliği bütün alan adlarındaki HTML kopyalarını yenilemiyordu. Güncel kod sunucuda bulunmasına rağmen bazı dil sürümlerinde eski çıktı sunulabiliyordu.
Bu nedenle Türkçe, Almanca ve İngilizce alan adlarının kopyalarını ayrı ayrı yeniledik ve normal ziyaretçi URL’lerinden kontrol ettik.
Bu vakadan çıkan ders, bir değişikliği yalnızca WordPress yönetiminde doğrulamanın yeterli olmadığıdır. Çok alan adlı yapılarda her alan adının ziyaretçiye sunduğu çıktı incelenmelidir. Tüm alan adları için otomatik önbellek temizliğinin kalıcı çözümü ise ayrıca takip edilmesi gereken bir geliştirme olarak kaldı.
5. AI ajanları için bağlantıları ve arayüz durumlarını anlaşılır hâle getirdik
Agentic browsing, bir AI ajanının tarayıcı üzerinden sayfayı inceleyip kullanıcı adına adımlar gerçekleştirmesiyle ilgilidir. Erişilebilirlik ağacı, bu süreçte etkileşimli öğeleri anlamak için kullanılabilir. Etiketi eksik bir düğme veya bağlantı, hem yardımcı teknolojiler kullanan insanlar hem de ajanlar için engel oluşturabilir. Chrome’un ajanlar için erişilebilirlik dokümanı.
Bizim sitemizde bazı sosyal medya bağlantıları yalnızca ikon içeriyordu. İnsan ziyaretçi YouTube simgesini tanıyabilse de bağlantının erişilebilir adı eksikti. İngilizce ana sayfanın alt bölümündeki HubSpot logosunda da bağlantının amacı teknik olarak açıklanmıyordu.
Bu bağlantılara diline uygun erişilebilir adlar ekledik. Örneğin Almanca sosyal bağlantı “Mochatouch auf YouTube”, İngilizce HubSpot bağlantısı “HubSpot agency services” adını aldı. Mevcut açıklaması bulunan bağlantıları koruduk.
Önceki Türkçe düzeltmelerde, düğme rolündeki akordeon başlıklarında kullanılan uygunsuz aria-selected niteliğini de kaldırdık. Açık veya kapalı durumu ifade eden aria-expanded niteliğini koruduk.
Buradaki amaç, arayüz öğesinin amacıyla teknik tanımının örtüşmesiydi. Görünen tasarımı değiştirmeden bağlantılara anlam kazandırabildik.
Çerez yönetimiyle etkileşimi de doğruladık
Erişilebilirlik düzeltmesinin ilk taslağı, kodda geçen YouTube alan adı nedeniyle Complianz tarafından bir YouTube entegrasyonu olarak yorumlanıp engellendi.
Yalnızca bağlantılara ad ekleyen bu yardımcı kodu, mevcut ikon kimliklerini kullanacak şekilde düzenledik. Kod takip işlemi, çerez veya ağ isteği oluşturmuyordu. Son sürümde etiketlerin çerez tercihi beklemeden oluştuğunu doğruladık; gerçek video ve pazarlama entegrasyonlarının izin ayarlarını koruduk.
Bu örnek, performans ve erişilebilirlik değişikliklerinin çerez yönetimiyle birlikte test edilmesi gerektiğini gösteriyor. Yapılan teknik kontrol, tek başına GDPR uyumluluğu değerlendirmesi değildir.
Ölçümlerde ne değişti?
Aşağıdaki tablo, 21 Eylül 2026 tarihli performans çalışmasının kayıtlarını gösteriyor. Türkçe ana sayfanın başlangıç hücresinde iki ayrı ölçüm yer alıyor; diğer başlangıç değerleri ilgili ilk raporlardan alınmıştır. Sonuçlar tüm siteyi temsil eden bir ortalama değildir.
| Sayfa | Mobil: önce → sonra | Masaüstü: önce → sonra |
|---|---|---|
| Türkçe ana sayfa | 83 / 66 → 90 | 58 / 99 → 99 |
| Türkçe hizmetler listesi | 69 → 93 | 70 → 99 |
| Türkçe blog listesi | 75 → 96 | 90 → 100 |
| Türkçe LinkedIn hizmet sayfası | 76 → 77 | 82 → 99 |
| Türkçe LinkedIn Retargeting yazısı | 77 → 71 | 99 → 94 |
| Almanca ana sayfa | 72 → 76 | 63 → 95 |
| İngilizce ana sayfa | 50 → 76 | 67 → 96 |
Türkçe ana sayfa, düzeltmelerin ardından iki ardışık testte 90/99 sonucunu verdi. Ayrıntılar ana sayfa raporunda, hizmetler raporunda ve blog listesi raporunda görülebilir.
Her sayfada aynı başarıyı elde etmedik. LinkedIn hizmet sayfasının mobil CLS değeri 0,106 seviyesinde kaldı. İngilizce ana sayfanın son performans ölçümünde LCP 6,90 saniyeydi. İncelediğimiz blog yazısında ise kaynak hatası giderilmesine rağmen performans puanı yükselmedi.
Ölçümler Lighthouse 13.4.1 ile, mobilde Moto G Power ve yavaş 4G profili kullanılarak yapıldı. Bu çalışma sırasında CrUX gerçek kullanıcı verisi bulunmuyordu. Bu nedenle sonuçlar, gerçek kullanıcı deneyiminin bütünü veya kalıcı puan garantisi olarak yorumlanmamalıdır.
Agentic Browsing için daha sonra alınan ayrı raporlarda ise şu sonuçları doğruladık:
| Ana sayfa | Mobil Agentic Browsing | Masaüstü Agentic Browsing |
|---|---|---|
| Almanca | 3/3 | 3/3 |
| İngilizce | 3/3 | 3/3 |
Bu iki dilin mobil ve masaüstü erişilebilirlik puanları da 95 oldu. Sonuçlar Almanca raporunda ve İngilizce raporunda yer alıyor.
3/3 sonucu, rapordaki denetimlerin geçtiğini gösterir. Bütün AI ajanlarıyla uçtan uca işlem testi yapıldığı, tam erişilebilirlik uyumluluğu sağlandığı veya WebMCP entegrasyonu kurulduğu anlamına gelmez. Bu çalışma kapsamında WebMCP entegrasyonu yapılmadı.
WordPress hızlandırma, GEO hizmetinin neresinde yer alıyor?
GEO’yu, markanın üretken yapay zekâ tabanlı arama ve yanıt deneyimlerinde bulunabilmesini, doğru anlaşılmasını ve uygun olduğunda kaynak olarak kullanılmasını destekleyen çalışmalar olarak ele alıyoruz.
AI tarafından verilen bir yanıtta kaynak gösterilmek ile bir AI ajanının web sitesinde işlem yapabilmesi farklı sonuçlardır. Performans ve erişilebilirlik çalışmaları bu alanların teknik temelini destekler; doğrudan kaynak gösterilme garantisi oluşturmaz.
Google da AI Overviews ve AI Mode için mevcut SEO ilkelerinin geçerli olduğunu, özel bir ek optimizasyon veya özel şema zorunluluğu bulunmadığını belirtiyor. İlgili sayfanın indekslenmiş ve aramada bir özetle gösterilmeye uygun olması gerekiyor. Bu koşulların karşılanması, gösterim garantisi vermiyor. Google’ın AI özellikleri ve web siteleri rehberi.
Mochatouch’un GEO hizmetinde bu çalışmayı aşağıdaki kapsamın teknik başlangıcı olarak konumlandırıyoruz:
| Çalışma alanı | Ele alınacak konular |
|---|---|
| Teknik erişim ve performans | Taranabilirlik, indekslenebilirlik, yükleme süreleri, görsel kararlılık ve dil sürümleri |
| Agentic kullanım ve erişilebilirlik | Anlamlı bağlantılar, düğme ve form etiketleri, doğru durum bilgileri ve görev akışları |
| İçerik ve uzmanlık | Açık hizmet tanımları, özgün deneyimler, doğrulanabilir veriler ve kullanıcı sorularına yanıtlar |
| Marka ve hizmet tutarlılığı | Kurum, hizmet, yazar ve dil bilgilerinin uyumu; görünen içeriğe uygun yapılandırılmış veri |
| Ölçüm ve geliştirme | Teknik metriklerin, arama görünürlüğünün, izlenebilen AI yönlendirmelerinin ve dönüşümlerin takibi |
Bu vakada performans ve belirli erişilebilirlik hatalarına müdahale ettik. Diğer alanlar, GEO çalışmasının daha geniş hizmet kapsamını oluşturuyor. Henüz organik trafik, AI kaynak gösterimi veya müşteri talebinde bu değişikliklere bağlanabilecek bir artış ölçmedik.
WordPress’i yenilemek veya headless yapıya geçmek şart mı?
Bu projede mevcut sistemi koruyarak ilerledik. Düzeltmeleri küçük, geri alınabilir bir WordPress eklentisinde topladık; özgün görsel dosyalarını sakladık ve hedefli sunucu ayarları kullandık.
Elde ettiğimiz sonuçlar, bizim yapımızda önemli sorunların tam bir yeniden tasarımdan önce giderilebildiğini gösterdi. Bu, her WordPress sitesinde aynı sonucun alınacağı anlamına gelmez.
Yeniden tasarım veya headless WordPress kararı; içerik yönetimi ihtiyaçları, kullanıcı akışları, entegrasyonlar, bakım kapasitesi ve mevcut yapının sınırları birlikte değerlendirilerek verilmelidir. Teknik inceleme, bu karar için somut veri sağlar.
Sık Sorulan Sorular
WordPress hızlandırma için siteyi tamamen yenilemek gerekir mi?
Her zaman gerekmez. Bu çalışmada mevcut WordPress, Elementor ve tema yapısını koruyarak kritik CSS, görsel yükleme öncelikleri, fontlar, önbellek ve erişilebilirlik hataları üzerinde iyileştirmeler yaptık. Yeniden tasarım kararı, teknik inceleme ve iş ihtiyaçları birlikte değerlendirilerek verilmelidir.
PageSpeed Insights mobil puanının 90 olması bütün Core Web Vitals ölçütlerinin geçtiğini gösterir mi?
Hayır. PageSpeed Insights performans puanı bir laboratuvar özetidir. LCP, INP ve CLS ayrıca değerlendirilmelidir. Bu çalışmada Türkçe ana sayfa mobilde 90 puana ulaşırken LCP yaklaşık 3,60 saniyeydi; dolayısıyla yükleme süresinde geliştirme alanı devam ediyordu.
WordPress sitelerinde CLS sorunu nasıl azaltılır?
Görsellerin kaplayacağı alanı önceden ayırmak, ilk ekran için gerekli CSS kurallarını zamanında sunmak, font değişimlerini kontrol etmek ve animasyonlu öğelerin yerleşimini kararlı hâle getirmek yardımcı olabilir. Uygulanacak düzeltme, kaymaya neden olan öğenin ölçümle belirlenmesine dayanmalıdır.
Önbelleği temizledikten sonra neden farklı dillerde eski içerik görünebilir?
Çok alan adlı WordPress yapılarında her dil için ayrı HTML kopyaları bulunabilir. Yönetim panelindeki temizleme işlemi bütün alan adlarını kapsamıyorsa eski çıktı sunulmaya devam edebilir. Her alan adının ziyaretçiye sunduğu HTML ve ilgili önbellek katmanları ayrı ayrı kontrol edilmelidir.
Agentic Browsing denetiminde 3/3 almak AI yanıtlarında görünürlük garantisi verir mi?
Hayır. Bu sonuç, ilgili rapordaki denetimlerin geçtiğini gösterir. AI yanıtlarında kaynak gösterilme, bütün ajanlarla işlem yapabilme, tam erişilebilirlik uyumluluğu veya WebMCP entegrasyonu garantisi değildir. Bu çalışmada WebMCP entegrasyonu yapılmadı.
WordPress performansı ile GEO arasında nasıl bir ilişki vardır?
Performans ve erişilebilirlik çalışmaları, içeriğin sunulduğu teknik altyapıyı ve arayüzün kullanılabilirliğini destekler. GEO kapsamında bu temel; taranabilirlik, açık hizmet tanımları, özgün içerik, tutarlı marka bilgileri ve görünürlük ölçümüyle birlikte ele alınır. Hız puanındaki artışın tek başına AI kaynak gösteriminde artış sağladığı varsayılmamalıdır.
GEO çalışmalarına teknik bir başlangıç
İçerik üretimi, içeriğin sunulduğu altyapıyla birlikte değerlendirildiğinde daha güçlü bir temele oturur. Hızlı görünen ana içerik, kararlı sayfa düzeni ve amacı anlaşılır bağlantılar; ziyaretçinin hizmeti incelemesini ve bir sonraki adıma geçmesini destekler.
Mochatouch’ta WordPress hızlandırma ve agentic erişilebilirlik çalışmalarını, GEO hizmetimizin teknik başlangıcı olarak ele alıyoruz. Önce mevcut engelleri ölçüyor, ardından sayfa ve şablon bazında düzeltmeler yapıyor, sonuçları yeniden doğruluyoruz.
Web sitenizin performansını ve AI ajanlarının kullanımı açısından teknik durumunu değerlendirmek için Mochatouch ile iletişime geçin. İçerik ve GEO yatırımınızın önündeki teknik engelleri birlikte belirleyelim.
