n8n ile WordPress REST API otomatik içerik yayınlama akışı

n8n ile WordPress REST API otomatik içerik yayınlama, bir içerik işini manuel kopyala-yapıştır yükünden çıkarıp WordPress’e kontrollü biçimde aktarmanın en pratik yollarından biridir. Bu yapı özellikle düzenli içerik üreten, aynı alanları tekrar tekrar dolduran ve taslak-yayın ayrımını otomatikleştirmek isteyen ekiplerde işe yarar. Yine de akışın güvenli olması için ilk tercih doğrudan yayın değil, önce taslak ve doğrulama olmalıdır.

Buradaki kritik nokta, n8n’i içerik üreticisi gibi değil, yayın taşıyıcısı gibi kurmaktır. Başlık, içerik, slug, kategori ve durum alanları net değilse akış hızlı çalışır ama hatayı da hızlı yayar. O yüzden doğru kurulum, yalnızca bir HTTP isteği atmak değil, o isteğin öncesine kontrol ve sonrasına doğrulama eklemektir.

n8n ile WordPress REST API otomatik içerik yayınlama

WordPress tarafında gönderi oluşturmak için çoğu kurulumda REST API’nin gönderi uç noktası kullanılır. n8n tarafında ise bu iş için genellikle bir tetikleyici, alanları düzenleyen bir hazırlık düğümü ve WordPress’e istek atan bir HTTP Request düğümü yeterlidir. Akışın basit görünmesi sizi yanıltmasın; asıl kalite farkı, hangi alanın zorunlu olduğunu ve hangi noktada yayın kararının verileceğini baştan belirlemenizden gelir.

WordPress tarafında güvenli yetkilendirme

Yönetici parolasını doğrudan akışa yazmak yerine uygulama parolası kullanmak daha temiz bir yaklaşımdır. Bu, n8n’de saklanan kimliğin sadece API erişimi için kullanılmasını sağlar ve gerektiğinde erişimi iptal etmeyi kolaylaştırır. Site ek güvenlik eklentileri, WAF ya da zorunlu çok faktörlü giriş kullanıyorsa ilk testte 401 ve 403 yanıtlarını özellikle kontrol edin; bunlar çoğu zaman endpoint’ten değil, yetkilendirme katmanından gelir.

Gönderi oluştururken alanların yapısı önemlidir. Başlık ve içerik çoğu kurulumda yeterli görünse de kategori ve etiket ekleyecekseniz sayısal kimlikleri doğru göndermeniz gerekir. Slug alanı elle belirlenebilir; ancak WordPress aynı slug daha önce kullanılmışsa kendi iç kuralına göre değişiklik yapabilir. Bu yüzden sonuçta oluşan kayıtla, gönderdiğiniz ham veriyi karşılaştırmak iyi bir alışkanlıktır.

n8n HTTP Request düğümünde pratik başlangıç

İlk kurulumda isteği doğrudan yayınlamak yerine draft ile başlatın. Böylece WordPress tarafında içerik görünür olur ama kamuya açılmaz. Test geçince aynı gövdeyi kullanıp yalnızca durum alanını publish yapabilirsiniz.

{ "title": "Yeni içerik başlığı", "content": "<p>İçerik burada yer alır.</p>", "status": "draft", "slug": "yeni-icerik-basligi", "excerpt": "Kısa açıklama" }

Burada en güvenli başlangıç, içeriği önce taslak olarak yaratmak ve WordPress yönetiminde açarak biçimlendirme, başlık ve bağlantıları gözle kontrol etmektir. Eğer akışın amacı doğrudan yayınsa bile, ilk testleri canlı yayına kapalı bir ortamda yapmak ileride geri dönmesi zor hataları azaltır.

Doğrulama: başarılı kabul etmek için neye bakmalı?

Başarılı bir istekten sonra oluşturulan kaydın kimliği, bağlantısı ve durumu döner. Birçok kurulumda bu işlem oluşturma yanıtı olarak görünür; asıl önemli olan, yanıtın boş olmaması ve WordPress’te aynı içeriğin beklenen durumda görünmesidir. n8n içinde ikinci bir kontrol düğümüyle dönen id alanını okuyup ardından bir GET isteğiyle aynı kaydı tekrar çekmek sağlam bir testtir.

• WordPress yönetiminde taslak ya da yayın kaydı görünmeli.
• Yanıtta beklediğiniz status alanı dönmeli.
• Slug, başlık ve içerik alanları beklenen biçimde kaydolmalı.
• HTML içeriği kullanıyorsanız etiketlerin WordPress tarafından kırpılmadığı doğrulanmalı.

Sık hata ve sınırlar

En yaygın hata, yetkilendirme sorununu içerik hatası sanmaktır. 401 ve 403 genellikle giriş bilgisinden, güvenlik eklentisinden veya API erişim kuralından kaynaklanır. 400 hatası ise çoğu zaman bozuk JSON, yanlış kategori kimliği ya da WordPress’in kabul etmediği bir alan yüzünden çıkar. Eğer akış dış sistemlerden içerik topluyorsa, metin temizleme adımını atlamayın; kötü biçimlenmiş HTML yayın kalitesini düşürür.

Bu yapı, editoryal onay isteyen sitelerde doğrudan yayın için her zaman uygun değildir. Önce taslak üretmek, ikinci bir gözden geçirme düğümü eklemek ve sadece onaydan sonra publish adımına geçmek çoğu ekip için daha dengeli bir düzendir. İçerik miktarı artınca hız kazanırsınız; ama kontrol katmanı yoksa hız, hata çarpanı haline gelir.

Canlıya geçmeden önce son kontrol

1. İlk denemeyi draft ile yapın.
2. WordPress’te API kullanıcısının yalnız gerekli yetkilere sahip olduğunu doğrulayın.
3. Slug, kategori ve etiket eşleşmelerini test edin.
4. Başarısız isteklerde akışı durduran bir kontrol ekleyin.
5. Yayın adımını ayrı node olarak tutup sonradan açılabilir halde bırakın.

Hız sizin için öncelikse tek akışta publish çalıştırabilirsiniz; denetim, onay ve uyumluluk önemliyse taslak + manuel onay yolu daha doğru olur. Kararı belirleyen şey, içerik üretim hızınızdan çok yayın hatasının size ne kadar pahalıya mal olacağıdır.