WordPress'ten Next.js'e: dokuz site taşıdıktan sonra öğrendiklerim

Son aylarda sekiz işletme sitesini ve sonunda kendi sitemi WordPress'ten Next.js'e taşıdım. Çekici firmalarından otomatik kapı servislerine, bir külliyeden eğitim şirketine kadar. Her birinde benzer sorunlarla karşılaştım; bu yazı o tekrar eden derslerin özeti.

1. Neden taşıyoruz?

Çoğu zaman sebep performans değil, bakım. İki sitede WordPress, ücretli tema ve yirmiden fazla eklentiyle 256 MB PHP belleğinde bile her gün çöküyordu. Yeni sürümler tek bir Node.js süreciyle boşta 70–100 MB civarında çalışıyor. Bunun yanında eklenti güncellemeleri, spam yorumlar ve işletme sahibinin "panel çok karmaşık" şikâyeti var.

2. İçerik birebir: metni makine karşılaştırsın

"Hiçbir şey kaybolmadı" demek yetmez, kanıtlamak gerekir. Her taşımada eski sitedeki görünen metinleri parçalara ayırıp yeni siteyle karşılaştıran bir betik yazıyorum. Bir sitede sonuç şuydu: 1.231 metin parçasının 1.203'ü birebir aynı, 28'i gerekçesi yazılı düzeltme, kayıp sıfır. Bu raporu işletme sahibine de veriyorum.

3. Adresler kutsaldır

Arama motorundaki sıralama, eski adreslerin üzerinde durur. WordPress adresleri "/" ile bittiği için Next.js'te trailingSlash açık kalmalı. Değişen her adres kalıcı (301/308) yönlendirmeyle yenisine bağlanmalı. Bir sitede 349 eski adresi yeni sayfalara bağladım ve yayından sonra her birini canlıda tek tek denetledim.

4. Statik ama güncel

Sayfalar derleme anında veritabanından hazır HTML'e dönüşüyor; panelden yapılan değişiklik yalnızca ilgili sayfaları yeniden üretiyor. Buradaki tuzak şu: yeni bir sürümü yayınlarken yerel veritabanıyla derlerseniz, işletme sahibinin panelde yaptığı değişiklikleri sessizce geri alırsınız. Bu yüzden yayın betiği önce canlı veritabanının bir kopyasını indirip derlemeyi onunla yapıyor.

5. Plesk'te Node.js: belge kökünü ayırın

• Uygulama kökü ile belge kökü aynı olmasın. Uygulama /httpdocs'ta, web'e açık kök /httpdocs/public'te durmalı. Aksi hâlde sunucu dosyalarınız web'den indirilebilir hâle gelebilir.
• Veritabanını web kökünün dışında tutun. Uygulama veri klasörünü yukarı doğru arayarak bulsun; derleme paketine hiçbir zaman veritabanı ya da gizli anahtar girmesin — paketleme betiği bunu denetleyip yayını durdursun.
• Eski .htaccess'i unutmayın. Belge kökü değişse bile Apache üst klasördeki WordPress kurallarını okuyabiliyor; bir sitede CSS ve JavaScript dosyalarını 500 hatasına düşürdü.
• FTP'yi doğrulanmış TLS ile kullanın. Sertifika adı uyuşmadığında sessizce düz FTP'ye düşen bir betik, parolanızı açık metin gönderir.

6. Windows'ta derleyip Linux'ta çalıştırmak

Görsel optimizasyonu yapan sharp kütüphanesi işletim sistemine özgü ikililerle gelir. Windows'ta derlenen pakete Linux ikilileri eklenmezse görseller sunucuda hiç küçültülmeden gönderilir — ve kimse fark etmez. Paketleme betiğim sürümleri karşılaştırıp uyuşmazlıkta derlemeyi durduruyor.

7. Spam: reddetmeyin, işaretleyin

Görünmez reCAPTCHA v3 ziyaretçiye resim seçtirmez, bir güven puanı üretir. Ama alan adını anahtara eklemeyi unutursanız Google her jetonu reddeder ve bütün gerçek mesajlar "şüpheli" görünür; yeni bir sitede ilk iş canlı bir jetonu doğrulamak. Bir de ilke: şüpheli mesajı silmeyin, işaretleyin. Gerçek bir müşteriyi teknik bir aksaklık yüzünden kaybetmek, panelde birkaç işaretli mesaj görmekten çok daha pahalı.

8. Ölçüm: ne olduğunu bilmeden reklam vermeyin

Bir sitede reklam etiketi yükleniyor ama tek bir dönüşüm gönderilmiyordu. Form gönderimlerini, telefon ve WhatsApp tıklamalarını ölçmeden yapılan reklam, karanlıkta atılan oktur. Ziyaretçi takibini de sunucu tarafında yapmak, reklam engelleyicilerin ve JavaScript çalıştırmayan botların veriyi bozmasını önlüyor.

Sonuç

Tek bir Node.js süreci, tek bir veritabanı dosyası ve işletme sahibinin rahatça kullandığı sade bir panel. WordPress kötü değil; ama bir tanıtım sitesi için çoğu zaman gereğinden fazla. Sitenizi taşımayı düşünüyorsanız yazın; birlikte bakalım.