WP-Cron Nedir? Gerçek Sunucu Cron’una Geçiş Rehberi 2026

WP-Cron nedir? WP-Cron, WordPress’in yerleşik zamanlanmış görev sistemidir ve adında “cron” geçmesine rağmen gerçek bir sistem cron’u değildir. Yazı yayınlama zamanlaması, eklenti güncelleme kontrolleri, yedekleme görevleri ve e-posta kuyrukları gibi işler bu mekanizma üzerinden tetiklenir. Ancak WP-Cron’un çalışma şekli, düşük trafikli sitelerde görevlerin gecikmesine, yüksek trafikli sitelerde ise gereksiz sunucu yüküne yol açabilir. Bu rehberde WP-Cron’un nasıl çalıştığını, neden sorun çıkardığını ve gerçek sunucu cron’una nasıl güvenli biçimde geçileceğini adım adım anlatıyoruz.

WP-Cron Nedir, Neden Sorun Çıkarır?

WP-Cron, WordPress çekirdeğine gömülü bir “sahte cron” (pseudo-cron) sistemidir. Sunucu işletim sisteminin kendi cron servisinden tamamen bağımsız çalışır; bunun yerine wp-cron.php dosyası, belirli koşullar sağlandığında sitenize gelen normal sayfa ziyaretleri sırasında tetiklenir. Bir ziyaretçi herhangi bir sayfayı açtığında WordPress arka planda “zamanı gelmiş bir görev var mı?” diye kontrol eder ve varsa bu görevi o anda çalıştırmaya çalışır.

Bu tasarımın pratikte iki ayrı sorunu vardır:

Düşük Trafikli Sitelerde Gecikme Sorunu

Günde birkaç ziyaretçisi olan bir blog ya da kurumsal tanıtım sitesinde, WP-Cron’u tetikleyecek sayfa isteği uzun süre gelmeyebilir. Sonuç olarak gece yarısı yayınlanması planlanan bir yazı, ilk ziyaretçi siteye uğrayana kadar yayınlanmaz; zamanlanmış bir yedekleme eklentisi görevini saatlerce çalıştıramaz; e-posta kuyruğunda bekleyen bildirimler gönderilmez. Bu, “zamanlanmış” olmaktan çok “bir sonraki ziyarete bağlı” bir sisteme dönüşür.

Yüksek Trafikli Sitelerde Gereksiz Yük Sorunu

Yoğun trafikte WordPress üzerinden işlenen istekler cron kuyruğunu kontrol edebilir. Ancak spawn_cron(), paralel çalıştırmaları sınırlandırmak için doing_cron kilidi kullanır; her ziyaret aynı görevi yeniden çalıştırmaz. Tam sayfa önbelleğinden sunulan istekler de WordPress’e ulaşmayabilir. Sistem cron’una geçişin performans etkisi, trafik ve görevlerin maliyeti ölçülerek değerlendirilmelidir.

Özetle: WP-Cron nedir sorusunun cevabı aynı zamanda neden sorun çıkardığının da cevabıdır — çünkü tetiklenme mekanizması ziyaretçi trafiğine bağlıdır, sunucunun kendi saatine değil.

WP-Cron Gerçekte Nasıl Çalışır?

WordPress, veritabanındaki wp_options tablosunda cron adlı bir seçenek altında zamanlanmış görevlerin listesini tutar. Her görevin bir sonraki çalışma zamanı (timestamp) kayıtlıdır. Bir sayfa yüklendiğinde WordPress şu sırayı izler:

1. Sayfa isteği geldiğinde WordPress çekirdeği zamanlanmış görevler listesini kontrol eder.
2. Zamanı gelmiş (veya geçmiş) bir görev varsa, tarayıcıya yanıt döndürmeden önce veya paralel bir arka plan isteğiyle wp-cron.php dosyasını tetikler.
3. wp-cron.php ilgili görevi (örneğin yazı yayınlama, eklenti güncelleme kontrolü) çalıştırır ve görevi listeden işaretler.

Varsayılan tetikleme, WordPress’in işlediği bir HTTP isteğine bağlıdır. Çekirdek, zamanı gelmiş işler için genellikle bloklamayan bir geri çağrı isteği gönderir. Sistem cron’u ile PHP CLI veya WP-CLI kullanıldığında HTTP isteği gerekmez; zamanlanmış görev mekanizması kullanılmaya devam eder.

Gerçek Sunucu Cron’u Nedir ve Farkı Ne?

Gerçek sunucu cron’u (system cron / crontab), işletim sisteminin kendi zamanlayıcı servisidir ve sitenize hiç ziyaretçi gelmese bile, tanımlanan dakikalarda çalışır. Linux sunucularda bu, crontab -e komutuyla düzenlenen bir zamanlama tablosudur. WP-Cron’u devre dışı bırakıp bu görevi gerçek cron’a devrettiğinizde, zamanlanmış işler artık ziyaretçi trafiğinden bağımsız, öngörülebilir aralıklarla tetiklenir.

WP-Cron ve Gerçek Sunucu Cron’u Karşılaştırması

WP-Cron’u Devre Dışı Bırakmadan Önce Dikkat Edilmesi Gereken Nokta

Bu rehberin en kritik uyarısı burada: WP-Cron’u devre dışı bırakmadan önce mutlaka sunucu seviyesinde gerçek bir cron görevi kurulmuş ve çalıştığı doğrulanmış olmalıdır. Sırayı tersine çevirip önce WP-Cron’u kapatıp sonra sunucu cron’unu kurmayı “sonraya bırakmak”, zamanlanmış görevlerin sessizce çalışmayı durdurmasına neden olur. Bu durumda:

• İleri tarihli yayınlanacak yazılar yayınlanmayabilir ve “zamanlama kaçırıldı” durumunda kalabilir.
• Yedekleme eklentileri (UpdraftPlus, BackWPup gibi) zamanlanmış yedeklerini almaz.
• E-posta kuyruğuna alınan bildirimler ve form gönderimleri gönderilmeden bekler.
• Önbellek temizleme ve içerik senkronizasyon görevleri çalışmaz.

Bu hatalar genelde fark edilmeden haftalarca sürebilir, çünkü site görünürde normal çalışmaya devam eder. Bu yüzden geçiş sırası her zaman şu şekilde olmalıdır: önce gerçek cron’u kur ve test et, sonra WP-Cron’u devre dışı bırak.

Gerçek Sunucu Cron’una Geçiş: Adım Adım Kurulum

Önce sunucudaki PHP/WP-CLI yolu ve site kullanıcısı belirlenir. Ardından tek bir tetikleme yöntemi kurulur, zamanlayıcının gerçekten çalıştığı doğrulanır ve en son ziyaretçi kaynaklı otomatik tetikleme kapatılır.

1. PHP ve gerekirse WP-CLI sürümünü php -v ve wp --info ile kontrol edin; cron ortamındaki çalıştırılabilir dosyaların mutlak yollarını kullanın.
2. Aşağıdaki yöntemlerden birini seçerek sistem cron’unu kurun.
3. Görevin zamanlayıcı üzerinden çalışmasını ve uygulamadaki sonucunu doğrulayın.
4. Doğrulamadan sonra DISABLE_WP_CRON ayarını ekleyin.

1. Adım: Gerçek Cron Görevini Kurma (3 Yöntem)

Sunucunuzda crontab -e komutunu çalıştırarak veya hosting panelinizin “Cron Jobs” bölümünden aşağıdaki üç yöntemden birini ekleyebilirsiniz. Her üçü de 15 dakikada bir çalışacak şekilde ayarlanmıştır.

Yöntem A — wget ile URL tetikleme:

*/15 * * * * wget -q -O - https://siteadi.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Yöntem B — PHP CLI ile doğrudan çalıştırma:

*/15 * * * * php /path/to/wordpress/wp-cron.php >/dev/null 2>&1

Yöntem C — WP-CLI ile zamanı gelmiş olayları çalıştırma:

*/15 * * * * cd /path/to/wordpress && wp cron event run --due-now >/dev/null 2>&1

WP-CLI de PHP çalıştırır ve WordPress’i yükler; PHP sürecini ortadan kaldırmaz. --due-now zamanı gelmiş olayları çalıştırır ve HTTP geri çağrısına ihtiyaç duymaz. Görevi site dosyalarının sahibi olan kullanıcıyla çalıştırın. Örneklerdeki php, wp ve kurulum yollarını sunucunuzdaki mutlak yollarla değiştirin.

*/15 yalnızca bir örnektir: görev 15 dakikada bir kontrol edilir. Saat 09.01’de yayınlanması gereken bir yazı, sonraki tetikleme 09.15 ise en az 14 dakika gecikebilir. Aralığı ziyaretçi sayısına göre değil, en hassas görevin kabul edilebilir gecikmesine ve hosting sınırlarına göre seçin. Dakikalık iş isteyen bir eklenti için 15 dakika uygun olmayabilir.

Üç yöntem arasında seçim yaparken sunucunuzda hangi araçların kullanılabilir olduğu belirleyicidir. Yönetilen (managed) WordPress hostinglerinin çoğunda WP-CLI önceden kurulu gelir ve bu durumda Yöntem C açık ara en pratik seçenektir. Paylaşımlı hostinglerde WP-CLI bulunmayabilir; bu durumda Yöntem A (wget) genellikle panel üzerinden en az yapılandırma gerektiren seçenektir. Yöntem B (PHP CLI) ise sunucuda PHP komut satırı erişimi olan ama WP-CLI kurulmamış ortamlar için bir ara çözümdür.

Hosting Panelinden Cron Ekleme

Sunucunuza SSH erişiminiz yoksa, çoğu paylaşımlı hosting sağlayıcısı “Cron Jobs” adlı bir panel bölümü sunar. Örneğin Hostinger hPanel’de “Gelişmiş” menüsü altındaki “Cron Jobs” bölümünden; cPanel’de “Cron Jobs” simgesinden; Plesk’te “Zamanlanmış Görevler” bölümünden aynı crontab satırını (dakika, saat, gün, ay, haftanın günü ve komut alanlarını ayrı ayrı doldurarak) girebilirsiniz. Panel arayüzü komutu sizin yerinize crontab’a yazar, mantık aynıdır.

wget/curl Kısıtlı Ortamlar İçin Alternatif

Bazı paylaşımlı hosting ortamlarında güvenlik politikaları gereği wget veya curl komutlarının doğrudan çalıştırılması kısıtlanmış olabilir. Bu durumda hosting sağlayıcınızın sunduğu, yalnızca bir URL’yi belirli aralıklarla çağıran “URL tetikleyici” tipi cron seçeneğini kullanabilirsiniz. Bu seçenek genelde panel üzerinde “URL çağır” veya “Visit URL” gibi bir seçenek olarak sunulur ve arka planda yine wp-cron.php?doing_wp_cron adresine istek gönderir.

2. Adım: Zamanlayıcıyı ve Görev Sonucunu Doğrulama

Kurulumu tamamladıktan sonra bekleyen görevleri listelemek için:

wp cron event list

Liste, kayıtlı olayların adını ve sonraki çalışma zamanını gösterir; tek başına cron’un çalıştığını kanıtlamaz. Önce komutu site kullanıcısıyla elle çalıştırıp hataları kontrol edin. Sonra zamanlayıcının kendi yürütme kaydı veya web kökünün dışındaki günlük üzerinden çalıştığını doğrulayın. Test ortamında ileri tarihli bir deneme yazısının yayımlanması gibi uygulama sonucunu da kontrol edin. Tekrarlanan olayların bir sonraki tarihi ilerlemelidir.

3. Adım: wp-config.php ile WP-Cron’u Devre Dışı Bırakma

Gerçek cron kurulumunu tamamlayıp doğruladıktan sonra, wp-config.php dosyasına aşağıdaki satırı ekleyin (tercihen /* That's all, stop editing! */ satırından önce):

define('DISABLE_WP_CRON', true);

Bu satır, sayfa ziyaretlerinin artık wp-cron.php‘u tetiklemesini engeller. Zamanlanmış görevler veritabanında kayıtlı kalmaya devam eder; sadece tetikleme kaynağı değişir.

Multisite Kurulumlarda WP-Cron Optimizasyonu

WordPress multisite ağlarında kritik bir nokta vardır: gerçek cron görevi yalnızca ana alan adı için çalıştırılırsa, ağdaki diğer alt siteler kendi zamanlanmış görevlerini hiç çalıştıramaz. Her alt site, kendi wp_blogid‘sine bağlı ayrı bir cron kuyruğuna sahiptir; bu nedenle cron görevi her alt site için ayrı ayrı tetiklenmelidir.

Tek bir alt site için çalıştırmak isterseniz:

wp cron event run --due-now --url=https://siteadi.com

Ağdaki tüm alt siteler için döngüyle çalıştırmak isterseniz:

wp site list --field=url | xargs -I % wp cron event run --due-now --url=%

Bu multisite komutunu ayrı bir kabuk betiğine koyup cron’dan betiği çağırın. Komutu doğrudan crontab’a kopyalarsanız yüzde işaretleri özel anlam taşıdığı için kaçırılmaları gerekir. Site kullanıcısı, kurulum yolu ve komutların mutlak yolları betikte açıkça belirlenmelidir.

Alt site sayısı arttıkça bu döngü komutunun tamamlanma süresi de uzar, çünkü her alt site için ayrı bir WP-CLI çağrısı yapılır. Çok sayıda alt siteye sahip büyük ağlarda, cron aralığını alt site sayısına göre gözden geçirmek ve döngünün bir sonraki çalıştırmadan önce tamamlandığından emin olmak faydalıdır; aksi halde art arda gelen cron tetiklemeleri üst üste binebilir.

Sık Yapılan Hatalar ve Çözümleri

1. Hata: Cron Kurmadan Önce WP-Cron’u Kapatmak

En sık ve en riskli hatadır. DISABLE_WP_CRON satırı eklenir ancak sunucu tarafında henüz bir cron görevi kurulmamıştır. Sonuç: hiçbir zamanlanmış görev çalışmaz. Çözüm: Her zaman önce gerçek cron’u kurup wp cron event list ile doğrulayın, satırı ancak bundan sonra ekleyin.

2. Hata: Yanlış Dosya Yolu Vermek

PHP CLI veya WP-CLI komutlarında WordPress kurulumunun tam (mutlak) yolu yerine göreli bir yol ya da yanlış bir dizin verilmesi, cron görevinin sessizce başarısız olmasına neden olur. Çözüm: Sunucuda pwd komutuyla WordPress kök dizininin tam yolunu doğrulayın ve crontab satırına bu tam yolu yazın.

3. Hata: Multisite’ta Sadece Ana Siteyi Çalıştırmak

Yukarıda değinildiği gibi, ağ genelinde tek bir cron satırıyla sadece ana alan adını tetiklemek, alt sitelerin zamanlanmış görevlerinin birikmesine yol açar. Çözüm: wp site list çıktısını döngüye alan komutu kullanın.

4. Hata: Çok Sık veya Çok Seyrek Aralık Seçmek

Aralığı görevlerin kabul edilebilir gecikmesi belirler. Çok seyrek tetikleme zamanlanmış yayınları geciktirir; uzun süren görevlerde yeni çalışmanın öncekiyle çakışmaması için çalışma süresini ve kilitleme yöntemini değerlendirin.

5. Hata: Sunucuda wget/curl Kısıtlı Olduğunu Fark Etmemek

Bazı paylaşımlı hosting ortamlarında bu komutlar devre dışı bırakılmıştır; crontab satırı eklenmiş gibi görünse de görev hiç çalışmaz ve hata günlüğünde “command not found” benzeri bir iz kalabilir. Çözüm: Önce hosting panelinizin cron günlüğünü kontrol edin; kısıtlama varsa panelin sunduğu URL tetikleyici seçeneğine veya WP-CLI yöntemine geçin.

Cron Görevini İzleme ve Günlük Kontrolü

Gerçek sunucu cron’una geçtikten sonra işin bitmediğini unutmamak gerekir; görevin düzenli ve hatasız çalıştığını periyodik olarak kontrol etmek, kurulumun kalıcı olarak güvenilir kalmasını sağlar.

Cron Çıktısını Bir Dosyaya Yönlendirme

Yukarıdaki örneklerde >/dev/null 2>&1 ifadesiyle cron çıktısı yok sayılmıştır. Kurulumun ilk haftalarında, olası hataları görebilmek için çıktıyı bir günlük dosyasına yönlendirmek daha güvenlidir:

*/15 * * * * cd /path/to/wordpress && wp cron event run --due-now >> /path/outside-webroot/wp-cron-log.txt 2>&1

Günlük dizini webden erişilemeyen bir konumda bulunmalı ve yalnızca ilgili kullanıcılarca okunabilmelidir. Gerçek dizin yolunu oluşturup yazma yetkisini kontrol edin; örnekteki yolu aynen kopyalamayın. Hataları izleyin ve dosyanın sınırsız büyümemesi için günlük döndürme uygulayın.

Hosting Panelinin Kendi Cron Günlüğünü Kullanma

Günlük veya e-posta çıktısı özellikleri panele ve hosting paketine göre değişir. Sağlayıcınızın belgelediği yürütme kaydını kullanın; panel yalnızca görev tanımını gösteriyorsa bunun çalıştırma kanıtı olmadığını unutmayın.

wp-cron.php Dosyasına Doğrudan Erişimi Sınırlama

Gerçek sunucu cron’una geçtikten sonra, wp-cron.php dosyasının dışarıdan tarayıcıyla doğrudan çağrılmasına artık ihtiyaç kalmaz; tetikleme işini sunucu üzerindeki zamanlanmış görev yapar. Bu nedenle bazı yöneticiler ek bir önlem olarak dosyaya dışarıdan erişimi sınırlamayı tercih eder. Bu isteğe bağlı bir sıkılaştırma adımıdır ve sunucu yapılandırmanıza (Apache/Nginx) göre farklılık gösterir; yanlış yapılandırılırsa cron görevinizin kendisi de (özellikle wget/URL tabanlı yöntemi kullanıyorsanız) erişimi engellenebileceğinden, bu adımı yalnızca WP-CLI veya PHP CLI tabanlı bir yöntem kullanıyorsanız ve değişikliği test ortamında doğruladıktan sonra uygulamanız önerilir.

WP-Cron Optimizasyonu Yaparken Performansı da Göz Önünde Bulundurun

Gerçek cron’a geçiş, WP-Cron’un sayfa yüklemesi üzerindeki gereksiz yükünü ortadan kaldırır, ancak genel site hızı için tek başına yeterli değildir. Sunucu seviyesinde önbellekleme, veritabanı sorgu optimizasyonu ve statik dosya sıkıştırması gibi önlemlerle birlikte uygulandığında etkisi daha belirgin hale gelir. Bu konuda daha kapsamlı bir yaklaşım için WordPress önbellekleme rehberine göz atabilirsiniz.

Sık Sorulan Sorular

WP-Cron nedir ve gerçek cron’dan farkı nedir?

WP-Cron, WordPress’in sayfa ziyaretlerine bağlı olarak çalışan dahili zamanlama sistemidir; gerçek sunucu cron’u ise işletim sisteminin trafikten bağımsız, sabit aralıklarla çalışan zamanlayıcısıdır.

WP-Cron’u devre dışı bırakmak site için riskli mi?

Otomatik tetiklemeyi yedek bir zamanlayıcı kurmadan kapatmak işleri geciktirebilir. Doğrulanmış sistem cron’u bu bağımlılığı azaltır; görev hataları ve zamanlayıcı kesintileri için izleme yine gerekir.

Hangi cron aralığını seçmeliyim?

En hassas görevin izin verdiği gecikmeyi esas alın. 15 dakika bir kurulum örneğidir; her site için varsayılan öneri değildir.

WP-CLI kurulu değilse ne yapmalıyım?

Hosting izin veriyorsa wget ile HTTPS çağrısı veya PHP CLI kullanılabilir. Yöntemlerin kullanılabilirliğini ve gerçek çalışma sonucunu doğrulayın; ölçüm olmadan verimlilik sıralaması yapmayın.

Multisite ağımda her alt site için ayrı cron mu kurmalıyım?

Her alt sitenin kuyruğu işlenmelidir. Ayrı cron tanımları veya tüm siteleri dolaşan bir betik kullanılabilir; çalıştırma süresini ve başarısız alt siteleri izleyin.

Gerçek cron’a geçtikten sonra WP-Cron tamamen mi devre dışı kalır?

Hayır. DISABLE_WP_CRON, ziyaretçi kaynaklı otomatik tetiklemeyi kapatır; olay kaydetme ve WP-CLI/PHP ile elle çalıştırma sürer. Gerçek cron’un düzenli çalışmasını izleyin.

Sonuç: Kime, Hangi Durumda Uygun?

WP-Cron nedir sorusuna verdiğimiz yanıt ve yukarıdaki karşılaştırma, hangi sitenin hangi yaklaşımı tercih etmesi gerektiğini netleştiriyor. Çok düşük trafikli, kişisel blog niteliğindeki siteler için varsayılan WP-Cron genelde yeterlidir; gecikmeler nadiren fark edilir. Ancak orta ve yüksek trafikli siteler, e-ticaret mağazaları, zamanlanmış yayın akışı yoğun haber siteleri ve özellikle multisite ağları için gerçek sunucu cron’una geçiş, hem güvenilirlik hem de performans açısından daha tutarlı bir çözüm sunar. Geçiş yaparken izlenecek tek kural basittir: önce cron’u kur ve doğrula, sonra WP-Cron’u kapat.

Teknik Kaynaklar

• WordPress: sistem zamanlayıcısına geçiş
• WordPress: spawn_cron ve çalışma kilidi
• WP-CLI: cron event run