17 WordPress’in Yapabilecekleri: 2025 İçin Teknik Bir Derinlemesine İnceleme

WordPress, internetteki tüm web sitelerinin %43’ünden fazlasına güç sağlamaktadır — bu istatistik, platformun kişisel bloglardan kurumsal SaaS panolarına kadar web yayıncılığının her kategorine ne kadar derinden nüfuz ettiğini tam olarak yansıtmamaktadır. WordPress, özünde PHP ve MySQL/MariaDB üzerine inşa edilmiş açık kaynaklı bir içerik yönetim sistemidir ve doğru mimariyle eşleştirildiğinde tam bir uygulama çerçevesi olarak işlev görebilir.

Bu kılavuz, yüzeysel özellik listesinin ötesine geçmektedir. Aşağıdaki her özellik, bir geliştirici veya sistem yöneticisinin bilinçli kararlar alması için ihtiyaç duyduğu teknik derinlikle incelenmektedir — eklenti seçimleri, veritabanı etkileri, sunucu tarafı gereksinimleri ve yalnızca üretim ortamlarında ortaya çıkan gerçek dünya tuzakları dahil.

Barındırma Katmanının WordPress’in Gerçekte Neler Sunabileceğini Neden Belirlediği

WordPress özelliklerini incelemeden önce, bir mimari gerçeğin vurgulanması gerekmektedir: barındırma ortamı pasif bir kap değildir — aşağıda açıklanan her özelliği aktif olarak kısıtlar ya da serbest bırakır. NVMe depolama, PHP 8.2+ ve OPcache etkin şekilde yapılandırılmış bir VPS Hosting ortamında çalışan bir WordPress örneği, kısıtlı I/O’ya sahip paylaşımlı altyapıdaki aynı kod tabanından kategorik olarak farklı performans gösterecektir.

Bu ayrım önemlidir; çünkü geliştiricilerin şikayet ettiği pek çok WordPress “sınırlaması” aslında barındırma sınırlamalarıdır — yavaş yönetici panelleri, WooCommerce içe aktarmalarında zaman aşımları, başarısız cron işleri ve bellek tavanı ihlallerinden kaynaklanan eklenti çakışmaları.

1. Her Türlü Web Sitesi Oluşturun — Uygulama Benzeri Platformlar Dahil

WordPress artık üzerine uzantılar eklenmiş bir blog aracı değildir. Mimarisi özel gönderi türlerini (CPT’ler), özel taksonomileri ve React, Vue veya Next.js ile oluşturulmuş ayrıştırılmış ön uçlara veri besleyen başsız bir CMS olarak işlev görmesini sağlayan bir REST API’yi desteklemektedir.

Teknik açıdan ne anlama geldiği:

• CPT’ler, ilişkisel veritabanı şemasına doğrudan dokunmadan keyfi veri yapılarını modellemenize olanak tanır — emlak ilanları, iş panoları, ürün katalogları.

register_post_type() ve register_taxonomy() fonksiyonları bu yapıları otomatik olarak WP REST API aracılığıyla sunar.
Başsız WordPress kurulumları PHP render katmanını tamamen ayırır; WordPress yalnızca içerik yönetimi ve kimlik doğrulamasını üstlenirken bir JavaScript ön ucuna JSON sunar.

Üretim tuzağı: Yüz binlerce gönderiye sahip CPT ağırlıklı siteler, wp_posts tablo indeksleme stratejisine dikkatli bir şekilde odaklanmayı gerektirir. Uygun veritabanı optimizasyonu olmadan, büyük veri kümelerindeki WP_Query çağrıları tam tablo taramalarına neden olarak yanıt sürelerini üstel olarak düşürür.
2. Ölçekte İçerik Yönetimi — Blok Editörünün Ötesinde
WordPress 5.0’da tanıtılan Gutenberg blok editörü, TinyMCE tabanlı Klasik Editörün yerini aldı ve içeriğin nasıl depolandığını köklü biçimde değiştirdi. İçerik artık ham HTML yerine blok grameri olarak serileştirilmektedir — blok türünü ve özelliklerini kodlayan yapılandırılmış HTML yorumları.
Temel teknik çıkarımlar:

Blok verileri wp_posts.post_content içinde serileştirilmiş biçimlendirme olarak depolanır; bu da SQL sorgularındaki regex tabanlı içerik manipülasyonunu kırılgan hale getirir.
WordPress 5.9’dan itibaren kullanılabilen Tam Site Düzenleme (FSE) sistemi, blok düzenlemeyi üstbilgiler, altbilgiler ve şablonlara genişleterek bunları wp_template ve wp_template_part özel gönderi türlerinde depolar.
Editoryal ekipler için yerel revizyon sistemi, her kaydetmeyi wp_posts içinde post_type = 'revision' ile yeni bir satır olarak depolar; bu durum yoğun trafikli editoryal sitelerde veritabanını önemli ölçüde şişirebilir. wp_delete_post_revisions() veya WP-Sweep gibi bir eklenti aracılığıyla zamanlanmış temizlik zorunludur.

3. WooCommerce: Üretim e-Ticaret Mağazası İşletmek
WooCommerce, WordPress’i tam bir e-ticaret platformuna dönüştürür; ancak bunu doğru şekilde yapmak, yalnızca eklentiyi yüklemek değil, veritabanı mimarisini ve sunucu gereksinimlerini anlamayı gerektirir.
WooCommerce veritabanı ayak izi:
WooCommerce 12’den fazla özel veritabanı tablosu ekler ve sipariş verilerini wp_posts, wp_postmeta, wp_woocommerce_order_items ve wp_woocommerce_order_itemmeta genelinde depolar. Yüksek hacimli mağazalar bu tablolarda hızla milyonlarca satır biriktirir.
Üretim WooCommerce için kritik sunucu tarafı gereksinimleri:

Minimum 256MB PHP bellek sınırı (memory_limit = 256M içinde php.ini)
Toplu işlemler için en az 300 saniyeye ayarlanmış max_execution_time

Ödeme ağ geçidi mimarisi: WooCommerce, ödeme ağ geçidi API’si aracılığıyla Stripe, PayPal ve düzinelerce bölgesel ağ geçidini destekler. Her ağ geçidi woocommerce_payment_gateways kancasına bağlanır ve işlemleri sunucu tarafında işler; bu da sunucunuzun giden SSL/TLS yapılandırmasının güncel olması gerektiği anlamına gelir. WooCommerce’i geçerli SSL Sertifikaları ile eşleştirmek, pazarlık konusu olmayan bir güvenlik ve PCI-DSS uyumluluk gereksinimidir.

Gerçek dünya uç durumu: WooCommerce’in wp_posts içindeki varsayılan sipariş depolama (“posts tablosu” mimarisi), siparişleri özel tablolara taşıyan Yüksek Performanslı Sipariş Depolama (HPOS) ile değiştiriliyor. Eklenti uyumluluğunu önceden test etmeden mevcut bir mağazada HPOS’u etkinleştirmek, 2024-2025 geçişlerinde veri bütünlüğü sorunlarının en yaygın nedenlerinden biridir.

4. Tasarım Özelleştirme — Kodsuzdan Tam Tema Geliştirmeye

WordPress, sürükle-bırak görsel oluşturuculardan ham PHP şablon hiyerarşisi manipülasyonuna uzanan katmanlı bir özelleştirme modeli sunar.

WordPress özelleştirmesinin üç katmanı:

Tema mimarisi notu: Blok temalar (FSE ile tanıtılan), tüm blok editörüne yayılan tasarım tokenlarını — renk paletleri, tipografi ölçekleri, boşluk ön ayarları — tanımlamak için theme.json kullanır. Klasik temalar, aşamalı olarak kullanımdan kaldırılan functions.php ve Özelleştirici API’ye dayanır. Eski eklenti uyumluluğu gerektirmedikçe yeni projeler varsayılan olarak blok temalara yönelmelidir.

Sayfa oluşturucuların performans etkisi: Elementor ve benzeri araçlar önemli miktarda DOM şişkinliği oluşturur ve birden fazla CSS/JS varlığı yükler. Sunucu tarafı önbelleğe alma (FastCGI önbelleği veya Redis tam sayfa önbelleği) ile düzgün yapılandırılmış bir VPS’de bu ek yük büyük ölçüde azaltılır. Önbellek katmanı olmayan paylaşımlı barındırmada, sayfa oluşturucular İlk Bayta Kadar Geçen Süreyi (TTFB) düzenli olarak 2 saniyenin üzerine çıkarır.

5. Eklenti Ekosistemi — 59.000’den Fazla Uzantı ve Beraberinde Gelen Riskler

WordPress eklenti deposu 59.000’den fazla eklenti içermekte olup Envato gibi pazaryerleri aracılığıyla ticari olarak binlercesi daha mevcuttur. Bu genişlik hem WordPress’in en büyük gücü hem de en önemli operasyonel riskidir.

Deneyimli yöneticilerin yeni başlayanların bilmediği şeyler:

• Eklenti çakışmaları, WordPress site hatalarının başlıca nedenidir. wp_head, wp_footer veya çekirdek eylem kancalarına bağlanan her eklenti, her sayfa yüklemesinde yürütme ek yükü ekler.
• Terk edilmiş eklentiler bir güvenlik yükümlülüğü oluşturur. 24+ ay boyunca güncelleme almamış bir eklenti yamalanmamış güvenlik açıkları içerebilir. WordPress Eklenti Dizini, 2+ yıldır güncellenmemiş eklentileri işaretler ancak bunları otomatik olarak kaldırmaz.
• Premium eklenti lisanslama bir tedarik zinciri riski oluşturur: nulled (korsan) premium eklentiler birincil kötü amaçlı yazılım dağıtım vektörüdür. Doğrulanmamış kaynaklardan asla eklenti yüklemeyin.
• Eklenti yükleme sırası önemlidir. Eklentilerin bağımlılıkları başlatılmadan önce yüklenmesinden kaynaklanan PHP önemli hataları, karmaşık ortamlarda yaygındır ve plugins_loaded kanca önceliklerinin dikkatli kullanımını gerektirir.

Operasyonel en iyi uygulama: Üretimi tam olarak yansıtan bir hazırlık ortamı bulundurun. Her eklenti güncellemesini üretime dağıtmadan önce hazırlık ortamında test edin. cPanel’li VPS‘te hazırlık ortamları, izole veritabanlarıyla alt alan adları olarak dakikalar içinde sağlanabilir.

6. SEO Mimarisi — WordPress’in Yerel Olarak Yaptıkları ve Eklentilerin Ekledikleri

WordPress anlamsal olarak doğru HTML5 biçimlendirmesi, temiz kalıcı bağlantı yapıları ve otomatik XML site haritaları (WordPress 5.5’ten itibaren) oluşturur. Ancak WordPress’i “kutudan çıktığı gibi SEO dostu” olarak nitelendirmek bazı açıklamalar gerektirmektedir.

Yerel SEO özellikleri:

• Yapılandırılabilir kalıcı bağlantı yapıları (varsayılan ?p=123‘den kaçının — /%postname%/ veya /%category%/%postname%/ kullanın)
• Belge başlığındaki rel="canonical" aracılığıyla otomatik kanonik etiketler

/wp-sitemap.xml adresinde yerleşik XML site haritası
Blok desenleri aracılığıyla şema biçimlendirme desteği (eklentiler olmadan sınırlı)

Yoast SEO ve Rank Math’in ekledikleri:

Gönderi/sayfa/taksonomi başına ayrıntılı meta başlık ve açıklama kontrolü
Gelişmiş şema grafiği (Article, BreadcrumbList, Organization, Product)
Yönlendirme yönetimi (301, 302, 410)
İçerik analizi ve okunabilirlik puanlaması
Sosyal grafik etiketleri (Open Graph, Twitter Cards)

Teknik SEO tuzağı: WordPress’in varsayılan davranışı, tarih arşivleri, yazar arşivleri, kategori/etiket sayfaları ve sayfalandırılmış arşivler aracılığıyla yinelenen içerik oluşturur. İnce arşiv sayfalarında noindex yapılandırmadan veya bunları kanonik etiketlerle birleştirmeden, büyük WordPress siteleri tarama bütçesini azaltan önemli miktarda yinelenen içerik biriktirir.
7. Duyarlı Tasarım ve Core Web Vitals
Modern WordPress temaları, medya sorguları ve akışkan ızgara sistemleri kullanan duyarlı CSS ile birlikte gelir. Ancak duyarlı tasarım ile Core Web Vitals uyumluluğu aynı şey değildir ve bunları birbirine karıştırmak yaygın bir hatadır.
WordPress için Core Web Vitals değerlendirmeleri:

En Büyük İçerikli Boyama (LCP): Genellikle hero görseli tarafından domine edilir. Ekranın üst kısmındaki görsellerde loading="eager" ve fetchpriority="high" kullanın. WordPress 6.3+ yerel LCP görsel algılama özelliği ekler.
Kümülatif Düzen Kayması (CLS): Açık width ve height özelliklerine sahip olmayan görseller, eş zamansız yüklenen web yazı tipleri ve ayrılmış alan olmayan reklam yuvaları tarafından oluşturulur. WordPress 5.5+, blok editöründeki görsellere otomatik olarak width ve height ekler.
Sonraki Boyamaya Etkileşim (INP): Mart 2024’te Core Web Vital olarak İlk Giriş Gecikmesinin yerini aldı. Sayfa oluşturuculardan ve üçüncü taraf komut dosyalarından gelen ağır JavaScript birincil suçludur.

Core Web Vitals’ı doğrudan etkileyen sunucu tarafı optimizasyonları:

php.ini içinde OPcache’i etkinleştirin (opcache.enable=1, opcache.memory_consumption=256)
Anonim kullanıcılara statik HTML sunmak için Nginx düzeyinde FastCGI önbelleğini yapılandırın
Statik varlıklar için kenar önbelleğe alma özelliğine sahip CDN kullanın

8. Çok Dilli WordPress — Teknik Mimari Seçimler
Çok dilli bir WordPress sitesi oluşturmak, URL yapısını, veritabanı tasarımını ve SEO stratejisini etkileyen temel bir mimari karar gerektirir.
Üç uygulama yaklaşımı:




Yaklaşım
Eklenti
URL Yapısı
Veritabanı Etkisi
SEO Çıkarımı




Alt dizin
WPML, Polylang
/fr/page/
Dil başına yinelenen gönderiler
URL başına ayrı hreflang


Alt alan adı
WPML, Polylang
fr.domain.com
Dil başına yinelenen gönderiler
Google tarafından ayrı siteler olarak değerlendirilir


Ayrı alan adı
WPML
domain.fr
Ayrı WP kurulumları veya paylaşımlı
Tam alan adı otoritesi ayrımı


Çeviri katmanı
Weglot
Herhangi biri
DB kopyalaması yok
Dinamik hreflang enjeksiyonu




hreflang uygulaması çok dilli SEO için vazgeçilmezdir. Eksik veya hatalı hreflang ek açıklamaları, Google’ın kullanıcılara yanlış dil sürümünü sunmasına neden olur; bu da yüksek hemen çıkma oranlarına ve bölgesel arama sonuçlarında sıralama baskısına yol açar.
WPML ve Polylang karşılaştırması: WPML daha kapsamlı özelliklere sahiptir ancak icl_translations tablosu aracılığıyla önemli veritabanı ek yükü ekler. Polylang daha hafiftir ve çoğu kullanım durumu için yeterlidir. Yüksek trafikli çok dilli siteler için çeviri katmanı yaklaşımı (Weglot), veritabanı kopyalamasını tamamen önler ancak üçüncü taraf bir SaaS’a bağımlılık getirir.
9. WordPress Güvenliği — Eklenti Kurulumunun Ötesinde Sertleştirme
WordPress güvenliği katmanlı bir disiplindir. Wordfence veya Sucuri yüklemek bir başlangıç noktasıdır, eksiksiz bir çözüm değil.
Eklenti tabanlı güvenliğin yerini alamayacağı sunucu düzeyinde sertleştirme önlemleri:

Nginx/Apache düzeyinde IP’ye göre wp-login.php erişimini kısıtlayın
Gerekli değilse XML-RPC’yi devre dışı bırakın (/xmlrpc.php kaba kuvvet amplifikasyon hedefidir)
Doğru dosya izinlerini ayarlayın: dosyalar için 644, dizinler için 755, wp-config.php için 600

wp-config.php‘yi web kökünün bir dizin üstüne taşıyın
HTTP güvenlik başlıklarını uygulayın: Content-Security-Policy, X-Frame-Options, Strict-Transport-Security

Bilinmesi gereken wp-config.php güvenlik sabitleri:

define('DISALLOW_FILE_EDIT', true);       // Disables theme/plugin editor in admin
define('DISALLOW_FILE_MODS', true);       // Prevents plugin/theme installation from admin
define('FORCE_SSL_ADMIN', true);          // Forces HTTPS for all admin sessions
define('WP_DEBUG', false);               // Never enable on production
define('WP_DEBUG_LOG', false);           // Prevents debug.log exposure

İki faktörlü kimlik doğrulama, tüm yönetici hesapları için kullanıcı düzeyinde yalnızca önerilmemeli, zorunlu tutulmalıdır. WP 2FA veya Wordfence 2FA modülü gibi eklentiler TOTP kimlik doğrulayıcı uygulamalarıyla entegre olur.

Veritabanı güvenliği: Kurulum sırasında varsayılan wp_ tablo önekini değiştirin. Belirsizlik yoluyla güvenlik birincil savunma olmasa da, varsayılan öneki hedef alan otomatik SQL enjeksiyon saldırılarının maliyetini artırır.

10. Blog Platformu Olarak WordPress — Gelişmiş Editoryal Özellikler

WordPress’in blog kökleri, amaca yönelik CMS platformlarının çoğunlukla yoksun olduğu editoryal yetenekler kazandırır.

Sıklıkla gözden kaçan gelişmiş blog özellikleri:

• Fark görünümlü revizyon geçmişi: Her gönderi kaydı bir revizyon oluşturur. Editördeki fark görünümü, revizyonlar arasındaki satır satır değişiklikleri göstererek editoryal hesap verebilirliği sağlar.
• Ortak yazarlık: Co-Authors Plus eklentisi, her biri için uygun şema biçimlendirmesiyle birden fazla yazarın tek bir gönderiye atfedilmesine olanak tanır.
• Editoryal iş akışı: Editorial Calendar ve PublishPress eklentileri, özel gönderi durumlarıyla (Taslak, İnceleme Bekliyor, Zamanlandı, Yayınlandı) Kanban tarzı editoryal ardışık düzenler ekler.
• Ölçekte yorum moderasyonu: Akismet’in API’si yorum spam’ini sunucu tarafında işler. Yüksek trafikli bloglar için 30-60 günden eski gönderilerde yorumları devre dışı bırakmak (Ayarlar > Tartışma), spam yükünü ve veritabanı yazımlarını önemli ölçüde azaltır.

11. Üyelik Siteleri — Erişim Kontrolü Mimarisi

WordPress üyelik siteleri, içerik erişim kontrolü, ödeme işleme ve kullanıcı veri güvenliği konusunda dikkatli bir düşünce gerektirir.

Üyelik işlevselliği için eklenti karşılaştırması:

Kritik mimari değerlendirme: İçeriği kapıya alan üyelik siteleri, yalnızca ön uç görünürlük geçişi değil, sunucu tarafı erişim kontrolü uygulamalıdır. İçeriği HTML kaynağında teslim ederken CSS veya JavaScript ile gizleyen bir eklenti içeriği korumaz — yalnızca bir koruma yanılsaması yaratır. Seçtiğiniz eklentinin içerik işlenmeden önce template_redirect veya the_content filtre düzeyinde erişim denetimleri gerçekleştirdiğini doğrulayın.

Abonelik faturalandırma ve PCI uyumluluğu: Üyelik siteniz yinelenen ödemeleri işliyorsa, ödeme ağ geçidinizin kart verilerini doğrudan işlediğinden emin olun (Stripe.js, PayPal Hosted Fields); böylece sunucunuz ham kart numaralarına hiç dokunmaz. Bu, WordPress örneğinizi PCI DSS kapsamı dışında tutar.

12. Öğrenme Yönetim Sistemleri — LMS Olarak WordPress

WordPress LMS eklentileri, özel SaaS LMS ürünleriyle rekabet edebilecek tam özellikli e-öğrenme platformlarına dönüşmüştür.

LearnDash ve LifterLMS — Teknik Karşılaştırma:

LMS dağıtımları için sunucu gereksinimleri: Video barındırma asla doğrudan WordPress tarafından yönetilmemelidir. Video dosyalarını wp-content/uploads içinde depolamak ve WordPress aracılığıyla sunmak büyük bant genişliği ve depolama maliyetleri yaratır. Özel bir video barındırma hizmeti (Vimeo, Bunny.net, Mux) kullanın ve blok editörü veya kısa kod aracılığıyla yerleştirin. Kurs varlıkları ve indirilebilir içerik için CDN entegrasyonu zorunludur.

13. Kullanıcı Rolü Yönetimi — Varsayılan Beş Rolün Ötesinde

WordPress beş varsayılan kullanıcı rolüyle birlikte gelir: Yönetici, Editör, Yazar, Katkıda Bulunan ve Abone. Her rol, edit_posts, publish_pages, manage_options gibi ayrıntılı izinler olan bir dizi yetenek ile eşleşir.

Rol sistemini genişletme:

add_role() fonksiyonu, keyfi yetenek kümeleriyle özel roller oluşturur
Bir WP_User veya WP_Role nesnesindeki add_cap() yöntemi bireysel yetenekler verir
User Role Editor gibi eklentiler, kod yazmadan yetenek yönetimi için bir GUI sağlar

Rol yanlış yapılandırmasının güvenlik etkisi: manage_options yeteneği tam yönetici erişimi verir. Bunu gerektirmeyen rollere asla atamayın. unfiltered_html yeteneği, kullanıcıların JavaScript dahil ham HTML göndermesine olanak tanır — bunu özellikle çok yazarlı sitelerde yalnızca yöneticilerle sınırlandırın.
Çoklu site rol mimarisi: Bir WordPress Çoklu Site ağında, Süper Yönetici rolü tüm site düzeyindeki yöneticilerin üzerinde bulunur ve ağ genelinde erişime sahiptir. Site yöneticileri, Süper Yönetici ağ ayarları aracılığıyla bu yeteneği açıkça vermediği sürece eklenti veya tema yükleyemez.
14. Forumlar ve Topluluk Özellikleri — bbPress ve BuddyPress Mimarisi
bbPress ve BuddyPress’in her ikisi de Automattic tarafından geliştirilmiştir ve WordPress’in kullanıcı sistemiyle yerel olarak entegre olur, ancak farklı amaçlara hizmet ederler.
bbPress, konuları ve yanıtları wp_posts içinde özel gönderi türleri (topic, reply) olarak depolayan hafif bir forum eklentisidir. Bu, tüm WordPress sorgulama, önbelleğe alma ve izin altyapısının yerel olarak uygulandığı anlamına gelir. Takas ölçeklenebilirliktir: milyonlarca gönderiye sahip forumlar, WordPress’in varsayılan olarak sağladığının ötesinde agresif nesne önbelleği ve veritabanı indeksleme gerektirir.
BuddyPress, sosyal ağ altyapısı ekler: kullanıcı profilleri, etkinlik akışları, arkadaş bağlantıları, özel mesajlaşma ve gruplar. Kendi veritabanı tablolarını (bp_activity, bp_messages, bp_friends vb.) tanıtır ve paylaşımlı altyapıda kaynak yoğun olabilir.
Yüksek trafikli topluluk siteleri için, WordPress tabanlı bir çözüm yerine özel bir forum platformunun (Discourse, Flarum) daha uygun olup olmadığını değerlendirin. Karar, WordPress içeriği ve kullanıcı hesaplarıyla sıkı entegrasyonun amaca yönelik forum yazılımının performans avantajlarından daha ağır basıp basmadığına bağlıdır.
15. İçerik Zamanlama ve Otomasyon — Üretimdeki WP-Cron Sınırlamaları
WordPress’in yerleşik zamanlama sistemi olan WP-Cron, gerçek zaman tabanlı bir programa göre değil, sayfa yüklemesinde çalışan sözde bir cron’dur. Bu durumun otomasyon güvenilirliği açısından önemli etkileri vardır.
WP-Cron sorunu:
WP-Cron, bir ziyaretçi sayfa yüklediğinde tetiklenir. Düşük trafikli sitelerde zamanlanmış gönderiler saatler geç yayınlanabilir. Yüksek trafikli sitelerde WP-Cron her sayfa yüklemesinde tetiklenebilir ve PHP-FPM çalışanlarını tüketen gereksiz arka plan süreçleri oluşturabilir.
Doğru üretim çözümü — WP-Cron’u devre dışı bırakın ve sistem cron’unu kullanın:
wp-config.php dosyasına aşağıdakini ekleyin:
define('DISABLE_WP_CRON', true);
Ardından sunucuya gerçek bir cron işi ekleyin:
*/5 * * * * wget -q -O - https://yourdomain.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
Veya WP-CLI kullanarak (tercih edilen):
*/5 * * * * /usr/local/bin/wp cron event run --due-now --path=/var/www/html/ --quiet
Bu, zamanlanmış gönderilerin zamanında yayınlanmasını, e-posta bildirimlerinin güvenilir şekilde gönderilmesini ve eklenti tarafından zamanlanan görevlerin (yedekleme işleri, dizin güncellemeleri, besleme getirmeleri) öngörülebilir aralıklarla çalışmasını sağlar.
16. Randevu Rezervasyon Sistemleri — Entegrasyon Derinliği Önemlidir
WordPress rezervasyon eklentileri, harici takvimler, ödeme işlemcileri ve bildirim sistemleriyle entegrasyon derinlikleri açısından önemli ölçüde farklılık gösterir.
Bookly ve Amelia — Özellik Karşılaştırması:




Özellik
Bookly
Amelia




Google Calendar senkronizasyonu
Evet
Evet


Outlook Calendar senkronizasyonu
Eklenti
Evet


Zoom entegrasyonu
Eklenti
Evet


SMS bildirimleri
Eklenti (Twilio)
Yerleşik (Twilio)


Birden fazla personel/konum
Eklenti
Yerleşik


WooCommerce ödemesi
Eklenti
Yerleşik


REST API
Sınırlı
Tam


Fiyatlandırma
Ücretsiz + ücretli eklentiler
Yıllık lisans




Üretim değerlendirmesi: SMS ve e-posta bildirimleri gönderen rezervasyon sistemleri, güvenilir sunucu tarafı posta teslimi gerektirir. WordPress’in varsayılan wp_mail() fonksiyonu PHP’nin mail() işlevini kullanır; bu da alıcı posta sunucuları tarafından sıklıkla engellenir veya spam olarak işaretlenir. WP Mail SMTP gibi bir eklenti aracılığıyla bir SMTP aktarıcısı (SendGrid, Postmark, Amazon SES) yapılandırın veya uygun SPF, DKIM ve DMARC kayıtlarına sahip özel bir E-posta Barındırma çözümü kullanın.
17. Üçüncü Taraf Entegrasyonlar — REST API, Webhook’lar ve Veri Ardışık Düzenleri
WordPress’in REST API’si (/wp-json/wp/v2/), onu modern entegrasyon mimarilerinde birinci sınıf bir katılımcı haline getirir. Yalnızca üçüncü taraf araçlara “bağlanan” bir CMS değil — veri kaynağı, webhook alıcısı ve otomasyon tetikleyicisi olarak işlev görebilir.
Üretimde kullanılan entegrasyon kalıpları:

Zapier/Make (Integromat) webhook’ları: Özel kod olmadan gönderi yayınlama, form gönderimi veya WooCommerce sipariş olaylarında iş akışlarını tetikleyin
CRM senkronizasyonu: Gravity Forms ve WPForms’un her ikisi de HubSpot, Salesforce ve ActiveCampaign ile yerel entegrasyonlar sunarak form gönderimlerini doğrudan CRM kayıtlarına iletir
Google Analytics 4: Google’ın yerel Site Kit eklentisi, manuel gtag.js uygulaması gerektirmeden sunucu tarafı GA4 yapılandırması sağlar
Başsız/API öncelikli: WordPress’i varsayılan REST API yerine GraphQL (WPGraphQL eklentisi) aracılığıyla veri kaynağı olarak kullanmak, ayrıştırılmış ön uçlar için daha verimli, sorguya özgü veri getirme sağlar

REST API entegrasyonları için kimlik doğrulama: Varsayılan WordPress REST API kısmen herkese açıktır (yayınlanan içeriğe okuma erişimi) ve yazma işlemleri için kimlik doğrulama gerektirir. Yönetici kimlik bilgilerini açığa çıkarmak yerine sunucudan sunucuya entegrasyonlar için Uygulama Şifreleri‘ni (WordPress 5.6’dan itibaren yerleşik) kullanın. Herkese açık API uç noktaları için, kötüye kullanımı önlemek amacıyla Nginx düzeyinde hız sınırlaması uygulayın.
WordPress Barındırma Mimarisi: Doğru Altyapıyı Seçmek
Yukarıda açıklanan özellikler farklı altyapı gereksinimleri içermektedir. Aşağıdaki matris, kullanım durumlarını uygun barındırma katmanlarıyla eşleştirir:




WordPress Kullanım Durumu
Minimum Barındırma Katmanı
Temel Gereksinimler




Kişisel blog, portföy
Paylaşımlı Web Barındırma
PHP 8.1+, MySQL 8.0


İş sitesi, WooCommerce (küçük)
VPS Hosting
2 vCPU, 4GB RAM, NVMe, Redis


Yüksek trafikli WooCommerce, LMS
VPS Hosting
4+ vCPU, 8GB+ RAM, nesne önbelleği


Kurumsal, yüksek kullanılabilirlik
Dedicated Sunucular
Tam donanım kontrolü, özel yığın


Yapay zeka destekli WordPress (görsel üretimi, ML)
GPU Hosting
CUDA desteği, yüksek VRAM




PHP sürümü, çoğu yöneticinin kabul ettiğinden daha önemlidir. PHP 8.2 üzerindeki WordPress, JIT derleme iyileştirmeleri ve azaltılmış bellek ek yükü nedeniyle PHP 7.4’e kıyasla ölçülebilir biçimde daha hızlıdır. Barındırma ortamınız hâlâ PHP 7.x’e varsayılan olarak ayarlıysa, PHP 8.2’ye yükseltmek mevcut en yüksek yatırım getirili performans optimizasyonudur.
WordPress’i Üretimde Dağıtmadan Önce Teknik Karar Kontrol Listesi
Herhangi bir WordPress sitesini başlatmadan önce bu kontrol listesini kullanın:

PHP sürümü: PHP 8.1 veya 8.2’nin etkin olduğunu onaylayın; PHP 7.x’ten kaçının
OPcache: opcache.enable=1‘yi doğrulayın ve opcache.memory_consumption en az 128MB olsun
Nesne önbelleği: Redis veya Memcached’i yükleyip yapılandırın; WP_CACHE sabiti aracılığıyla bağlanın
Veritabanı: innodb_buffer_pool_size‘yi kullanılabilir RAM’in %70’ine ayarlayın; yavaş sorgu günlüğünü etkinleştirin
Dosya izinleri: Dosyalar için 644, dizinler için 755, wp-config.php için 600

SSS

WordPress bir VPS gerektiriyor mu, yoksa paylaşımlı barındırmada çalışabilir mi?

WordPress, düşük trafikli siteler için paylaşımlı barındırmada çalışır; ancak WooCommerce, LMS, üyelik sistemi veya günlük ~500’den fazla ziyaretçiye sahip herhangi bir site, paylaşımlı altyapıda PHP bellek sınırları, yürütme zaman aşımları ve I/O kısıtlamasıyla karşılaşacaktır. Bir VPS, ayrılmış kaynaklar, PHP/MySQL ayarlaması için root erişimi ve Redis yükleme imkânı sağlar — bunların tümü üretim kalitesinde WordPress dağıtımları için fiilen zorunludur.

WordPress için PHP 7.4 ile PHP 8.2 arasındaki gerçek performans farkı nedir?

Kıyaslamalar, PHP 8.2’nin tipik WordPress iş yükleri için PHP 7.4’e kıyasla saniyede %20-40 daha fazla isteği işlediğini ve istek başına daha düşük bellek tüketimi sağladığını tutarlı biçimde göstermektedir. İyileşme JIT derlemesinden, geliştirilmiş tür işlemeden ve azaltılmış dahili ek yükten kaynaklanmaktadır. Bu sıfır maliyetli bir optimizasyondur — PHP sürümünü yükseltmek, iyi bakımlı eklentiler kullanan siteler için kod değişikliği gerektirmez.

Mağaza büyüdükçe WooCommerce’in WordPress performansını düşürmesini nasıl önlersiniz?

Birincil müdahaleler şunlardır: siparişleri wp_posts dışına taşımak için Yüksek Performanslı Sipariş Depolama’yı (HPOS) etkinleştirin; veritabanı gidiş-dönüşlerini azaltmak için Redis nesne önbelleğini uygulayın; geçici değerlerin, süresi dolmuş oturumların ve gönderi revizyonlarının düzenli temizliğini zamanlayın; ve sipariş hacmi günlük ~1.000 siparişi aştığında veritabanı sunucusunu web sunucusundan ayırın.

WordPress REST API üretim entegrasyonları için yeterince güvenli mi?

REST API, düzgün yapılandırıldığında güvenlidir. Hassas uç noktalara kimlik doğrulamasız erişimin engellendiğinden emin olun, sunucudan sunucuya kimlik doğrulama için Uygulama Şifreleri kullanın, web sunucusu düzeyinde hız sınırlaması uygulayın ve hangi eklentilerin özel REST uç noktaları açığa çıkardığını denetleyin — kötü yazılmış eklentiler bazen uygun yetenek denetimleri olmadan veri açığa çıkarır.

Bir WordPress sitesi için bbPress ile Discourse gibi özel bir forum platformu arasındaki fark nedir?

bbPress, tüm forum verilerini WordPress özel gönderi türleri olarak depolar; bu, WordPress kullanıcı hesaplarıyla sorunsuz SSO ve yerel tema entegrasyonu sağlar, ancak önemli önbelleğe alma altyapısı olmadan ~100.000 gönderinin ötesinde kötü ölçeklenir. Discourse, kendi veritabanına ve olgun gerçek zamanlı mimarisine sahip bağımsız bir uygulamadır, ancak ayrı bir sunucu ve WordPress ile özel bir SSO entegrasyonu gerektirir. İçerik entegrasyonunun önemli olduğu topluluklar için bbPress uygundur. Tartışmanın birincil ürün olduğu büyük, aktif forumlar için Discourse daha ölçeklenebilir bir seçimdir.