WordPress mi Özel Yazılım mı? SEO ve GEO İçin Karar

İki yolla da Google'da ve yapay zeka cevaplarında okunabilen bir site kurulabilir, iki yolla da okunamayan bir site çıkabilir: SEO ve GEO açısından WordPress'in de özel yazılımın da baştan bir üstünlüğü yok. Sonucu sunucunun gönderdiği HTML'in içinde ne olduğu, güncellemeyi kimin yapacağı, başlık ve şema gibi alanların kimin elinde olduğu ve ajans değiştiğinde sitenin ne kadar zahmetle taşınabileceği belirler. Ölçütler aşağıda tek tek açılıyor, her biri için teklifte neye bakılacağı yazılıyor ve sonda üç farklı işletme tipi için hangi yolun neden makul olduğu karşılaştırılıyor.

Masanızda biri WordPress, diğeri "sıfırdan kodlama" öneren iki teklif duruyorsa karşılaştırmayı bu ölçütlerle yapabilirsiniz. Wix tipi barındırılan site kuruculardan söz ediyorsanız soru biraz farklı; onlar için hazır sitelerin beş kontrolü ayrı bir yazıda duruyor ve burada tekrar edilmiyor.

SEO ve GEO açısından WordPress mi özel yazılım mı?

Kısa cevap şu: arama motorları ve yapay zeka tarayıcıları bir sitenin hangi yazılımla yapıldığını değil, kendilerine hangi metnin geldiğini görür. Googlebot için arkada hangi yazılımın çalıştığı değil, gelen HTTP yanıtı önemlidir.

Bu yüzden "WordPress SEO dostudur" ya da "özel yazılım Google'da daha iyi sıralanır" gibi cümleler tek başına bir şey söylemez. Doğru kurulmuş bir WordPress sitesi temiz HTML, doğru başlıklar ve hızlı sayfalar üretebilir. Kötü kurulmuş bir özel yazılım ise içeriği yalnızca tarayıcıda JavaScript ile çizen, her sayfaya aynı başlığı basan bir yapıda kalabilir.

Asıl fark iş bölümünde ortaya çıkar. WordPress'te hazır gelen pek çok şey (yönetim paneli, kullanıcı rolleri, içerik dışa aktarma) özel yazılımda ayrıca yazılmak zorundadır. Özel yazılımda ise WordPress'te eklentiyle çözülen bir ihtiyacın sayfaya ne yüklediğini baştan siz ya da geliştiriciniz belirlersiniz. Hangisinin size uyduğu, sitenizin ne yapması gerektiğine ve onu kimin yöneteceğine bağlıdır.

İki seçenek gerçekte neyi anlatıyor?

WordPress, kendi barındırma hesabınıza kurulan açık kaynaklı bir içerik yönetim sistemidir. Çekirdek yazılım ücretsizdir; görünümü tema, ek özellikleri eklentiler sağlar. Teklifte "WordPress" yazıyorsa aslında üç parçalı bir şey alıyorsunuz: çekirdek, seçilen tema (hazır ya da sizin için yazılmış) ve bir eklenti listesi. Üçünün de kalitesi ayrı ayrı sorulmalıdır.

"Özel yazılım" ise tek bir şey değildir. Bir geliştiricinin Laravel, Django ya da benzeri bir çatıyla sunucu tarafında sayfa ürettiği klasik bir uygulama olabilir. React veya Vue ile yazılmış, sayfayı tarayıcıda çizen tek sayfa uygulaması olabilir. Ya da aynı kütüphanelerle yazılıp derleme sırasında her sayfa için hazır HTML dosyası üreten statik bir site olabilir. SEO ve GEO açısından bu üçü birbirinden WordPress'ten olduğu kadar farklıdır.

Bir de karma yol var: içerik WordPress panelinde girilir ama ziyaretçiye gösterilen sayfaları ayrı bir ön yüz üretir. Buna "headless" kurulum denir. Panel kolaylığı korunur, ama bakımda iki sistem olur ve ön yüzün sayfaları nerede ürettiği ayrıca sorulmalıdır.

Sunucudan gelen HTML'de metin var mı?

Hangi yolu seçerseniz seçin, hizmet adınız, açıklamanız ve sık sorulan sorularınız sunucunun ilk yanıtında düz metin olarak durmalıdır. Google'ın JavaScript SEO temelleri belgesi Google'ın JavaScript'i işleyebildiğini anlatır, ama aynı belgede sunucu tarafında ya da önceden oluşturmanın hâlâ iyi bir fikir olduğu yazar; gerekçesi sitenin kullanıcılar ve tarayıcılar için hızlanması ve bütün botların JavaScript çalıştıramamasıdır.

WordPress sayfaları varsayılan olarak sunucuda PHP ile üretilir, yani metin genellikle ilk yanıttadır. Burada risk çekirdekten değil, üstüne eklenenlerden gelir. Bazı sayfa oluşturucu eklentiler ve temalar sekmeli içerikleri, kaydırmalı alanları ya da "devamını oku" bölümlerini sonradan JavaScript ile yükleyebilir. SSS cevaplarınız böyle bir bileşenin içindeyse, sayfa ekranda düzgün görünse de kaynağında bulunmayabilir.

Özel yazılımda risk daha keskin olabilir. Yalnızca tarayıcıda çizilen bir tek sayfa uygulamasında ilk yanıt çoğu zaman boş bir kap ve bir betik dosyasından ibarettir. Sunucu tarafı oluşturma ya da derleme sırasında statik HTML üretimi bu boşluğu kapatır. Bu sitenin kendisi de React ile yazılıyor ve derleme sırasında her adres için ayrı bir HTML dosyası üretiliyor. Bu bizim kendi ihtiyacımıza göre verdiğimiz bir karar; bir işletme sitesi için tek doğru yol olduğunu söylemiyoruz.

JavaScript kapalıyken sayfaya bakmak ve kaynakta metin aramak gibi adımların tamamı web sitesi teslim kabul testi içinde sırayla duruyor. Teklif aşamasında yapabileceğiniz şey daha basit: geliştiricinin daha önce yaptığı bir sitenin hizmet sayfasını açıp kaynağında o sayfanın ilk paragrafını aramak.

Eklenti yükü hızı nasıl etkiler?

WordPress'te hızı belirleyen şey eklentilerin sayısı değil, her eklentinin her sayfaya ne yüklediğidir. Yalnızca yönetim panelinde çalışan bir yedekleme eklentisi ziyaretçinin sayfasına hiçbir dosya eklemeyebilir. Buna karşılık tek bir kaydırıcı ya da sayfa oluşturucu eklentisi, kullanılmayan sayfalarda bile kendi stil ve betik dosyalarını yükleyebilir.

Bu yüzden "en fazla şu kadar eklenti" diye bir sınır vermek yanıltıcı olur; böyle bir eşiği koyan bir belge de bilmiyoruz. Daha işe yarar soru şudur: ana sayfada ve bir hizmet sayfasında tarayıcıya kaç dosya iniyor ve bunların hangisi hangi eklentiden geliyor? Tarayıcının geliştirici araçlarındaki "Ağ" sekmesi bu listeyi verir; dosya yollarında eklenti klasörünün adı genellikle görünür.

Özel yazılımda bu yük baştan daha azdır, çünkü yalnızca yazılan özellik yüklenir. Ama bu bir avantaj olarak kendiliğinden gelmez. Hazır bir arayüz kütüphanesi, ağır bir animasyon paketi ya da üçüncü taraf sohbet betiği özel yazılımı da aynı ölçüde yavaşlatabilir. Hız iki tarafta da bir tasarım kararıdır ve teslimde ölçülüp yazılmalıdır.

Güncellemeyi kim, ne sıklıkta yapacak?

WordPress'in kendi belgesi bu konuda nettir. Updating WordPress sayfası WordPress'in her zaman en son sürüme güncellenmesi gerektiğini, başlamadan önce sitenin yedeğinin alınmasını önerir. Aynı belgeye göre 3.7 ve sonrası sürümlerde küçük sürüm ve güvenlik güncellemeleri çoğu sitede arka planda kendiliğinden uygulanır; büyük özellik sürümleri için ise yönetim panelinde "Update Now" düğmesine basmak gerekir.

Bu belge çekirdeği anlatıyor. Tema ve eklentiler kendi geliştiricilerinden gelen ayrı güncellemelerdir ve her birinin takvimi farklıdır. Bir eklentinin geliştiricisi bakımı bırakırsa, o eklentiyi değiştirmek de sizin ya da bakım yapan tarafın işi olur. WordPress'in güvensiz olduğu söylenemez; ama güvenliği, bu üç katmanın düzenli güncellenmesine bağlıdır ve bu iş birinin takviminde yazılı olmalıdır.

Özel yazılımda güncelleme yükü kaybolmaz, yalnızca görünmez hâle gelir. Kullanılan çatının, programlama dilinin ve açık kaynak kütüphanelerin de güvenlik sürümleri çıkar. Farkı şu: WordPress'te bir panel size "güncelleme var" der, özel yazılımda bunu ancak geliştirici takip eder. Siteyi teslim eden kişi işi bırakırsa, kimsenin haberi olmadan eski sürümde kalan bir sistemle karşılaşabilirsiniz.

İki durumda da sorulacak soru aynıdır: güncellemeyi kim yapacak, ne sıklıkta, yedek nerede tutulacak ve bir güncelleme siteyi bozarsa geri dönüş nasıl olacak? Bu maddelerin sözleşmeye nasıl yazılacağı web sitesi bakım sözleşmesi içinde soru soru duruyor.

Başlık, açıklama ve şema alanları kimin elinde?

WordPress'te her sayfanın başlık etiketi, meta açıklaması ve kanonik adresi genellikle bir SEO eklentisiyle panelden düzenlenir. Bu, içerik ekibinin geliştiriciye gitmeden bir sayfanın başlığını değiştirebilmesi demektir. Aynı eklentiler yapılandırılmış veri de üretir; ama tema da kendi işaretlemesini ekliyorsa sayfada birbiriyle çelişen iki ayrı işaretleme bloğu oluşabilir.

Özel yazılımda bu alanlar kodun içindedir. İyi kurulmuş bir yapıda her sayfa kendi başlığını, açıklamasını ve kanonik adresini bir veri dosyasından ya da veritabanından alır; işaretleme de sayfadaki görünen metinden üretilir. Kötü kurulmuş bir yapıda ise bütün sayfalar aynı başlığı taşır ve değişiklik için her seferinde geliştiriciye iş açmanız gerekir.

Şemayla ilgili beklentiyi de doğru kurmak gerekir. Yapılandırılmış veri, sayfada zaten yazan bilginin makine tarafından okunur kopyasıdır; sayfada olmayan bir bilgiyi yalnızca şemaya koymak doğru değildir. Hangi altyapıyı seçerseniz seçin, sorulacak şey "şema eklenecek mi" değil, "şemadaki adres, telefon ve hizmet adı sayfadaki metinle aynı kalacak mı ve bunu kim kontrol edecek" sorusudur.

Yapay zeka botları sitenize girebilecek mi?

Bot erişimi altyapıdan çok ayarlara bağlıdır ve iki ayrı katmanda kontrol edilir. Birinci katman robots.txt dosyasıdır. OpenAI'ın tarayıcı belgesi OAI-SearchBot'un ChatGPT arama özelliklerinde siteleri göstermek için kullanıldığını, bu botu engelleyen sitelerin ChatGPT arama cevaplarında gösterilmeyeceğini (gezinme bağlantısı olarak yine görünebileceğini) yazar ve botun izinli bırakılmasını önerir. Aynı belge botların JavaScript çalıştırıp çalıştırmadığını söylemez; bu da önceki bölümdeki HTML sorusunu önemli kılar.

İkinci katman sunucunun gerçek yanıtıdır ve WordPress tarafında beklenmedik engel burada çıkabilir. Bazı güvenlik eklentileri ve barındırma firmalarının bot koruma ayarları, robots.txt izin verdiği hâlde tanımadığı tarayıcıları geri çevirebilir. Özel yazılımda aynı rolü genellikle bir CDN veya güvenlik duvarı kuralı oynar ve ayar yine birinin elindedir.

Robots.txt'nin izin verip sunucunun 403 döndürdüğü durumun nasıl tespit edildiğini AI botlarının erişim doğrulaması yazısı anlatıyor. Kod yazmadan bakmak isterseniz AI bot erişim testi aynı adresi farklı bot kimlikleriyle isteyip yanıt kodlarını yan yana gösterir. Testi her güvenlik eklentisi ya da ayar değişikliğinden sonra tekrarlayın.

İçeriği kim, ne sıklıkta girecek?

Bu soru çoğu zaman teknik ölçütlerden daha belirleyicidir. Ayda bir kez fiyat listesi güncelleyen bir işletme ile her hafta yeni ilan, kampanya ya da makale yayımlayan bir işletmenin ihtiyacı farklıdır. İçeriği ekibinizden biri girecekse, o kişinin teknik bilgi olmadan kullanabileceği bir yönetim paneli gerekir.

WordPress bu ihtiyacı kurulduğu gün karşılar: blok düzenleyici, taslak ve yayın durumu, kullanıcı rolleri ve medya kütüphanesi hazırdır. Özel yazılımda aynı paneli yazmak ayrı bir iştir ve teklifte ayrı bir kalem olarak görünmelidir. Panel yerine "değişiklikleri biz yaparız" diyen teklifte her metin düzeltmesi bir iş talebine dönüşür.

Panel ihtiyacı yoksa durum tersine döner: hiç kullanılmayacak bir panel, güncellenmesi gereken ek bir yazılım katmanıdır. Son bir yılda kaç metin değişikliği yapıldığını ve bunları kimin yaptığını yazmak, panelin gerekip gerekmediğini çoğu zaman gösterir.

Ajans değişince site ve içerik taşınabilecek mi?

Taşınabilirlik, işler yolunda giderken kimsenin sormadığı ama ayrılık günü en pahalıya patlayan ölçüttür. WordPress'te içeriği dışarı almanın yerleşik bir yolu vardır. WordPress.org'un Tools Export belgesine göre yazılar, sayfalar, yorumlar, özel alanlar, kategori ve etiketler, menüler ve özel içerik türleri WXR adlı bir XML dosyası olarak indirilebilir ve başka bir WordPress kurulumuna içe aktarılabilir. Belgede sayılan bu listede tema ve eklenti ayarları geçmez; onlar ayrıca taşınır.

Özel yazılımda böyle hazır bir düğme yoktur. İçerik bir veritabanında, bir dosya klasöründe ya da kodun içinde durabilir. Siteyi başka bir ajansa devretmek mümkündür, ama bunun için kaynak kodun size teslim edilmesi, kurulum adımlarının yazılı olması ve kodun yaygın bir dil ve çatıyla yazılmış olması gerekir. Tek bir geliştiricinin bildiği bir yapı pratikte taşınamaz.

Hangi yolu seçerseniz seçin, alan adı, barındırma hesabı, kod deposu ve yönetici erişimleri işletmenin adına olmalıdır. Bu kalemlerin tam listesini ve devir günü sırasını dijital varlık devir listesi veriyor. Altyapı değişikliği adresleri de değiştirecekse, eski adreslerin yenilerine tek tek bağlanması gerekir; eşleme tablosunun nasıl kurulacağını 301 yönlendirme haritası adım adım gösteriyor.

Teklif aşamasında geliştiriciye sorulacak altı soru

Teklifte hangi altyapı yazarsa yazsın, yukarıdaki ölçütlerin her biri bir soruya dönüşür ve bu sorular ancak geliştiricinin yazılı cevabıyla kapanır. Sözlü verilen "tabii, hallederiz" cevabı ayrılık günü bir şey ifade etmez. Bu yüzden soruları teklif aşamasında sorup cevapları sözleşmeye ek olarak almanızı öneririz:

1. Sayfalar sunucuda mı üretiliyor, derleme sırasında mı, yoksa tarayıcıda mı çiziliyor?
2. WordPress ise hangi tema ve hangi eklentiler kurulacak, her biri sayfaya ne yükleyecek?
3. Çekirdek, tema, eklenti ya da kütüphane güncellemelerini kim yapacak ve yedek nerede tutulacak?
4. Başlık, açıklama ve kanonik adresi panelden mi değiştireceğiz, kod değişikliği mi gerekecek?
5. Güvenlik eklentisi veya bot koruması kurulacaksa yapay zeka tarayıcılarına nasıl davranacak?
6. Ayrılırsak içerik, kaynak kod ve kurulum belgesi hangi biçimde teslim edilecek?

Bu altı sorunun cevabı açık ve yazılıysa, altyapının adı ikinci planda kalır. Kurumsal site kurulumunda hazır altyapı mı özel geliştirme mi seçildiğini ve nedenini nasıl yazılı verdiğimizi kurumsal web sitesi kurulumu sayfasında görebilirsiniz. Online satış yapacaksanız soru başka ölçütlerle sorulur; o durumda e-ticaret altyapısı seçimi için kurulmuş karar çerçevesinden başlamak daha doğru olur.

Üç işletme, üç farklı cevap: senaryo karşılaştırması

Yukarıdaki ölçütleri somutlaştırmak için üç varsayımsal işletmeyi yan yana koyalım. Birincisi sekiz sayfalık bir hizmet sitesi isteyen bir güzellik salonu: hizmetler, fiyat sayfasına yönlendirme, ekip, iletişim ve birkaç SSS. İkincisi her hafta yeni portföy ilanı ve bölge yazısı yayımlayan bir emlak ofisi. Üçüncüsü ziyaretçinin metrekare ve malzeme seçip ön teklif aldığı, ardından keşif randevusu ayarladığı bir tadilat firması.

Salon için iki yol da işe yarar ve belirleyici olan bakım yüküdür. Sayfalar nadiren değişiyorsa soru, düzenli güncelleme isteyen bir kurulumu kimin takip edeceğidir. WordPress seçilirse az sayıda, ne yüklediği bilinen eklentiyle kurmak hızın ve güvenliğin büyük kısmını çözer.

Emlak ofisinde terazi WordPress'e doğru eğilir. Haftalık içerik akışı bir panel ister ve bu panel hazır gelir; ilan yönetimi için hazır eklentiler de var, ama seçilen eklentinin bakımının sürüp sürmediğine ayrıca bakılmalı. Burada asıl iş altyapı seçimi değil, güncellemenin bir bakım sözleşmesine bağlanması ve ilan sayfalarının kaynağında metnin bulunduğunun teslimde test edilmesidir.

Tadilat firmasında ise özel geliştirmenin gerekçesi güçlenir. Teklif hesaplama ve randevu kaydı işletmeye özgü kurallar taşır; bunu bir eklentiyle zorlamak, ileride değiştirilmesi zor bir yapı doğurabilir. Yine de tek yol bu değildir: tanıtım sayfaları WordPress'te kalıp hesaplama modülü ayrıca yazılabilir. Hangi yol seçilirse seçilsin, hizmet sayfalarının metni sunucudan gelmeli, kaynak kod ve kurulum belgesi işletmeye teslim edilmelidir. İşletmeniz bu üçüne tam benzemiyorsa tablodaki satırları kendi cevaplarınızla doldurun.

Sıkça Sorulan Sorular

WordPress siteler Google'da daha mı iyi sıralanır?

Altyapının adı tek başına bir sıralama nedeni değildir; Googlebot hangi yazılımın çalıştığını değil, sunucudan gelen sayfayı görür ve sayfayı içeriğine, erişilebilirliğine ve sorguyla ilgisine göre değerlendirir. WordPress doğru kurulduğunda temiz HTML ve düzenlenebilir başlıklar üretir; ama ağır bir tema, çok dosya yükleyen eklentiler veya birbirini tekrar eden başlıklar aynı siteyi geride bırakabilir. Belirleyici olan altyapının adı değil, kurulumun kalitesi ve bakımıdır.

Özel yazılım site yapay zeka aramalarında avantaj sağlar mı?

Kendiliğinden sağlamaz. Yapay zeka tarayıcıları için önemli olan, sayfanın metninin sunucunun ilk yanıtında bulunması ve botların robots.txt ile güvenlik katmanında geri çevrilmemesidir. Sayfayı yalnızca tarayıcıda JavaScript ile çizen bir özel yazılım, JavaScript çalıştırmayan botlara boş görünebilir; sunucuda ya da derleme sırasında HTML üreten bir özel yazılım ise WordPress kadar okunabilir olur.

WordPress'te kaç eklenti siteyi yavaşlatır?

Belirleyici olan sayı değil, her eklentinin ziyaretçinin sayfasına hangi dosyaları yüklediğidir. Yalnızca yönetim panelinde çalışan bir eklenti sayfa hızını etkilemeyebilir, tek bir sayfa oluşturucu ise her sayfaya stil ve betik dosyası ekleyebilir. Tarayıcının geliştirici araçlarındaki ağ listesinde dosyaların hangi eklenti klasöründen geldiğine bakarak gerçek yükü görebilirsiniz.

WordPress sitemi güncellemezsem ne olur?

WordPress'in kendi güncelleme belgesi sitenin her zaman en son sürümde tutulmasını ve güncellemeden önce yedek alınmasını öneriyor; 3.7 ve sonrası sürümlerde küçük ve güvenlik güncellemeleri çoğu sitede kendiliğinden uygulanırken büyük sürümler için panelden onay gerekiyor. Tema ve eklentiler ayrı güncellenir. Bu katmanlar eski sürümde kalırsa giderilmiş güvenlik açıkları sitenizde açık kalabilir; bu yüzden güncellemeyi kimin yapacağı bir bakım planında yazılı olmalıdır.

Özel yazılımla yapılan siteyi başka bir ajansa devredebilir miyim?

Devredebilirsiniz, ama bunun için kaynak kodun size teslim edilmiş olması, kurulum ve yayına alma adımlarının yazılı olması ve kodun yaygın bir dil ve çatıyla yazılmış olması gerekir. Alan adı, barındırma hesabı ve kod deposu işletmenin adına kayıtlı olmalıdır. Bu koşullar sözleşmede yazılı değilse, kod teknik olarak sizin olsa bile yeni bir ajansın onu devralması zor ve zaman alıcı olabilir.