Next.js Sitelerde Teknik SEO ve Core Web Vitals: Render, İndeksleme, LCP, INP ve CLS Rehberi

Google Search, JavaScript uygulamalarını genel olarak crawling, rendering ve indexing aşamalarında işler. Crawling sırasında URL alınır, HTTP cevabı ve ilk HTML değerlendirilir, keşfedilebilen linkler sıraya eklenir. Rendering sırasında Web Rendering Service sayfanın kaynaklarını çalıştırarak son DOM’u görmeye çalışır. Indexing, işlenmiş içeriğin ve sinyallerin arama dizininde değerlendirilmesidir. Bu aşamalar bir mimari garanti değil, teknik gerçekliği anlamak için modeldir.

İlk HTML ne kadar anlamlıysa kritik içerik render kuyruğuna daha az bağımlı olur. Client-side veri çağrısı başarısız olduğunda, robots tarafından engellenen script gerektiğinde veya hydration öncesi boş shell gönderildiğinde ana içerik gecikebilir. Google JavaScript çalıştırabilse de her bot bunu yapmaz; sosyal paylaşım botları, kurumsal tarayıcılar ve bazı erişilebilirlik/arsiv sistemleri ilk HTML ile sınırlı olabilir.

Link discovery de aynı nedenle önemlidir. Server çıktısındaki gerçek `<a href>` ve Next.js `Link`, hedefi açık biçimde gösterir. Yalnız buton click’i içinde `router.push` kullanmak URL ilişkisini HTML’de ifade etmez. Sonsuz scroll içerikleri, her sayfa veya öğe için crawlable URL ve bağlantı sağlamıyorsa yalnız kullanıcı etkileşimiyle keşfedilebilir kalabilir.

Render yöntemi bir kalite sıralaması değildir. İçeriğin değişim sıklığı, kişiselleştirme ihtiyacı, veri kaynağı ve operasyon modeli belirleyicidir. Bir kurumsal hizmet sayfası veya blog yazısı build-time statik üretime uygundur. Kullanıcı hesabı içindeki gerçek zamanlı panel istemci etkileşimi gerektirebilir ve indekslenmesi zaten hedeflenmeyebilir. E-ticaret stok bilgisi server render veya uygun cache ile güncel tutulabilir.

App Router’da statik sayfalar `metadata` nesnesi, route parametresine göre değişen sayfalar `generateMetadata` kullanabilir. Bu API’ler server component sınırında çalışır ve Next.js ilgili head elemanlarını üretir. Title template global marka ekini tutarlı yapar; sayfa başlığı ise her URL’nin özgün konusunu anlatır. Description aynı paragrafın bütün sayfalara kopyası olmamalıdır.

Canonical, `alternates.canonical` içinde ilk render çıktısına eklenebilir. Çok dilli karşılıklar gerçekten varsa `alternates.languages` kullanılır; Türkçe içeriğin makine çevirisi olmayan İngilizce URL’sini varsaymak yanlış hreflang üretir. Open Graph ve Twitter görselleri 1200×630 gibi öngörülebilir ölçülerde, crawlable ve konuya uygun olmalıdır. Article metadata’da yayın/güncelleme zamanı, yazar, kategori ve etiketler gerçek içerik verisinden gelmelidir.

Metadata inheritance sığ birleşir; alt route’taki `openGraph` nesnesi üsttekini tamamen değiştirebilir. Bu nedenle parent görsellerini veya site adını korumak gerekiyorsa açıkça birleştirin. Metadata ile görünür H1 aynı niyeti taşımalı ama aynı uzunlukta olmak zorunda değildir. SEO title daha kısa; H1 bağlamı daha ayrıntılı olabilir.

export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const { slug } = await params;
  const post = getPost(slug);
  if (!post) return {};

  const canonical = `https://example.com/tr/blog/${post.slug}`;
  return {
    title: post.seo.title,
    description: post.seo.description,
    alternates: { canonical },
    openGraph: {
      type: "article",
      url: canonical,
      images: [{ url: post.image.src, width: 1200, height: 675 }],
      publishedTime: post.publishedAt,
      modifiedTime: post.updatedAt,
    },
  };
}

Navigasyonun temel birimi bağlantıdır. Next.js `Link` sonunda gerçek anchor üretir ve client-side geçiş optimizasyonu sağlar. Kartın tamamı tıklanabilir olacaksa anchor alanı semantik kalmalı; içine ikinci bir button veya anchor yerleştirilmemelidir. Paylaş, kaydet veya favori gibi eylemler ayrı butondur; rota değişimi linktir.

Pagination her sayfa için benzersiz ve crawlable URL sağlamalıdır. Faceted navigation sınırsız parametre kombinasyonu üretiyorsa hangi filtrelerin indekslenebilir olduğu belirlenmeli; canonical ve robots yaklaşımı iş ihtiyacına göre tasarlanmalıdır. Infinite scroll kullanıcı deneyimi olarak kullanılabilir, fakat içerik parçaları sayfalı URL’lerle ve href bağlantılarıyla erişilebilir olmalıdır.

Sahte buton navigasyonu klavye ve yardımcı teknoloji deneyimini de bozar. Anchor yeni sekmede açılabilir, adresi kopyalanabilir ve link bağlamı sunar. Button bir işlemi tetikler. Görsel stil ikisini aynı gösterebilir; semantik rolü CSS değil kullanıcı amacı belirler.

Next.js uygulamasında duplicate content çoğunlukla framework’ten değil route ve proxy politikasından doğar. Trailing slash’lı ve slash’sız URL’ler, www/non-www, HTTP/HTTPS, büyük harf, query parametreleri ve locale varyasyonları aynı içeriği sunabilir. Bir ana biçim seçin; diğerlerini kalıcı redirect ile normalleştirin ve canonical, sitemap, internal linklerde yalnız ana biçimi kullanın.

Filtre URL’leri gerçekten ayrı arama talebine cevap vermiyorsa indekslenmesi gerekmeyebilir. Canonical, birbirinden farklı sayfaları zorla birleştirme aracı değildir. Paginated içeriklerin her sayfası kendi içeriğine göre self-canonical olabilir. Locale sayfaları birbirinin kopyası sayılmaz; her dil kendi canonical’ına sahip olur, yalnız gerçek çeviri karşılıkları hreflang ile bağlanır.

Canonical ilk HTML’de bulunmalı ve mutlak, nihai 200 URL’yi göstermelidir. JavaScript ile bir canonical ekleyip server HTML’de farklı değer bırakmak birden fazla veya çelişkili etiket üretebilir. Redirect hedefi ile canonical hedefi aynı olmalı; sitemap redirect URL içermemelidir.

App Router’da `app/sitemap.ts`, `MetadataRoute.Sitemap` döndürerek statik ve veri tabanlı route’ları programatik üretebilir. Blog gibi yerel statik içerikte slug ve `updatedAt` doğrudan canonical veri kaynağından alınır. Sitemap yalnız 200, indekslenebilir ve canonical URL’leri içermelidir. Eski, redirect olan, `noindex` veya 404 adresleri listeden çıkarın.

Locale URL’lerini yalnız gerçek sayfalar için üretin. Profesyonel İngilizce karşılığı bulunmayan Türkçe blog yazısını `/en/` altında otomatik çoğaltmayın ve hreflang eşleştirmeyin. `lastModified` her build’de `new Date()` olmamalı; gerçek içerik güncelleme tarihini kullanmalıdır. Aksi durumda arama sistemine anlamsız tazelik sinyali gönderilir.

Robots.txt tarama iznini yönetir. Bir URL robots ile engellendiğinde bot içeriği ve `noindex` etiketini göremeyebilir; bu yüzden robots engeli indeks kaldırma mekanizması değildir. Private alanlar erişim kontrolüyle korunmalı, public fakat indekslenmemesi gereken sayfalar uygun robots meta veya X-Robots-Tag kullanmalıdır.

export default function sitemap(): MetadataRoute.Sitemap {
  return posts.map((post) => ({
    url: `https://example.com/tr/blog/${post.slug}`,
    lastModified: new Date(post.updatedAt),
    changeFrequency: "monthly",
  }));
}

Structured data, sayfanın anlamını standart sözlükle ifade eder; görünür içeriğin yerine geçmez. Kurumsal kimlik için Organization, hiyerarşi için BreadcrumbList, makale için BlogPosting veya Article kullanılabilir. Bir hizmet sayfasına sırf fiyat veya yorum sonucu bekleyerek Product işaretlemesi eklemek doğru değildir. Service türü de yalnız sayfanın görünür hizmet kapsamını temsil etmelidir.

JSON-LD server çıktısında üretilebilir. Article içinde headline, description, image, datePublished, dateModified, author, publisher, mainEntityOfPage, articleSection ve keywords gibi alanlar canonical içerikten gelmelidir. Yazar kurumsal ekip ise Person gibi gösterilmemeli; Organization kullanılmalıdır. Görsel URL crawlable olmalı ve sayfada gerçekten kullanılan kapakla eşleşmelidir.

FAQ bölümü görünürse schema teknik olarak üretilebilir; ancak Google FAQ rich result görünürlüğünü esas olarak yetkili sağlık ve kamu siteleriyle sınırlandırdı. Bu nedenle sırf sonuç görünümü için her makaleye FAQPage eklemek anlamlı değildir. SSS kullanıcıya fayda sağlıyorsa görünür içerik olarak kalabilir. Yapılandırılmış veri doğru olsa bile rich result garantisi yoktur.

Core Web Vitals, gerçek kullanıcı deneyiminin üç boyutunu izleyen metrik setidir. Largest Contentful Paint yükleme deneyimini, Interaction to Next Paint etkileşim yanıtını, Cumulative Layout Shift görsel kararlılığı ölçer. web.dev iyi deneyim hedeflerini LCP için 2,5 saniye veya daha az, INP için 200 ms veya daha az, CLS için 0,1 veya daha az olarak tanımlar. Değerlendirme, mobil ve masaüstü ayrımında sayfa yüklemelerinin 75. yüzdelik diliminde yapılır.

Bu eşikler sıralama garantisi değildir. Performans, arama değerlendirmesindeki birçok sinyalden biridir ve iyi skor zayıf içeriği kurtarmaz. Buna karşılık yavaş ve kararsız sayfa gerçek kullanıcıyı etkiler; form tamamlama, okuma ve navigasyon davranışını bozar. Teknik hedefi yalnız Lighthouse puanı değil, kullanıcıya hızlı ve güvenilir deneyim sunmak olarak belirleyin.

Önce LCP elementini gerçek cihaz ve rota için bulun. Çoğu kurumsal sayfada hero görseli veya büyük başlık bloğudur. CSS background image tarayıcı tarafından stylesheet işlenene kadar geç keşfedilebilir. Kritik görseli `next/image` ile markup içinde sunmak, doğru `sizes` vermek ve gerçekten LCP ise `priority` ya da uygun `fetchPriority` kullanmak keşfi hızlandırabilir. Her görseli önceliklendirmek bant genişliği rekabeti yaratır.

`next/image` tek başına çözüm değildir. Kaynak görsel gereksiz büyükse, CDN yavaşsa, responsive `sizes` yanlışsa veya LCP kaynağı istemci renderından sonra oluşuyorsa optimizasyon sınırlı kalır. Görselin intrinsic width/height değerini tanımlayın, uygun modern format kullanın ve mobil kırılımda gereksiz büyük dosya indirmeyin. Hero üzerindeki uzun raster metin yerine gerçek HTML başlık kullanın.

LCP’nin sunucu ve render bileşenlerini ayırın: TTFB, resource load delay, resource load duration ve element render delay. Yavaş veri çağrısını cache veya static generation ile azaltın. Kritik font varyantlarını sınırlayın; bütün ağırlıkları preload etmeyin. Render-blocking CSS ve senkron üçüncü taraf scriptleri denetleyin. CDN cache ve sıkıştırma politikasını HTML ile görsel için ayrı değerlendirin.

• LCP görseli ilk HTML’de bulunuyor ve erken keşfediliyor.
• `sizes` gerçek responsive yerleşimi tarif ediyor.
• Yalnız kritik görsel yüksek öncelik alıyor; alt görseller lazy-load.
• TTFB ve yavaş server veri bağımlılıkları ayrı ölçülüyor.
• Font ve kritik CSS, görselin ekrana çizilmesini gereksiz geciktirmiyor.

INP, kullanıcının etkileşiminden sonraki görsel güncellemeye kadar geçen süreyi değerlendirir. Büyük client bundle parse ve execution maliyeti yaratır; yoğun hydration ana thread’i meşgul eder. Bütün componentleri `use client` yapmak server component avantajını kaybettirir. İçerik, layout ve veri sunumunu server’da tutup form, filtre, slider veya accordion gibi gerçek etkileşim bölgelerini küçük client island’lara ayırın.

Uzun task’ları DevTools Performance ile bulun. Büyük döngüler, senkron JSON işleme, tek event içinde çok state güncellemesi ve pahalı render zincirlerini bölün. Code splitting ile route açılışında gerekmeyen editör, grafik veya modal kodunu erteleyin. State’i bütün sayfayı yeniden render edecek üst seviyede tutmayın. Input handler içinde layout ölçümü ve yazımını tekrar tekrar karıştırmayın.

Üçüncü taraf scriptleri genellikle görünmeyen INP bütçesi tüketir. GTM, Meta Pixel, Clarity, chat widget ve A/B test aracı aynı başlangıç anında çalışıyorsa ana thread rekabeti oluşur. Her scriptin iş sahibini, consent gereksinimini, yükleme stratejisini ve kaldırma kriterini belgeleyin. Next.js Script stratejileri yükleme zamanını yönetmeye yardımcı olur; ağır kodu otomatik olarak hafifletmez.

Görsel ve video için width/height veya aspect-ratio ile alan ayırın. Reklam, embed ve client-only bloklar için beklenen boyutta placeholder kullanın. Skeleton içeriğin son ölçüsüne yakın olmalıdır; dar skeleton’ın geniş karta dönüşmesi shift üretir. Dinamik header yüksekliği ve sticky CTA, sayfa başladıktan sonra içerik alanını itmemelidir.

Font swap metin ölçüsünü değiştirebilir. Yakın metrikli fallback font seçin, gerekli ağırlıkları sınırlayın ve font loading stratejisini gerçek sayfada test edin. Cookie banner mümkünse overlay veya ayrılmış alanla gelmeli; sayfanın üstüne sonradan eklenerek bütün içeriği aşağı itmemelidir. Kullanıcı onayı olmadan üçüncü taraf script yüklememek hem privacy hem performans açısından önemlidir.

Hydration mismatch de CLS kaynağı olabilir. Server’da farklı tarih, locale veya kullanıcı durumu; client’ta başka çıktı üretirse React bölgeyi değiştirebilir. Server ve client ilk renderını deterministik tutun. Kullanıcıya özel bilgiyi ayrılmış alanda hydration sonrası gösterin ve boyutunu önceden ayırın. Shift kaynağını Performance paneli ve field RUM attribution verisiyle doğrulayın.

App Router’da componentler varsayılan olarak server component’tir. Bu iyi bir başlangıç sınırıdır. Makale gövdesi, breadcrumb, ilişkili içerik listesi, schema ve metadata server/static kalabilir. Arama kutusu, kategori filtresi, bülten formu ve mobil menü ayrı client component olabilir. Bir üst layout’a `use client` eklemek, altındaki büyük ağacı istemci sınırına taşıyabilir.

Client component server component’i doğrudan import etmemeli; server içeriği `children` gibi prop olarak bileştirmek tercih edilebilir. Etkileşim verisini özet tutun. Blog araması için bütün makale gövdelerini client bundle’a göndermek yerine başlık, açıklama, kategori, etiket ve slug yeterlidir. Bu ayrım hem bundle boyutunu hem veri sızıntısı ve hydration maliyetini azaltır.

Bundle analyzer, route bazlı JavaScript maliyetini görünür kılar. Ancak sayı tek başına karar değildir; çalıştırma süresi, cihaz sınıfı ve etkileşim anı önemlidir. Server component stratejisinin SEO faydası, HTML içeriğinin hazır olmasıdır; performans faydası ise gereksiz istemci JavaScript’ini azaltmasıdır. Form gibi gerçek etkileşimleri server yapmaya çalışmak da gereksiz karmaşıklık yaratabilir.

Her script için envanter tutun: sağlayıcı, amaç, veri sahibi, consent kategorisi, yüklendiği sayfalar, boyut ve ana thread etkisi. GTM konteyneri görünür tek script olsa da içinde çok sayıda tag tetiklenebilir. Duplicate GA4 veya aynı pixel’in hem hard-code hem GTM’den çalışması ölçümü ve performansı bozar. Preview/debug ile gerçek tetiklemeleri kontrol edin.

Consent Mode, kullanıcı seçimi ve yasal gerekliliklerle birlikte yapılandırılmalıdır. Analytics veya reklam scriptini “performans için geciktirme” kararı, consent davranışını yanlış uygulama gerekçesi değildir. Chat widget yalnız iletişim ihtimali yüksek sayfalarda ve etkileşim/idle sonrası yüklenebilir. Clarity gibi analiz araçlarının sampling ve sayfa kapsamı sınırlandırılabilir.

Next.js Script için `beforeInteractive`, `afterInteractive` ve `lazyOnload` gibi stratejiler vardır. Kritik olmayan scripti başlangıca koymayın; ama işlevin ne zaman gerekli olduğunu test edin. Worker tabanlı çözümler uyumluluk doğrulaması ister. Üçüncü taraf güncellemesi sizin deploy’unuz olmadan performansı değiştirebilir; RUM alarmı ve periyodik envanter bu nedenle gereklidir.

Lighthouse ve DevTools kontrollü koşulda teşhis sağlar. Build öncesi regression yakalamak, render-blocking kaynakları görmek ve belirli cihaz/ağ profiliyle karşılaştırma yapmak için değerlidir. PageSpeed Insights laboratuvar verisi benzer simülasyon üretir. Lighthouse gerçek kullanıcı etkileşimi olmadığı için INP’yi doğrudan ölçmez; Total Blocking Time yardımcı laboratuvar sinyalidir.

Chrome UX Report ve Search Console Core Web Vitals raporu uygun trafik hacmine sahip origin/URL grupları için anonim alan verisi sunar. RUM, kendi kullanıcı oturumlarınızdan metrik ve attribution toplayarak route, cihaz ve release bazlı teşhis sağlar. GA4 custom web vitals yaklaşımı örnekleme ve cardinality sınırları dikkate alınarak kurulabilir. Kişisel veri ve consent politikası ölçüm tasarımının parçasıdır.

Lab ile field sonucu farklı olabilir: cihaz gücü, ağ, cache, coğrafya, kullanıcı etkileşimi, A/B varyantı ve üçüncü taraf davranışı aynı değildir. Bir rota laboratuvarda hızlıyken gerçek kullanıcıların düşük seviye telefonlarında ağır olabilir. Bu nedenle laboratuvarı geliştirme geri bildirimi, field verisini kullanıcı sonucu olarak kullanın; ikisini aynı sayı gibi karşılaştırmayın.

Semantik HTML, yalnız ekran okuyucu desteği değildir; başlık, navigasyon, article, time, table ve link ilişkilerini açık biçimde ifade eder. Tek H1, sıralı H2/H3 yapısı, klavyeyle erişilen içindekiler, görünür focus ve anlamlı alt metin uzun-form içeriğin kullanımını iyileştirir. Mobil tablolar kontrollü yatay scroll içinde olmalı ve başlık hücreleri `th` ile tanımlanmalıdır. Kod blokları klavyeyle kaydırılabilir olmalı, bütün sayfada yatay taşma üretmemelidir.

Security header’ları doğrudan sıralama taktiği değildir; güvenilir production işletiminin parçasıdır. Content-Security-Policy yanlış yazılırsa Next.js scriptleri, analytics, görseller veya form doğrulaması engellenebilir. HSTS yalnız HTTPS altyapısı hazırken uygulanmalı; redirect ve sertifika zinciri doğrulanmalıdır. X-Content-Type-Options, Referrer-Policy ve Permissions-Policy gibi başlıklar merkezi config üzerinden yönetilmeli ve staging ile production farkı belgelenmelidir.

Erişilebilirlik veya güvenliği skor kovalamaya indirgemeyin. Otomatik araçlar eksik label, kontrast veya header uyarısı yakalayabilir; klavye sırası, ekran okuyucu bağlamı ve gerçek CSP ihlalleri manuel test ister. SEO denetimi, arama botunun erişimi kadar gerçek kullanıcının içeriği okuyup eyleme geçebilmesini de kapsamalıdır.

• Her componenti `use client` yapmak: Büyük hydration alanı ve gereksiz JavaScript üretir.
• Metadata’yı yalnız client’ta değiştirmek: İlk HTML ve HTML-sınırlı botlar doğru head bilgisini göremeyebilir.
• JS click ile navigasyon: Link keşfi, klavye kullanımı ve standart tarayıcı davranışı bozulur.
• Yanlış canonical: Locale, staging, eski domain veya redirect URL’si ana kaynak olarak bildirilir.
• Duplicate sitemap URL’leri: Slash, query veya locale varyasyonları yayın niyetini karıştırır.
• Hydration mismatch’i görmezden gelmek: İçerik değişimi, console warning ve layout shift üretebilir.
• Hero background’ını geç keşfetmek: LCP kaynağı CSS ve client render sonrasına kalır.
• Bütün üçüncü taraf scriptleri başlangıçta yüklemek: Main thread ve network bütçesini etkileşimden önce tüketir.
• Büyük PNG kullanmak: Gereksiz transfer ve decode maliyeti oluşturur; responsive varyantlar eksik kalır.
• Lighthouse puanını tek başarı ölçütü görmek: Gerçek kullanıcı dağılımını ve işlevsel kaliteyi yok sayar.
• Her sayfayı SSR yapmak: Statik içerikte gereksiz sunucu bağımlılığı ve TTFB değişkenliği yaratabilir.
• `next/image` ile işin bittiğini sanmak: Yanlış sizes, geç render, yavaş origin ve aşırı priority sorunlarını çözmez.

Next.js teknik SEO başarısı framework seçiminden değil; render stratejisi, erişilebilir HTML, performans bütçesi ve yayın sonrası ölçüm disiplininden gelir. Statik blog yazısını client-side API’ye bağlamak da, gerçek zamanlı paneli zorla build-time üretmek de bağlamı kaçırır. Doğru yöntem kullanıcı ve veri ihtiyacına göre seçilir.

İlk HTML’de ana içerik ve linkler, server metadata içinde canonical ve sosyal veriler, canonical kaynaktan sitemap ve schema, küçük client island’lar, ölçülü görsel/script politikası ve gerçek kullanıcı verisi sağlam bir temel oluşturur. Bir platform yenilemesinde bu kararların URL migrasyonuyla birlikte ele alınması gerekiyorsa web sitesi yenileme SEO migrasyon rehberi teknik yayın planını tamamlar.