1. Webhook Nedir?
Webhook, bir sistemde bir olay gerçekleştiğinde (ör. “publish”) başka bir sisteme HTTP üzerinden “haber vermek”tir. Klasik entegrasyonlar “polling” yapar: site gidip CMS’i sürekli sorar. Webhook ise tersine çalışır: CMS olayı olduğunda sizi çağırır. Sonuç; daha düşük gecikme, daha az manuel iş ve daha net operasyon. Bu yaklaşım, web ve yazılım hizmetlerinde CMS event driven akış kurarken CMS’i pasif panelden aktif tetikleyiciye dönüştürür.
CMS webhook nedir, ne işe yarar?
Kısa cevap: CMS’te publish/update/delete gibi olaylar olduğunda, belirlediğiniz endpoint’e otomatik istek atarak revalidation, bildirim veya entegrasyon tetikleyen mekanizmadır.
Webhook’ların en doğru kullanımı, “tek bir devasa akış” değil; küçük ve güvenli tetiklerdir:
- •Yayınlandı → revalidate + Slack mesajı
- •Silindi → ilgili sayfayı kaldır + indeks güncelle
- •Kritik içerik güncellendi → partner sisteme uyarı
Ne yapmalıyım?
- • Olayları listele: publish/update/delete (draft dahil mi?)
- • Her olay için hedef aksiyon tanımla (revalidate/bildirim/CRM).
- • Endpoint güvenliğini baştan planla (secret + rate limit).
- • Log/izleme ekle (başarılı/başarısız).
- • Önce küçük bir akışla başla (publish→revalidate).
2. CMS’te Publish/Update/Delete Olaylarını Dinlemek
En büyük hata, “update” ile “publish”i karıştırmaktır. Birçok CMS’te draft kaydı da update sayılır; o yüzden “update” event’ini doğrudan prod tetiklemek risklidir. Bu bölümde hangi olayın ne anlama geldiğini netleştiriyoruz.
Bu yüzden publish trigger otomasyonu mantığı, draft, preview, staging ve prod ayrımını webhook seviyesinde netleştirmeden sağlıklı çalışmaz.
Event seçiminde 3 kritik kural
- Publish: Prod’a yansıyacak aksiyonlar (revalidation, Slack)
- Update: Sadece “published entry updated” filtreli kullan (Varsayım: CMS destekliyorsa)
- Delete/Unpublish: 404/redirect, indeks güncelleme ve cache purge
Payload standardı (minimum)
Webhook payload’ında şu bilgiler yoksa sonradan acı çekersiniz:
- •event_type (publish/update/delete)
- •content_type (blog, room, campaign, document)
- •entity_id
- •slug/path
- •locale (çok dilli ise)
- •timestamp
- •signature/secret doğrulama bilgisi
Ne yapmalıyım?
- • Draft olaylarını prod tetiklerinden ayır (preview/staging’e yönlendir).
- • “Published update” filtreleri ile risk azalt.
- • Delete/unpublish için redirect/404 planı yaz.
- • Payload standardını dokümante et.
- • Hatalı payload’ı “reject” eden validasyon ekle.
3. Static Rebuild/ISR Revalidation Tetiklemek
Next.js tarafında en sık hedef: içerik yayınlanınca sayfanın hızlı güncellenmesi. ISR revalidation; “tüm siteyi build et” yerine ilgili sayfaları yenilemeyi sağlar. Bu da hem hız hem maliyet avantajı demektir.
Yeni içerik yayınlandığında Next.js’i nasıl tetiklerim?
Kısa cevap: CMS’ten webhook ile güvenli bir endpoint’e istek gönderin; endpoint doğrulama sonrası ilgili path’ler için revalidate çağrısı yapar. Burada ISR revalidation webhook yaklaşımı, cache temizleme ve frontend güncelliğini aynı performans stratejisinin parçası olarak ele alır.
SSG vs ISR vs full rebuild (kısa karar çerçevesi)
- •Full rebuild: büyük değişiklikler veya geniş etki (nadir)
- •ISR revalidation: içerik sayfası güncellemeleri (çoğu senaryo)
- •Parçalı güncelleme: fiyat/widget gibi dinamik bileşenler (ayrı katman)
Ne yapmalıyım?
- • Revalidate endpoint tasarla (tek iş: doğrula + revalidate).
- • Path üretimini payload’dan yap (blog slug / oda slug / kampanya).
- • Full rebuild’i sadece istisnaya bırak.
- • Publish→live SLA belirle ve ölç.
- • Hata tekrarında retry/backoff kuralı koy.
4. Dış Sistemlere Bildirim (CRM, Slack, Search Index vb.)
Webhook’ların gücü, yalnız revalidation değil; ekip ve sistem senkronudur. Yayınlanan içeriğin CRM kampanyasına bağlanması, Slack’te ekip bilgilendirmesi, indeksin güncellenmesi gibi adımlar; “yayın sonrası unutulan işleri” otomatikleştirir.
Slack/Teams bildirimleri (örnek)
- •Blog yayınlandı → #content kanalına link + etiket + owner
- •Kritik sayfa güncellendi (oda/kampanya) → #ops kanalına uyarı
- •Delete/unpublish → #seo kanalına 404/redirect hatırlatması
CRM tetikleri (B2B whitepaper örneği)
İçerik yayını yalnız görünürlük değil, lead akışı da başlatıyorsa webhook ile CRM otomasyonu tarafında kampanya, nurturing ve form yolculuğu sinyallerinin birlikte tasarlanması gerekir.
- •Whitepaper yayınlandı → CRM’de kampanya aktif et, nurture başlat
- •Form sayfası güncellendi → dönüşüm takibi notu / Tag Manager kontrol checklist’i (Internal Link Targets ile uyum)
Bu noktada CMS event ve dönüşüm takibi yapısı; publish sonrası GTM, conversion tag ve event tracking kontrollerini operasyonel otomasyon zincirine dahil eder.
Arama indeksi / site haritası güncellemesi
- •Yeni içerik yayınlandı → sitemap ping / index update tetiklenir (Varsayım: kullandığınız altyapıya göre)
| Olay | Tetiklenen aksiyon | Hedef sistem | Operasyon notu |
|---|---|---|---|
| publish | İlgili path için ISR revalidation | Next.js | Payload içindeki slug/path ve locale ile hedefli çalışır |
| publish | İçerik yayına alındı bildirimi | Slack/Teams | #content kanalına link + owner + içerik tipi gönderilir |
| update | Kritik sayfa güncellendi uyarısı | Slack/Teams | Sadece published update filtreli kullanılmalıdır |
| delete/unpublish | 404/redirect kontrol hatırlatması | SEO/ops kanalı | İndeks ve yönlendirme aksiyonu unutulmaz |
| publish | Kampanya veya nurturing tetik sinyali | CRM | Whitepaper/demo gibi yüksek niyet içeriklerde kullanılır |
Ne yapmalıyım?
- • Bildirimleri kanala göre segmentle (content/ops/seo).
- • CRM tetiklerini “yüksek niyet” içeriklere bağla (whitepaper/demo).
- • Search index/sitemap güncellemelerini otomatikleştir.
- • Bildirim payload’ını standartlaştır (title, url, type, owner).
- • Gürültüyü azalt: sadece publish ve kritik update’ler.
5. Otel ve B2B İçin Otomasyon Örnekleri
Bu bölüm, “neden yapalım?” sorusunu sahaya indirir: otelde hız ve tutarlılık; B2B’de pipeline ve içerik lansmanı. Aynı zamanda CMS yayını sonrası içerik dağıtım planı ile sosyal medya ve kampanya takviminin de içerik yayınını takip edecek şekilde kurgulanabileceğini gösterir.
Otel senaryosu 1 — kampanya yayını
- •CMS kampanya publish → Next.js revalidate (landing)
- •Ops Slack → “kampanya canlı” bildirimi
- •(Varsayım) fiyat bileşeninde cache purge/revalidate → eski fiyat riski azalır
Otel senaryosu 2 — oda içeriği güncellemesi
- •Oda açıklaması/görsel update → oda sayfası revalidate
- •SEO ekibine bildirim → snippet/metadata kontrol
- •(Partner) PMS/Channel Manager’a içerik değil, sadece uyarı/etiket akışı (çakışma yaratmadan)
B2B senaryosu — doküman/whitepaper yayını
- •Whitepaper publish → CRM kampanya tetik + nurturing
- •Slack → satış ekibine “yeni asset” bildirimi
- •Landing revalidate + dönüşüm takibi kontrol notu (Tag Manager süreçleriyle uyum)
Ne yapmalıyım?
- • Otelde kampanya/oda sayfalarını “kritik” ilan et; hedefli revalidate kur.
- • B2B’de asset yayınlarını CRM automation’a bağla.
- • Delete/unpublish için redirect/SEO aksiyonunu otomatikleştir.
- • Her senaryoyu staging’de test et; prod’da deneme yapma.
- • Otomasyonları yılda en az 1 kez (365) gözden geçir.
6. Güvenlik ve Operasyonel Dayanıklılık (Teknik Not)
Webhook endpoint’leri, dış dünyaya açık “tetik kapısı”dır; korunmazsa spam, brute-force veya yanlış tetiklerle sisteminizi bozabilir. Bu yüzden kimlik doğrulama, rate limit ve loglama şarttır. Bu yaklaşımın /tr/yazilim/sunucu-guvenlik içeriğiyle uyumlu şekilde ele alınması gerekir.
Webhook endpoint’ini koruyan minimum paket
- •Secret signature doğrulama (HMAC vb.)
- •IP allowlist (mümkünse)
- •Rate limit (burst kontrolü)
- •Idempotency (aynı event iki kez gelirse güvenli)
- •Log + alert (başarısız tetikler, 401/403/500)
Webhook güvenliği hakkında neler sorulmalı?
Kısa cevap: Secret doğrulama, rate limit, IP kısıtı, loglama ve tekrar denemelere karşı idempotency uygulanmalıdır.
Ne yapmalıyım?
- • Secret doğrulamayı zorunlu yap; geçmeyeni reddet.
- • Rate limit + idempotency ile spam’i engelle.
- • Logları merkezi topla; hata alarmı kur.
- • Endpoint’i staging/prod ayrı yönet.
- • Güvenlik notlarını /tr/yazilim/sunucu-guvenlik ile hizala.
7. Rakip Açığını Kapat: “Event-Driven”i Üretim Kalitesine Taşı
TR’de CMS entegrasyonları çoğu zaman “çek veriyi göster” seviyesinde; webhook tabanlı event-driven otomasyon rehberleri az. Fark yaratan yaklaşım; webhook’u sadece “tetik” değil, gözlemlenebilir ve güvenli bir release mekanizması olarak ele almaktır: doğru event seçimi, doğrulama, log, retry ve idempotency. Bu kalite katmanı eklendiğinde; manuel build/bildirim/eşitleme işleri büyük oranda azalır ve ekip içerik/stratejiye daha fazla odaklanır.
8. CMS Publish Webhook & ISR/CRM/Slack Otomasyon Planlama Şablonunu İndir — Yazılım / Webhooks
CMS Publish Webhook & ISR/CRM/Slack Otomasyon Planlama Şablonunu İndir — Yazılım / Webhooks (v1.0)
Bu şablon; CMS’teki publish/update/delete event’lerini webhook ile dinleyip Next.js revalidation, Slack bildirimleri ve CRM tetiklerini güvenli biçimde planlamayı amaçlar. Event seçimi, payload sözleşmesi, endpoint güvenliği ve log/alert katmanını tek dokümanda toplayarak manuel işleri azaltır.
Kim Kullanır?
Teknik lider, ajans teknik ekibi, içerik operasyon yöneticisi.
Nasıl Kullanılır?
- Event türlerini ve hangi içerik tiplerini tetikleyeceğini seçin.
- Payload ve güvenlik (secret/rate limit/ip) sözleşmesini doldurun.
- Revalidation path’leri, Slack/CRM aksiyonları ve log/alert kurallarını planlayın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Event Envanteri
- ▢ ✅ İçerik tipleri: blog / room / campaign / document / service (seç: ____)
- ▢ ✅ Payload Sözleşmesi:
- ▢ ✅ Hedef Aksiyonlar:
- ▢ ✅ Revalidation Planı:
- ▢ ✅ Güvenlik Katmanı:
- ▢ ✅ Loglama ve Operasyon: Log alanları:
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
9. Sonuç: CMS, ekosistemin tetikleyicisi olduğunda hız ve tutarlılık artar
Webhook’lar; içerik değişikliğini tek bir panel olayından çıkarıp, Next.js revalidation, CRM tetikleri ve ekip bildirimleri gibi çoklu sistem aksiyonlarına dönüştürür. Doğru kurulduğunda publish→live süresi kısalır, manuel iş azalır ve içerik tutarlılığı artar. Güvenlik ve loglama ile desteklendiğinde ise bu otomasyonlar üretim kalitesini yükseltir. Bu etkinin operasyonel sonucunu webhook otomasyonlarının performans etkisi ile izleyebilir; uygulama tarafında da otomasyon uyumlu CMS entegrasyonu desteği ve CMS entegrasyonu hakkında sık sorulan sorular üzerinden karar sürecini netleştirebilirsiniz.
Bir Sonraki Adım
Publish/update/delete tetiklerini güvenli endpoint’lerle standardize edip revalidation ve bildirim süreçlerini otomatikleştirin.
Sık Sorulan Sorular
CMS webhook nedir, ne işe yarar?▾
Yeni içerik yayınlandığında Next.js’i nasıl tetiklerim?▾
CMS’te yapılan değişiklikleri CRM/Slack gibi sistemlere nasıl iletirim?▾
Otel ve B2B için webhook tabanlı otomasyon örnekleri neler?▾
Webhook endpoint’ini nasıl güvenli hale getiririm?▾
Update event’i neden riskli olabilir?▾
İlgili İçerikler