Next.js teknik SEO: proxy, canonical ve locale
Next.js 16’da middleware yerini proxy’ye bıraktı. Çok dilli sitelerde proxy, canonical ve locale kurgusunun tuzakları.
Yazan Roozbeh Nazari · CEO
Next.js ile kurulmuş çok dilli sitelerde teknik SEO hatalarının çoğu, tek tek sayfalarda değil, isteğin sayfaya ulaşmadan önce geçtiği katmanda oluşur. Bu katman uzun süre middleware adıyla bilindi. Next.js 16 ile birlikte dosya kuralı kullanımdan kaldırıldı ve proxy adını aldı; middleware.ts dosyası proxy.ts olarak yeniden adlandırıldı, dışa aktarılan fonksiyonun adı da proxy oldu. Yeniden adlandırmanın gerekçesi, "middleware" teriminin Express.js middleware’i ile karıştırılması ve bu katmanın olduğundan daha yaygın kullanılmaya teşvik etmesiydi.
Bu değişiklik SEO açısından yalnızca bir isim değişikliği değil. Kurulumu güncellemeden geçen ekiplerde locale ve canonical kurgusu, kimsenin fark etmediği bir noktada devre dışı kalabiliyor. Aşağıdaki maddeler, çok dilli Next.js kurulumlarında bu katmanın en sık ürettiği hataları ele alıyor. Denetimin geri kalanı için teknik SEO hizmetimize ve yirmi maddelik production denetim listemize bakabilirsiniz.
Geçişte kaybolan katman
Next.js 16’ya yükselen bir projede middleware.ts dosyası yerinde bırakılırsa, dosya kuralı artık tanınmaz. Sonuç bir hata mesajı değil, sessiz bir davranış değişikliğidir: o dosyada tanımlı locale yönlendirmeleri, dil çerezine göre yeniden yazmalar ve başlık eklemeleri artık çalışmaz. Site açılmaya devam eder, sayfalar 200 döner, hiçbir test kırılmaz. Yalnızca dil kurgusu ortadan kalkar.
Next.js bu geçiş için bir codemod sağlıyor; dosyayı ve fonksiyon adını birlikte yeniden adlandırıyor. Yükseltme yapan ekipler için doğru sıra, codemod’u çalıştırmak ve ardından locale davranışını canlıya benzer bir ortamda elle doğrulamaktır. Doğrulama, tarayıcıda değil, Accept-Language başlığı elle ayarlanmış isteklerle yapılmalıdır; tarayıcı zaten kendi dilini gönderdiği için sorunu maskeleyebilir.
Matcher: en pahalı üç satır
Proxy, matcher tanımlanmadığında her istek için çalışır. Buna statik dosyalar, görsel optimizasyon yolları ve public klasöründeki varlıklar da dahildir. Çok dilli kurgularda tipik hata, dil ön eki ekleyen bir yeniden yazmanın statik varlıkları da kapsamasıdır; sonuç, stil ve betik dosyalarının yüklenememesi ya da beklenmedik yollara yönlendirilmesidir.
- Negatif eşleşme kalıbı yazılırken sitemap.xml ve robots.txt yollarının dışarıda bırakılması gerekir. Dil ön eki almış bir sitemap adresi, arama motorunun beklediği adres değildir.
- API yolları dışarıda bırakılmalıdır; dil ön eki eklenen bir API adresi çalışmaz.
- Matcher değerleri sabit olmak zorundadır. Değişkenden üretilen bir matcher derleme sırasında çözümlenemez ve sessizce yok sayılır; kurgu çalışıyor sanılır.
Bir başka ince nokta: negatif eşleşme kalıbında dışarıda bırakılsa bile proxy, veri yolları için yine de çalıştırılır. Bu davranış kasıtlıdır ve sayfayı koruyup karşılık gelen veri yolunu korumasız bırakma hatasını önlemek içindir. Dil kurgusunda bunun anlamı, veri isteklerinin de aynı yeniden yazma mantığından geçeceği ve bu mantığın veri yolu adresini bozmaması gerektiğidir.
Canonical: proxy’de değil, metadata’da
Çok dilli kurgularda sık görülen bir yanlış, canonical adresini proxy katmanında başlık olarak eklemektir. Bu katman sayfanın render edilmesinden önce çalışır ve sayfanın hangi içeriği göstereceğini her zaman bilmez; üretilen canonical, yeniden yazma sonrası adresle uyuşmayabilir. Doğru yer, sayfa ya da layout seviyesinde tanımlanan metadata nesnesidir.
Metadata tarafında canonical ve dil alternatifleri alternates alanı altında tanımlanır: canonical sayfanın kendi tercih edilen adresini, languages ise dil sürümlerinin adreslerini taşır. Dinamik rotalarda bu değerlerin generateMetadata içinde üretilmesi gerekir; statik bir metadata nesnesiyle tanımlanan canonical, tüm dinamik sayfalarda aynı adresi göstererek en klasik şablon hatasını üretir.
Google tarafındaki kural bundan bağımsızdır: canonical bir yönerge değil, güçlü bir sinyaldir. Yönlendirme en güçlü tekilleştirme yöntemidir, canonical etiketi ikinci sıradadır. Yani çelişkili sinyaller ürettiğinizde, örneğin canonical bir adrese işaret ederken dil bildirimi başka bir adresi gösterdiğinde, sonucu siz belirlemezsiniz.
Locale: otomatik yönlendirme tuzağı
Proxy katmanının en cazip kullanımı, ziyaretçinin tarayıcı diline göre dil sürümüne yönlendirilmesidir. Bu kurgu kullanıcı deneyimi açısından mantıklı görünür ve SEO açısından pahalıdır. Arama motoru tarayıcısı tek bir dil tercihiyle gelir; zorunlu yönlendirme kurulduğunda diğer dil sürümleri hiç taranmaz ve dil grubunun üyeleri keşfedilmez.
Bu tuzağı ayrıntılı olarak locale auto-redirect yazımızda ele almıştık. Next.js özelinde eklenecek nokta şudur: yönlendirme mantığı proxy içinde yazıldığında, matcher’a bağlı olarak varlık istekleri de dahil her istek bu mantıktan geçer ve yönlendirme zincirleri oluşur. Zincirin uzunluğu, dil sürümü sayısıyla çarpılarak artar.
Güvenli kurgu, dili zorla değiştirmek yerine önermektir: ziyaretçinin bulunduğu dil sürümünde kalmasına izin verip, tercih ettiği dil için görünür bir seçenek sunmak. Bu yaklaşım her dil sürümünün kendi adresinde taranabilir kalmasını sağlar ve kullanıcının tercihini elinden almaz.
Çalışma ortamı ve doğrulama
Proxy, Node.js çalışma ortamını varsayılan olarak kullanır ve dosya içinde runtime yapılandırma seçeneği ayarlanamaz; ayarlanmaya çalışıldığında hata verir. Eski kurulumlardan taşınan runtime tanımları bu nedenle yükseltme sırasında temizlenmelidir.
Doğrulama tarafında, Next.js 15.1 ile gelen test yardımcıları proxy dosyasının hangi adreslerde çalıştığını birim testiyle doğrulamaya izin veriyor. Çok dilli kurgularda bunun karşılığı somuttur: sitemap, robots ve varlık yollarının proxy kapsamı dışında kaldığını, dil ön ekli yolların ise kapsam içinde olduğunu iddia eden birkaç test, canlıda fark edilmesi haftalar süren hataları derleme aşamasında yakalar.
Bu katmanın bütününe dair pratik kural şudur: proxy, yönlendirme ve yeniden yazma için kullanılmalı, sayfanın kimliğini belirleyen sinyaller için kullanılmamalıdır. Canonical, dil bildirimleri ve başlık etiketleri sayfa katmanına aittir. İkisi karıştığında ortaya çıkan hata, tek bir sayfada değil, tüm şablonda görülür ve genellikle sayfa sayısıyla çarpılarak büyür.
Yükseltme sonrası kontrol listesi
Next.js 16’ya geçen çok dilli bir projede, yükseltme tamamlandıktan sonra elle koşulması gereken kısa bir liste vardır. Bu liste otomatik testlerin yerine geçmez; otomatik testin kapsamadığı, "çalışıyor ama yanlış çalışıyor" sınıfındaki hataları yakalamak içindir.
- Kök dizinde proxy.ts var mı ve dışa aktarılan fonksiyonun adı proxy mi? Eski adla bırakılmış bir dosya sessizce yok sayılır.
- Accept-Language başlığı elle ayarlanmış isteklerde her dil sürümü kendi adresinde 200 dönüyor mu, yoksa tek bir sürüme mi yönleniyor?
- sitemap.xml ve robots.txt dil ön eki almadan erişilebiliyor mu?
- Dinamik bir sayfada canonical, o sayfanın kendi adresini mi gösteriyor, yoksa şablon genelinde tek bir adresi mi?
- Dil bildirimleri karşılıklı mı ve canonical ile aynı adresi mi işaret ediyor?