WordPress'ten Özel Kodlanmış Siteye Geçiş: Tam Rehber

WordPress'ten özel kodlanmış siteye geçiş, orta ölçekli bir kurumsal sitede tipik olarak 6-12 hafta sürer ve doğru kurgulanmış 301 yönlendirmelerle SEO kaybı yaratmaz. Doğru karar WordPress'in kötü olması değil; eklenti bağımlılığının, güvenlik yükünün ve performans tavanının işinizi yavaşlatmaya başlamasıdır.

Bu yazı bir WordPress eleştirisi değil. WordPress, W3Techs'in Eylül 2026 ölçümüne göre tüm web sitelerinin %40,7'sini, içerik yönetim sistemi kullanan sitelerin ise %58,9'unu çalıştırıyor. Bu ölçekte bir platform tesadüfen bu noktaya gelmedi.

Ama her aracın bir çalışma aralığı var. Türkiye'de kurumsal sitelerin büyük kısmı 3-5 yıl önce hazır bir temayla kurulup üzerine 25-40 eklenti yığılarak bugüne geldi. O site artık her güncellemede tökezliyor, PageSpeed skoru 30'lara düşmüş ve her yeni özellik "bunu yapan bir eklenti var mı?" sorusuyla başlıyor. Bu yazı tam olarak o noktada ne yapılması gerektiğini anlatıyor: geçmeli misiniz, geçerseniz süreç nasıl işler ve arama motorundaki konumunuzu nasıl korursunuz.

İçindekiler

• WordPress'ten Çıkma Zamanı: 6 Gerçek Sinyal
• WordPress'te Kalmanın Daha Doğru Olduğu Durumlar
• Özel Kodlanmış Site Nedir, Ne Değildir?
• WordPress ve Özel Kod: Yan Yana Karşılaştırma
• Üç Yıllık Toplam Maliyet Karşılaştırması
• Ara Yol: Headless WordPress
• Geçiş Süreci: 8 Adımlık Yol Haritası
• SEO'yu Kaybetmeden Geçiş Kontrol Listesi
• Geçişte En Sık Yapılan 5 Hata
• Sıkça Sorulan Sorular

WordPress'ten Çıkma Zamanı: 6 Gerçek Sinyal

Geçiş kararı duygusal değil, ölçülebilir olmalı. Aşağıdaki sinyallerden üç veya daha fazlası sizde varsa masaya yatırmanın zamanı gelmiştir.

1. Eklenti sayınız kontrolden çıktı. Her eklenti sayfaya kendi CSS'ini, JavaScript'ini ve veritabanı sorgularını ekler. 30 eklentili bir sitede tek bir düğmenin görünmesi için onlarca dosya indirilir. Daha kötüsü, eklentiler birbirinin ayağına basar: biri güncellenince diğeri bozulur.

2. Güvenlik yükü taşınamaz hale geldi. Patchstack'in 2026 WordPress güvenlik raporuna göre 2025'te ekosistemde 11.334 yeni güvenlik açığı raporlandı; bu, bir önceki yıla göre %42 artış demek. Açıkların %91'i eklentilerde, %9'u temalarda bulundu; WordPress çekirdeğinde ise sadece 6 açık raporlandı. Yani sorun çekirdek değil, üzerine kurduğunuz eklenti yığını.

3. Yamalar sizi bekletiyor. Aynı rapor, açıkların %46'sının ifşa edildiği anda yamasının bile bulunmadığını ve yoğun hedeflenen açıkların medyan 5 saat içinde istismar edilmeye başlandığını gösteriyor. Yüksek etkili açıkların yaklaşık yarısı ilk 24 saatte kullanılıyor. Haftada bir güncelleme yapan bir işletme bu tempoya yetişemez.

4. Hız duvara tosladı. HTTP Archive'ın Core Web Vitals teknoloji raporunda WordPress siteleri üç metriği birden geçme oranında %45 bandında dolaşıyor. Sorun genellikle tepki hızında değil, yüklenmede: hazır tema + sayfa oluşturucu + eklenti kombinasyonu ana sayfada megabaytlarca varlık indiriyor. Sitenizin bugünkü durumunu ölçmek isterseniz ücretsiz site analizi aracımızla başlayabilirsiniz.

5. Her yeni istek "eklenti var mı?" sorusuna dönüşüyor. Bayi girişi, teklif formu akışı, ERP'den fiyat çekme, üyeye özel fiyat gösterme... Bunlar iş süreçleridir ve hazır bir eklentinin varsayımlarına sığmazlar. Zorlandığınız her yerde ya para ödeyip esneklikten ya da esneklik için koddan taviz verirsiniz.

6. Tema geliştiricisi ortadan kayboldu. Ticari temanız güncellenmiyorsa yalnızca yeni özellik almıyor değilsiniz; PHP sürümü yükseldiğinde site çökme riskiyle karşı karşıyasınız. Patchstack, yalnız bir yıl içinde güvenlik açığı yamalanmadığı için resmî depodan 1.614 eklenti ve tema kaldırıldığını bildiriyor.

Bu sinyalleri tek tek okumak yanıltıcı olabilir. Belirleyici olan birikimdir: siteyi ayakta tutmak için harcanan saat, yeni iş üretmek için harcanan saatten fazlaysa altyapı artık size hizmet etmiyor demektir.

WordPress'te Kalmanın Daha Doğru Olduğu Durumlar

Bir ajansın "geçin" demesi beklenir. Biz tersini söyleyeceğiz: aşağıdaki tabloya giriyorsanız WordPress'te kalın, parayı geçişe değil içeriğe ve reklama harcayın.

• Site esas olarak bir blogsa. İçerik üretimi ağırlıklı, ayda 10-30 yazı yayımlayan bir yapıda WordPress'in editör deneyimi hâlâ güçlü bir avantaj. Özel kod bu senaryoda size hız kazandırmaz, sadece maliyet ekler.
• Ekibiniz içeriği kendi yönetiyor ve memnun. Pazarlama ekibi sayfa açıp düzenleyebiliyorsa ve bu süreçte tıkanma yaşanmıyorsa, çalışan sistemi değiştirmenin somut bir getirisi yok.
• Site 10-15 sayfalık bir tanıtım sitesiyse. Kartvizit ölçeğinde bir sitede özel kodun kazandıracağı milisaniyeler, geçiş bütçesini çıkarmaz.
• Bütçeniz geçiş sonrası bakımı kaldırmıyorsa. Özel yazılım da bakım ister. Yıllık bakım bütçesi ayıramayacaksanız iyi kurulmuş bir WordPress, kötü bakılan özel bir yazılımdan daha güvenlidir.
• Eklenti sayınız 10'un altındaysa ve site hızlıysa. Sorun yoksa çözüm aramayın. Önce site hızlandırma çalışması yapın; çoğu durumda alınacak yol vardır.

WordPress'in kendisi de duruyor olmayacak. Resmî WordPress yol haritası 2026 için üç ana sürüm ve blok editöründe gerçek zamanlı ortak düzenleme hedefliyor. Platform gelişmeye devam ediyor; karar "hangisi daha iyi" değil, "benim iş modelimde hangisi daha az sürtünme yaratıyor" sorusunun cevabı olmalı.

Özel Kodlanmış Site Nedir, Ne Değildir?

Özel kodlanmış site, hazır bir tema ve eklenti yığını yerine yalnızca sizin ihtiyacınız için yazılmış bir yazılımdır. Arayüz genelde modern bir framework ile üretilir, içerik yönetimi için sadeleştirilmiş bir panel yazılır ve entegrasyonlar doğrudan API üzerinden kurulur.

Ne değildir? Panelsiz bir site değildir. Sık karşılaştığımız yanlış inanış şu: "Özel yazılım olursa içeriği kendim güncelleyemem." Doğru kurgulanmış bir özel projede yönetim paneli işin parçasıdır ve WordPress panelinden genellikle daha sadedir, çünkü içinde sizin kullanmadığınız 200 ayar yoktur.

Ayrıca "her şey sıfırdan yazılır" da demek değildir. Kimlik doğrulama, ödeme, e-posta gönderimi gibi çözülmüş problemler için olgun kütüphaneler kullanılır. Özel olan iş mantığıdır: sizin fiyatlandırma kurallarınız, sizin onay akışınız, sizin bayi hiyerarşiniz.

Bu ayrımı daha geniş bir çerçevede hazır web sitesi ile özel tasarım karşılaştırmamızda ele almıştık; bu yazı ise özellikle mevcut bir WordPress sitesinden çıkış senaryosuna odaklanıyor.

WordPress ve Özel Kod: Yan Yana Karşılaştırma

Tablodaki en kritik satır sondan ikinci değil, sonuncudan bir öncekidir: geliştirici bulma. WordPress'in en büyük gücü ekosisteminin genişliğidir. Özel yazılıma geçerken sözleşmenizde kaynak kod teslimi, dokümantasyon ve devir teslim maddelerinin bulunması bu riski yönetmenin tek yoludur. Bu konudaki kriter listesini yazılım firması seçim rehberimizde ayrıntılı anlattık.

Üç Yıllık Toplam Maliyet Karşılaştırması

Karar tek seferlik fiyata bakılarak verilirse neredeyse her zaman WordPress kazanır. Üç yıllık toplam sahip olma maliyetine bakıldığında tablo değişir. Aşağıdaki senaryo, orta ölçekli bir kurumsal site içindir; rakamlar 2026 Türkiye piyasa aralıklarıdır.

Tablodaki mesaj "özel kod daha ucuz" değil. Mesaj şu: aralıklar kesişiyor. Eklenti lisansları ve düzeltme işleri belli bir eşikten sonra WordPress'i özel yazılım maliyetine yaklaştırıyor. Yıllık lisans yenilemeleri dolar bazlı olduğu için kur hareketleri bu kalemi öngörülemez hale getiriyor; özel yazılımda ise maliyetin büyük kısmı bir kez ödeniyor ve yıllık bakım genelde proje bedelinin %10-20'si kadar kalıyor.

Kendi projenizde bu rakamların nereye oturduğunu görmek için web sitesi fiyat hesaplayıcımızı kullanabilirsiniz; sayfa sayısı, dil ve entegrasyon seçimlerine göre gerçekçi bir aralık üretiyor.

Bir uyarı: geçiş maliyetini yalnızca yazılım kalemiyle hesaplamayın. İçerik taşıma, yeniden yazım, görsel optimizasyonu ve geçiş sonrası izleme de bütçenin parçasıdır. Yüzlerce yazısı olan bir blogda içerik taşıma tek başına projenin en uzun kalemi olabilir.

Ara Yol: Headless WordPress

Her geçiş "ya hep ya hiç" olmak zorunda değil. Headless yaklaşımda WordPress arka planda içerik yönetim sistemi olarak kalır, ziyaretçinin gördüğü arayüz ise modern bir framework ile ayrı yazılır. İçerik ekibi alıştığı panelde çalışmaya devam eder, ziyaretçi ise statik hızda bir site görür.

Bu yaklaşım şu durumlarda mantıklıdır:

• İçerik ekibiniz kalabalık ve WordPress editörüne bağımlı.
• Asıl derdiniz hız ve arayüz esnekliği, içerik yönetimi değil.
• Yüzlerce yazılık bir arşiviniz var ve taşımak istemiyorsunuz.

Ama sihirli değnek de değildir. Sektör ölçümleri, headless geçişlerin önemli bir bölümünün lansman sonrasında Core Web Vitals skorlarında geçici bir düşüş yaşadığını gösteriyor; sebep genellikle optimize edilmemiş API gecikmeleri ve ağırlaşan arayüz kodu. Yani headless, iyi mühendisliğin yerine geçmez; iyi mühendisliğe zemin hazırlar. Ayrıca artık iki sistemi birden yönetirsiniz: WordPress'in güvenlik güncellemeleri de, framework'ün bakımı da devam eder.

Kararı sadeleştiren soru şu: içerik mi karmaşık, iş süreçleri mi? İçerik karmaşıksa headless; iş süreçleri karmaşıksa tam özel yazılım daha doğru adrestir.

Geçiş Süreci: 8 Adımlık Yol Haritası

Aşağıdaki akış, web yazılım projelerimizde uyguladığımız sıradır. Sıralamayı bozmak, özellikle 1. ve 2. adımı atlamak, geçişteki trafik kayıplarının başlıca sebebidir.

1. Envanter ve tarama (3-5 gün). Mevcut sitenin tamamı taranır. Her URL, HTTP durum kodu, canonical etiketi, indekslenebilirlik durumu ve trafik verisiyle birlikte listelenir. Search Console ve analitik verileri bu listeye eklenir. Çıktı: tek bir tabloda tüm site.

2. İçerik kararı (3-5 gün). Her sayfa dört kovadan birine düşer: aynen taşınacak (trafiği ve backlink'i güçlü), iyileştirilecek (URL sabit, içerik güncellenecek), yönlendirilecek (kaldırılacak ama değeri var) veya kapatılacak (trafiği yok, değeri yok). Bu adım geçişi aynı zamanda bir içerik temizliği fırsatına çevirir.

3. Yönlendirme haritası (2-3 gün). Eski URL → yeni URL eşlemesi hazırlanır. Bu, geçişin en kritik çıktısıdır ve geliştirme başlamadan önce hazır olmalıdır. Kalıcı taşımalarda 301 kullanılır; kalıp bazlı eşleşmeler (örneğin /kategori/* → /hizmetler/*) toplu kurallarla yazılır.

4. Tasarım ve prototip (2-3 hafta). Sayfa şablonları çıkarılır. Yeni siteyi eski sitenin birebir kopyası yapmaya çalışmayın; ama başlık hiyerarşisini ve içerik derinliğini koruyun. Google, taşıdığınız sayfanın hâlâ aynı soruya cevap verdiğini görmek ister.

5. Geliştirme ve içerik aktarımı (3-6 hafta). Arayüz, yönetim paneli ve entegrasyonlar yazılır. İçerik veritabanından programatik olarak aktarılır; elle kopyalama yalnızca az sayfalı sitelerde mantıklıdır. Görseller bu aşamada modern formatlara dönüştürülür.

6. Sahne provası (1 hafta). Site, arama motorlarına kapalı bir test ortamında ayağa kaldırılır. Tüm yönlendirmeler test edilir, formlar denenir, analitik ve dönüşüm takibi doğrulanır. Eski URL listesi baştan sona taranır: hepsi 301 dönmeli, 404 veya 302 dönmemeli.

7. Yayına alma (1 gün). Geçiş tercihen haftanın ortasında ve düşük trafikli saatte yapılır; cuma akşamı yayına almak, hafta sonu boyunca sorunla yaşamak demektir. Yayın anında robots.txt kontrol edilir, "arama motorlarını engelle" seçeneğinin kapalı olduğu doğrulanır ve yeni site haritası Search Console'a gönderilir.

8. İzleme (90 gün). İlk iki hafta günlük, sonrasında haftalık takip yapılır. İzlenecekler: indekslenen sayfa sayısı, tarama hataları, organik tıklama ve gösterim, ilk 20 anahtar kelimedeki konumlar ve Core Web Vitals.

Toplam takvim, orta ölçekli bir kurumsal sitede 6-12 hafta bandındadır. Yüzlerce sayfalı veya e-ticaret içeren projelerde bu süre uzar.

SEO'yu Kaybetmeden Geçiş Kontrol Listesi

Geçişte sıralama kaybının sebebi neredeyse hiçbir zaman "yeni teknoloji" değildir; eksik yönlendirme, değişen içerik derinliği ve kaçırılan teknik ayarlardır. Google'ın resmî site taşıma dokümanı da aynı çerçeveyi çiziyor.

• Yayından önce tüm eski URL'lerin tam listesi çıkarıldı.
• Her eski URL için birebir hedef belirlendi; toplu olarak ana sayfaya yönlendirme yapılmadı.
• Yönlendirmeler 301 (kalıcı) olarak kuruldu ve zincir oluşturmuyor.
• Yönlendirmeler en az 180 gün açık kalacak şekilde planlandı.
• Sayfa başlıkları, meta açıklamalar ve H1'ler taşındı veya bilinçli olarak iyileştirildi.
• Yapısal veri işaretlemeleri (kurum, ürün, SSS) yeni sitede yeniden kuruldu.
• Canonical etiketleri yeni URL'leri gösteriyor.
• robots.txt'de istenmeyen Disallow satırı yok; noindex etiketleri temizlendi.
• XML site haritası güncellendi ve Search Console'a gönderildi.
• Dahili linkler yeni URL'lere işaret ediyor; eski linkler yönlendirmeye bırakılmadı.
• Görsel URL'leri ve alt metinleri korundu.
• Analitik ve dönüşüm hedefleri yayından önce test edildi.
• Alan adı değişiyorsa Search Console'un adres değişikliği aracı kullanıldı.

Doğru yürütülen bir geçişte sinyaller genellikle 2-6 hafta içinde yeni URL'lerde toplanır; tam oturma ise 2-3 ayı bulabilir. İlk haftalarda görülen dalgalanma normaldir, panikle geri dönüş yapmak asıl zararı verir. Aynı disiplini yenileme projeleri için web sitesi yenileme rehberimizde de anlatmıştık.

Geçişte En Sık Yapılan 5 Hata

1. Yönlendirme haritasını sona bırakmak. Site yayına alındıktan sonra "şimdi yönlendirmeleri yazalım" denen her projede birkaç gün boyunca yüzlerce URL 404 döner. Google bu süreyi affetmek zorunda değil.

2. Her şeyi ana sayfaya yönlendirmek. Toplu ana sayfa yönlendirmesi Google tarafından yumuşak 404 olarak değerlendirilebilir ve sayfanın biriktirdiği değer aktarılmaz. Her URL kendi en yakın karşılığına gitmelidir.

3. İçeriği kısaltmak. Yeni tasarım "daha sade" olsun diye 1.800 kelimelik bir hizmet sayfası 400 kelimeye indirildiğinde sıralama da düşer. Tasarımı yenilerken metni koruyun; iyileştirme yapacaksanız geçişten sonra, ayrı bir adımda yapın.

4. Eski siteyi hemen kapatmak. Sunucuyu erken kapatmak, karşılaştırma ve geri dönüş imkânını yok eder. Eski ortamı en az birkaç ay yedekli tutun.

5. Geçişi tek seferlik iş sanmak. Yayın günü işin bitişi değil, izleme döneminin başlangıcıdır. 90 günlük takip planı olmayan geçişlerde sorunlar aylar sonra fark edilir.

Sıkça Sorulan Sorular

WordPress'ten özel kodlanmış siteye geçiş SEO'mu düşürür mü?

Doğru yapılan bir geçişte kalıcı kayıp yaşanmaz. Her eski URL 301 ile yeni karşılığına yönlendirilir, içerik derinliği korunur ve site haritası güncellenirse sinyaller 2-6 hafta içinde yeni adreslere taşınır. Kayıpların sebebi teknoloji değişimi değil, eksik yönlendirme ve kısaltılmış içeriktir.

Geçiş ne kadar sürer?

Orta ölçekli bir kurumsal sitede toplam süreç 6-12 haftadır. Bunun 1-2 haftası envanter ve içerik kararı, 2-3 haftası tasarım, 3-6 haftası geliştirme ve içerik aktarımı, 1 haftası test ve yayındır. Yüzlerce ürünlü e-ticaret projelerinde süre uzar.

WordPress'ten çıkınca içeriğimi kendim güncelleyebilir miyim?

Evet. Özel kodlanmış projelerde yönetim paneli işin standart parçasıdır; sayfa, blog yazısı, görsel ve menü yönetimi panelden yapılır. Fark şu ki panel yalnızca sizin kullandığınız alanları içerir, bu yüzden genelde WordPress panelinden daha sadedir.

Blog yazılarım ve yorumlarım taşınır mı?

Taşınır. İçerik WordPress veritabanından programatik olarak aktarılır; yazılar, kategoriler, etiketler, görseller ve yazar bilgileri korunur. Yorumların taşınması da mümkündür, ancak yorum hacmi düşükse birçok işletme bu aşamada yorumları arşivlemeyi tercih eder.

Özel yazılım daha mı güvenli?

Saldırı yüzeyi daha dardır çünkü kodunuz binlerce sitede çalışan bir eklenti değildir; otomatik tarayan botlar bilinen bir açığı sizde deneyemez. Ancak bu mutlak güvenlik anlamına gelmez: kullanılan kütüphanelerin güncellenmesi ve düzenli güvenlik bakımı yine gereklidir.

Alan adım ve e-postalarım etkilenir mi?

Etkilenmez. Geçiş yalnızca web sitesinin çalıştığı yazılımı değiştirir; alan adı aynı kalır. E-posta hizmetiniz farklı bir sunucuda çalışıyorsa hiç dokunulmaz, aynı sunucudaysa DNS kayıtları taşıma öncesinde not edilip yeni ortamda birebir kurulur.

Aynı anda hem WordPress hem özel yazılım kullanabilir miyim?

Kullanabilirsiniz. Yaygın yöntem, blogu WordPress'te bırakıp kurumsal sayfaları ve iş süreçlerini özel yazılıma taşımaktır; ya da headless yaklaşımla WordPress'i yalnızca içerik deposu olarak çalıştırmaktır. İki sistemi de bakımda tutmayı planlamanız gerekir.

Geçişten sonra bakım maliyetim ne olur?

Özel yazılımda yıllık bakım genellikle proje bedelinin %10-20'si kadardır ve kütüphane güncellemeleri, güvenlik yamaları, yedekleme ve küçük geliştirmeleri kapsar. WordPress tarafında ise bu kaleme ticari eklenti ve tema lisans yenilemeleri de eklenir; lisanslar dolar bazlı olduğu için kur riski taşır.

WordPress'ten çıkmak bir başarısızlık itirafı değil, bir ölçek kararıdır. Sitenizin çözdüğü problem "içerik yayınlamak"tan "iş süreci yürütmek"e dönüştüğü anda hazır bir sistemin varsayımları size dar gelmeye başlar. Sinyaller nettir: eklenti yığını, güvenlik yükü, hız duvarı ve her yeni isteğin bir eklenti aramasına dönüşmesi.

Karar vermeden önce iki şeyi yapın. Önce mevcut sitenizi ölçün — hız, güvenlik ve içerik envanteri elinizde olmadan hiçbir geçiş planı gerçekçi olmaz. Sonra üç yıllık toplam maliyeti karşılaştırın, tek seferlik fiyatı değil. Projenizin kapsamını konuşmak ve gerçekçi bir takvim çıkarmak için web tasarım hizmetimizi inceleyebilir veya doğrudan bize ulaşabilirsiniz; geçiş gerekli değilse bunu da açıkça söyleriz.