Headless geçişten sonra trafik neden düşer ve bunu nasıl durdurursunuz
İstemci tarafı render, düşen canonical'lar ve yavaş bir köken. Bir headless geçişinin organik trafiğe sessizce mal olmasının üç yolu — ve her birini nasıl kapatacağınız.
Headless bir CMS'in HTML'iniz hakkında bir fikri yoktur. İçeriği bir API üzerinden döndürür; bir arama motorunun gördüğü her şey sizin yazdığınız kod tarafından üretilir.
İşte bu yüzden "headless SEO için kötü mü?" yanlış sorudur. Doğru soru şu:
yeniden inşa HTML hakkında neyi değiştirdi? Pratikte cevap üç şeyden biridir ve üçü de düzeltilebilir.
#Sızıntı 1 — Yalnızca JavaScript çalıştıktan sonra var olan içerik
En yaygın ve en pahalısı.
Sunucu render'ı olan bir çerçeveye geçtiniz ve ardından makale gövdesini bir istemci efektinde çektiniz, çünkü öğretici böyle yapıyordu. Şimdi:
Googlebot ilk geçişte boş bir kabuk alır ve render sonraya — bazen çok sonraya — kuyruğa alınır.
Diğer tarayıcılar (Bing, AI tarayıcıları, sosyal önizleme botları) çoğunlukla hiç render etmez. Bağlantılarınız boş açılır.
ölçer ve içeriğiniz kabuktan bir gidiş-dönüş sonra ulaşır.
Teşhis — tek komut, araç gerektirmez:
0 içeriğinizin HTML'de olmadığı anlamına gelir. Bu geri 1 dönene kadar bu makaledeki diğer her şey ikincildir.
Düzeltme — sunucuda çekin. Next.js App Router'da bu varsayılandır; hata genellikle ağaçta çok yükseğe yerleştirilmiş bir 'use client' sınırıdır. Sayfayı sarmak yerine onu etkileşimli bileşene indirin.
#Sızıntı 2 — Yeniden inşada kaybolan canonical, meta ve yapılandırılmış veri
Eski CMS'in her sayfa için canonical etiketleri, meta açıklamaları, Open Graph etiketleri ve Article şeması üreten bir SEO eklentisi vardı. Kimse bunu kaldırmaya açıkça karar vermedi. Sadece yeniden inşa kontrol listesinde yoktu.
Belirtiler: yinelenen içerik kümelenmesi (parametreli URL'ler, sondaki eğik çizgi varyantları, sayfalandırılmış arşivlerin hepsinin ayrı ayrı indekslenmesi), eksik zengin sonuçlar ve yanlış başlıkla açılan sosyal paylaşımlar.
Düzeltme — bu alanları tema'nın değil, içerik modelinin bir parçası yapın. corpusctl'de SEO modülü girdi başına başlık, açıklama, canonical ve sosyal görseli içerikle birlikte saklar, böylece onu render eden şeyde yaşamak yerine girdiyle birlikte seyahat ederler.
Sonra bunları CI'da doğrulayın. On temsili URL çeken ve her birinin tam olarak bir kendine-referanslı canonical'a, 155 karakterin altında boş olmayan bir açıklamaya ve geçerli JSON-LD'ye sahip olduğunu kontrol eden bir test bir saate mal olur ve bu sınıf gerilemeyi kalıcı olarak yakalar.
#Sızıntı 3 — Düşünmediğiniz bir önbelleğin arkasındaki yavaş bir köken
Headless genellikle performansı daha iyi yapar. Ön uç her istekte CMS'den çektiğinde ve CMS bir veritabanı sorgusu uzaklıkta olduğunda daha kötü yapar.
TTFB'niz artık her önbellek ıskasında CMS'in yanıt süresi artı render sürenizdir ve her önbellek ıskası bekleyen gerçek bir kullanıcıdır.
Düzeltme — istek anında içeriğin nerede yaşadığına karar verin. Üç seçenek, ne kadar iyi dayandıklarına göre artan sırayla:
İstek başına çek. CMS kritik yoldadır. Bir gösterge paneli için iyi, sıralanmasını istediğiniz içerik için yanlış.
Zaman pencereli ISR. İçerik en fazla N saniye eskidir; her pencere süresi dolumu birinin ödediği bir önbellek ıskasıdır.
Önceden derle ve önbellekten servis et. Yayın anında render edilir, statik bir eser olarak servis edilir. En hızlı ve en ucuz — invalidation ele alındığı sürece.
Üçüncü seçeneğin zor kısmı invalidation'dır, çünkü sayfa, her an değişebilecek bir hesaplamanın kopyasıdır.
corpusctl sorunu yönetmek yerine ortadan kaldırır. Yayınlamak içeriği nesne deposundaki değişmez, hash ile adreslenen bir dosyaya yazar ve bir manifesti yeniler; istemci slug'ı yerel olarak bir manifest parçasına çözer, ardından o adresi nginx kenar önbelleğinden çeker. Adres bir içerik hash'idir, dolayısıyla aynı adres asla farklı içerik döndüremez — otuz gün önbelleğe alınabilir ve yayınlamak yeni bir adres yazar. Temizlenecek bir şey yoktur.
Core Web Vitals için bu doğrudan önemlidir: doküman bir hesaplamadan değil bir önbellekten ulaşır, dolayısıyla TTFB veritabanı yüküyle değişmeyi bırakır ve LCP önbellek isabeti alıp almadığınıza bağlı olmayı bırakır.
Birden fazla dil işletiyorsanız — ve headless bir CMS genellikle tam da bu yüzden seçilir — bu dördüncü sızıntıdır.
Söylemesi kolay, yanlış yapması kolay kurallar:
Her dil sürümü her diğer sürüme, kendisi dahil, bağlantı verir.
Eşleşmeyen ziyaretçiler için sürüme işaret eden bir x-default vardır.
Bağlantılar karşılıklıdır. Tek yönlü bir hreflang tamamen göz ardı edilir.
Dil kodları geçerli BCP 47'dir. Basitleştirilmiş Çince, bölgeyi değil de yazıyı kastettiğinizde, zh-Hans'dır, zh-CN değil.
hreflang içindeki URL, işaret ettiği sayfadaki canonical ile eşleşir.
Bunu elle doğrulamayın. Her URL'yi çekin ve tam kümeyi doğrulayın:
İlgili: dil pazarlığı yapan kök URL 302 döndürmeli, 301 değil. Yanıt Accept-Language'a göre değişir, dolayısıyla kalıcı değildir; bir 301 tarayıcıda önbelleğe alınır ve o makinedeki bir sonraki kişi dilini değiştiremez. Onunla birlikte Vary: Accept-Language, Cookie gönderin, aksi halde bir ara önbellek ilk ziyaretçinin dilini herkese servis eder.
Geçişten sonra en az iki hafta. Sıralamalar kendi takvimlerinde hareket eder ve üç günlük bir panik size hiçbir şey söylemez.
Search Console → Kapsam. 404'lerdeki artış, kaçırdığınız bir yönlendirme demektir. "Tarandı – şu anda indekslenmedi"deki artış genellikle bir şablondan zayıf veya yinelenen çıktı demektir.
Search Console → Performans, sayfa tipine göre bölümlenmiş. Bir şablon diğerlerinden daha fazla kaybettiyse, hata o şablondadır, geçişte değil.
Yalnızca Search Console değil, sunucu günlükleri. Tarama günlüğü size Googlebot'un gerçekte ne istediğini ve ne aldığını söyler. Oradaki bir 404'ü bugün düzeltmek bedava, bir ay sonra düzeltmek pahalıdır.
Laboratuvar skorları değil, Core Web Vitals saha verisi. Laboratuvar skorları dizüstü bilgisayarınızı ölçer.