Next.js SEO: Kurumsal web sitesi için teknik kontrol listesi

Next.js SEO, iyi kurulduğunda kurumsal bir sitenin en güçlü yanlarından biridir: sayfalar sunucuda HTML olarak üretilir, başlık ve açıklama her sayfa için ayrı yazılır, site haritası ve robots.txt koddan çıkar. Sorunlar çerçeveden değil kurulumdan doğar. Aşağıdaki kontrol listesi, Türkçe ve İngilizce yayın yapan bir Next.js sitesinde gerçekten önemli olan sekiz teknik başlığı sırayla ele alıyor.

Bu yazı kurucular, pazarlama ve ürün sorumluları için hazırlandı; kod yazmanız gerekmiyor ama ajansınıza ya da yazılım ekibinize doğru soruyu sorabilmeniz gerekiyor. Teknik SEO, içeriğinizin arama motorları tarafından doğru dilde ve doğru adresle bulunup dizine eklenebilmesi için sitenin altyapısında yapılan işlerin toplamıdır. İçerik ve bağlantı (backlink) çalışmaları ayrı bir konudur; burada yalnızca altyapıya bakıyoruz. Sürüm bilgileri ve Google kuralları Ekim 2026 itibarıyla kontrol edildi ve her birinin kaynağı metin içinde verildi. Kendi sitemiz ulviontech.com da Next.js 16, React 19, next-intl ve Sanity ile kurulu; anlattıklarımızın bir kısmını orada yaşadığımız somut sorunlardan aktarıyoruz.

Next.js SEO dostu mu?

Evet, ama kendi başına değil. Next.js arama motorları için gereken araçların neredeyse hepsini hazır verir: sunucu tarafında render (sayfanın sunucuda HTML'e dönüştürülmesi), statik üretim, sayfa bazında metadata, sitemap.ts ve robots.ts dosya kuralları, görsel optimizasyonu. Hangi sayfanın nasıl üretileceğine, hangi adresin asıl adres sayılacağına ve dillerin birbirine nasıl bağlanacağına ise siz karar verirsiniz. Google, JavaScript ağırlıklı sayfaları önce tarar, sonra bir sıraya alıp render eder ve en son dizine ekler; Google'ın JavaScript SEO rehberi (yeni sekmede açılır) sunucu tarafında ya da önceden render etmenin hâlâ iyi bir fikir olduğunu, çünkü her botun JavaScript çalıştıramadığını açıkça söylüyor. Next.js bu yüzden doğru seçimdir; ancak bir sayfayı yanlışlıkla tamamen tarayıcıda çalışan bir bileşene çevirdiğinizde, düz bir React uygulamasının sorunlarını geri getirirsiniz. Bu yazıdaki maddeler, Next.js dokümantasyonunun (yeni sekmede açılır) bugün anlattığı 16.4 sürümündeki App Router içindir; Pages Router kullanıyorsanız ilkeler aynı, dosya adları ve API'ler farklıdır.

Render ve indekslenebilirlik: Google sayfanızın içeriğini görüyor mu?

İlk ve en önemli kontrol, sayfanın asıl metninin sunucudan gelen HTML'in içinde olup olmadığıdır. Tarayıcıda sağ tıklayıp "sayfa kaynağını görüntüle" dediğinizde başlığınızı, ana paragraflarınızı ve hizmet açıklamalarınızı görüyorsanız iyi bir başlangıçtasınız. Metin yalnızca JavaScript çalıştıktan sonra beliriyorsa, Google büyük olasılıkla yine görür ama daha geç görür; sosyal medya önizleme botları ve bazı yapay zekâ tarayıcıları ise hiç görmeyebilir. Next.js'te bu durum genellikle bir sayfanın tepesine "use client" yazılıp verinin useEffect içinde çekilmesiyle ortaya çıkar. Çözüm, veriyi sunucu bileşeninde çekip etkileşimli küçük parçaları ayrı istemci bileşenlerine ayırmaktır.

Kurumsal bir site için render modunu seçerken şu ayrım işe yarar:

• Statik üretim (SSG): Hizmet sayfaları, hakkımızda, iletişim gibi nadiren değişen sayfalar için seçin. En hızlı ve en sorunsuz yoldur.
• Artımlı yeniden üretim (ISR): Blog yazıları ve CMS'ten gelen proje sayfaları için seçin; sayfa statik kalır, içerik belirli aralıklarla ya da bir tetikleyiciyle yenilenir.
• Her istekte sunucu render (SSR): Kişiye ya da ana göre değişen içerik varsa seçin. Kurumsal sitelerde nadiren gerekir ve sunucu maliyetini artırır.
• Yalnızca istemci render: Giriş gerektiren paneller ve arama motorunda görünmesi gerekmeyen ekranlar için seçin; dizine girmesini istediğiniz hiçbir sayfa için seçmeyin.

Bağlantılar için de bir kural var: Google bağlantıları yalnızca href niteliği olan <a> öğelerinden keşfeder. Next.js'in Link bileşeni gerçek bir <a> üretir, ama onClick ile yönlendiren butonlar ve div'ler üretmez. Menüdeki, alt bilgideki ve kartlardaki her geçişin gerçek bir bağlantı olduğundan emin olun.

Kontrolü kendiniz de yapabilirsiniz. Aşağıdaki komut sayfanın sunucudan gelen HTML'ini indirir ve içinde kaç tane h1 etiketi olduğunu sayar; sonuç 1 olmalıdır:

curl -s https://alanadiniz.com/tr | grep -o "<h1" | wc -l

Bağlantı önizlemeleri bozuk görünüyorsa bir ayrıntıya bakın: Next.js 15.2'den beri generateMetadata beklenirken sayfa gövdesi önce gönderilebiliyor; dokümantasyona göre (yeni sekmede açılır) Facebook'un önizleme botu gibi JavaScript çalıştırmayan botlara ise metadata yine <head> içinde veriliyor.

Sayfa bazında metadata: başlık, açıklama ve Open Graph

Her indekslenebilir sayfanın kendine ait bir başlığı (title), açıklaması (description), asıl adresi (canonical) ve paylaşım görseli (Open Graph) olmalıdır. Next.js'te bunlar statik sayfalarda metadata nesnesiyle, CMS'ten gelen sayfalarda generateMetadata fonksiyonuyla verilir. Kök layout dosyasında metadataBase tanımlarsanız göreli adresler tam adrese çevrilir; tanımlamazsanız ve göreli bir adres kullanırsanız derleme hata verir. Başlık şablonu (title.template) ile her sayfanın sonuna marka adını eklemek de burada yapılır. Türkçe sayfaların başlık ve açıklaması Türkçe yazılmalı, İngilizce metnin çevirisi gibi durmamalıdır; arama sonuçlarında okuyucunun ilk gördüğü metin budur.

Sık atlanan bir kural: Next.js, farklı katmanlardan gelen metadata nesnelerini yüzeysel (shallow) birleştirir. Yani bir sayfa kendi openGraph alanını verdiğinde, layout'taki openGraph alanının tamamı yerine geçer; layout'ta tanımlı paylaşım görseli o sayfada kaybolur. Kendi sitemizde bu yüzden her sayfanın metadata'sını tek bir yardımcı fonksiyondan üretiyoruz: fonksiyon sayfanın adresini alır, canonical, dil alternatifleri ve Open Graph alanlarını birlikte döndürür. Böylece hiçbir sayfada bir alan unutulmaz; kural değiştiğinde bütün sayfalar birlikte güncellenir.

Canonical ve hreflang: Türkçe ve İngilizce sayfalar nasıl ayrılır?

Canonical etiketi, aynı ya da çok benzer içeriğe ulaşılan adresler arasından hangisinin asıl adres olduğunu söyler; hreflang ise aynı sayfanın diğer dillerdeki karşılıklarını gösterir. İkisi birlikte çalışır: her dil sürümü kendini canonical olarak gösterir ve diğer dil sürümlerini hreflang ile listeler. Türkçe ve İngilizce yayın yapan bir şirket sitesinde dizin sorunlarının çoğu bu iki etiketin birbiriyle çelişmesinden çıkar.

Canonical URL: her sayfanın tek bir adresi olmalı

Aynı sayfa www ile ve www olmadan, sonunda eğik çizgiyle ve çizgisiz, kampanya parametreleriyle ya da barındırma sağlayıcınızın önizleme alan adında açılabilir. Google'a göre (yeni sekmede açılır) yönlendirme ve rel="canonical" güçlü sinyallerdir, site haritasında yer almak ise zayıf bir sinyaldir; robots.txt canonical belirlemek için kullanılmamalıdır. Pratikte bu şu anlama gelir: bir ana alan adı seçin (biz www olmayan adresi seçtik ve www'yi oraya yönlendiriyoruz), her sayfada alternates.canonical alanına tam adresi yazın ve önizleme ortamlarını dizine kapatın.

Kendi sitemizden bir örnek: next-intl kütüphanesi varsayılan olarak her yanıta dil alternatiflerini HTTP Link başlığı olarak da ekliyor. Bu başlık, sayfadaki etiketlerden farklı bir x-default değeri ve isteğin geldiği alan adını bildirdiği için, sitemiz üretim dışındaki ortamlarda Lighthouse'un canonical denetiminden geçemiyordu. Başlığı kapatıp dil alternatiflerini yalnızca sayfa içi etiketlerden ve site haritasından vermeye karar verdik. Buradan çıkan kural: aynı bilgiyi iki yerden veriyor ve ikisinin hep aynı kalacağından emin olamıyorsanız, birini kapatın.

Hreflang: TR/EN sayfaları birbirine bağlamak

Google'ın çok dilli sayfalar rehberi (yeni sekmede açılır) hreflang'in HTML etiketiyle, HTTP başlığıyla ya da site haritasıyla verilebileceğini söylüyor ve tek bir kuralda ısrar ediyor: her dil sürümü hem kendini hem diğer bütün dil sürümlerini listelemelidir. Türkçe sayfa İngilizceyi gösteriyor ama İngilizce sayfa Türkçeyi göstermiyorsa, işaretleme yok sayılabilir. Dil kodu ISO 639-1 biçiminde (tr, en) verilir; bölge kodu (tr-TR) isteğe bağlıdır ve yalnızca farklı ülkelere farklı içerik sunuyorsanız anlamlıdır. x-default, ziyaretçinin diline uyan bir sürüm olmadığında gösterilecek sayfadır; biz İngilizceyi seçtik. Google hreflang'i bir ipucu olarak değerlendirir, yani doğru işaretleme her zaman doğru sürümün gösterileceğini garanti etmez ama hatalı işaretleme neredeyse her zaman sorun çıkarır.

Next.js App Router'da iki dil için en sade yol next-intl ile her adresi dil önekiyle (/tr/..., /en/...) sunmaktır. Türkçe adresleri Türkçe kelimelerle yazmak (/tr/hizmetler/web-uygulamalari) kullanıcı için daha anlaşılırdır; bu durumda iç bağlantılar mutlaka kütüphanenin yönlendirme yardımcılarından geçmeli, yoksa Türkçe bir sayfa İngilizce adrese bağlantı verir. Bir içerik yalnızca tek dilde varsa (örneğin sadece Türkçe yazılmış bir blog yazısı), hreflang listesinde olmayan dil yer almamalıdır; var olmayan bir sayfayı göstermek, hiç göstermemekten kötüdür. Ziyaretçiyi IP adresine ya da tarayıcı diline göre otomatik olarak başka dile yönlendirmeyin; Google bunu önermiyor (yeni sekmede açılır), çünkü Googlebot bu durumda dil sürümlerinden birini hiç göremeyebilir.

Hangi adres yapısını seçmeli?

Çok dilli bir sitede dil sürümlerini nerede tutacağınız, sonradan değiştirmesi en pahalı kararlardan biridir. Google'ın aynı rehberde saydığı seçenekleri kurumsal bir site açısından şöyle özetleyebiliriz:

Karar için kısa bir kural: tek bir şirket olarak Türkiye'ye ve yurt dışına aynı hizmetleri anlatıyorsanız alt dizini seçin. Ülkeye göre farklı fiyat, ürün ya da yasal metin sunuyorsanız ülke alan adını değerlendirin. Alt alan adını yalnızca dil sürümlerini gerçekten farklı sistemler yönetiyorsa seçin.

Sitemap, robots.txt ve iç linkler: Google sayfalarınızı nasıl bulur?

Arama motoru bir sayfayı üç yoldan bulur: başka bir sayfadaki bağlantıdan, site haritasından ya da dışarıdan gelen bir bağlantıdan. İlk ikisi tamamen sizin kontrolünüzdedir ve Next.js'te ikisi de koddan üretilebilir. Bu, site haritasının elle güncellenmesini ve unutulmasını önler; aynı veri kaynağından beslenen menü, site haritası ve hreflang listesi birbiriyle çelişmez.

sitemap.xml ve robots.txt: Next.js'te doğru kurulum

app/sitemap.ts dosyası bir dizi adres döndürür ve Next.js bundan sitemap.xml üretir; sitemap dosya kuralı (yeni sekmede açılır) her adres için dil alternatiflerini de destekler. Google'ın site haritası rehberi (yeni sekmede açılır) birkaç net kural koyuyor: adresler tam ve mutlak olmalı, bir dosya en fazla 50.000 adres ya da sıkıştırılmamış 50 MB olmalı, priority ve changefreq değerleri yok sayılıyor, lastmod ise yalnızca tutarlı biçimde doğruysa kullanılıyor. Bu yüzden kendi sitemizde lastmod değerini yalnızca CMS'teki gerçek güncelleme tarihi olan sayfalara yazıyoruz; kodla tanımlı sayfalarda tek bilinen tarih derleme zamanı olduğu için o alanı boş bırakıyoruz. KVKK aydınlatma metni gibi noindex olan sayfaları da site haritasına koymuyoruz, çünkü dizine kapalı bir adresi göndermek Search Console'da gereksiz hata üretir.

app/robots.ts ise tarayıcılara hangi yolları taramamaları gerektiğini ve site haritasının nerede olduğunu söyler. Burada en yaygın yanlış anlama şudur: robots.txt bir sayfayı arama sonuçlarından çıkarmaz. Google'ın robots.txt rehberine göre (yeni sekmede açılır) engellenen bir adres, başka sitelerden bağlantı alıyorsa açıklamasız biçimde yine görünebilir; bir sayfayı sonuçlardan uzak tutmak için noindex kullanılmalıdır. Test ve önizleme ortamlarını ise en sağlam biçimde parola ya da noindex başlığıyla kapatın.

İç linkleme: sayfalar birbirine nasıl bağlanmalı?

İç bağlantılar hem ziyaretçiyi hem tarayıcıyı önemli sayfalarınıza taşır. Blog yazıları ilgili hizmet sayfasına, hizmet sayfaları ilgili projelere ve yazılara bağlantı vermelidir; hiçbir sayfadan bağlantı almayan "yetim" sayfalar site haritasında olsa bile zayıf kalır. Bağlantı metni gideceği sayfayı anlatmalıdır: "buraya tıklayın" yerine "özel web uygulaması geliştirme" gibi. Breadcrumb (gezinti yolu) hem kullanıcıya bulunduğu yeri gösterir hem de yapılandırılmış veriyle birleştiğinde arama sonucunda adres yerine okunabilir bir yol olarak görünebilir. Örneğin kurumsal sitelerde web uygulaması geliştirme hizmet sayfamız, bu yazı gibi teknik içeriklerden bağlantı alır ve tamamladığımız projelere bağlantı verir.

Yapılandırılmış veri: hangi şema türleri gerçekten işe yarar?

Yapılandırılmış veri (structured data), sayfanın ne anlattığını arama motorlarına makinelerin okuyabileceği biçimde söyleyen JSON-LD bloklarıdır. Kurumsal bir site için dört tür çoğu ihtiyacı karşılar ve her birinin yeri farklıdır. Asıl kural şudur: işaretleme, sayfada gerçekten görünen içerikle birebir aynı olmalıdır; sayfada olmayan bir puanı, yorumu ya da adresi işaretlemek fayda değil risk getirir.

Son satır önemli, çünkü pek çok rehber hâlâ tersini söylüyor. Google, SSS zengin sonuçlarını Ağustos 2023'te yalnızca tanınmış devlet ve sağlık sitelerine sınırlamıştı (yeni sekmede açılır); Search Central değişiklik kaydına göre (yeni sekmede açılır) bu özellik 7 Mayıs 2026'dan itibaren Google aramada hiç görünmüyor ve Haziran 2026'da ilgili dokümantasyon kaldırıldı. FAQPage hâlâ geçerli bir schema.org türüdür ve sayfanızdaki gerçek soru-cevapları makinelerin okuyabileceği hâle getirir; ama arama sonucunda açılır soru kutuları artık beklenmemeli. Ajansınız "SSS şeması ekleyelim, sonuçlarda büyüyelim" diyorsa bu tarihi sorun.

Next.js'te JSON-LD için resmî öneri (yeni sekmede açılır), veriyi layout ya da sayfa bileşeninde düz bir <script type="application/ld+json"> etiketiyle basmak ve içerikteki < karakterini \u003c ile değiştirerek XSS riskini kapatmaktır. next/script bileşeni çalıştırılacak JavaScript içindir, yapılandırılmış veri için gerekmez. Yayın öncesinde her şablonu Google'ın Rich Results Test aracından ve Schema Markup Validator'dan geçirin; bir şablonu doğrulamak, o şablondan üretilen yüzlerce sayfayı doğrulamak demektir.

Core Web Vitals ve görseller: hız sıralamayı ne kadar etkiler?

Core Web Vitals, Google'ın sayfa deneyimini ölçtüğü üç metriktir ve eşikleri web.dev'e göre (yeni sekmede açılır) şöyledir: en büyük içeriğin görünme süresi (LCP) 2,5 saniye veya altı, etkileşime yanıt süresi (INP) 200 milisaniye veya altı, görsel kayma (CLS) 0,1 veya altı. Değerlendirme, gerçek ziyaretçilerin yüzde 75'inin yaşadığı değere göre yapılır; INP, 2024'te FID'nin yerini aldı. Google'ın Core Web Vitals sayfası (yeni sekmede açılır) bu metriklerin sıralama sistemlerinin ödüllendirdiği şeyle uyumlu olduğunu söylüyor; sayfa deneyimi rehberi (yeni sekmede açılır) ise iyi skorların üst sıra garantisi olmadığını ve Google'ın deneyim zayıf olsa bile en alakalı içeriği göstermeye çalıştığını ekliyor. Hız tek başına sıralama kazandırmaz; iyi içeriği desteklediğinde işe yarar.

Next.js sitelerde bu üç metriği en çok etkileyen şeyler bellidir:

• Görseller: next/image kullanın ve her görsele width ile height verin ya da fill ile boyutu olan bir kutuya yerleştirin; boyutsuz görsel CLS'nin en yaygın nedenidir. sizes niteliği telefonun masaüstü boyutunda görsel indirmesini önler.
• LCP görseli: Sayfanın üst kısmındaki ana görseli önceden yükletin. Next.js 16 ile priority niteliği kullanımdan kaldırıldı ve yerini preload aldı; ayrıntılar Image bileşeni dokümantasyonunda (yeni sekmede açılır).
• Yazı tipleri: next/font ile yazı tipini kendi alan adınızdan sunun; harici yazı tipi isteği hem LCP'yi hem metin kaymasını kötüleştirir.
• Üçüncü taraf betikler: Canlı destek, ısı haritası, birden fazla etiket yöneticisi ve reklam pikselleri INP ve ana iş parçacığı süresini en çok bozan kalemlerdir. Her betiğin bir sahibi ve bir gerekçesi olmalı.

Laboratuvar ölçümü ile gerçek kullanıcı verisini karıştırmamak da önemlidir. Lighthouse, yavaş bir telefonu ve ağı taklit eden bir laboratuvar testidir; Google'ın değerlendirdiği ise Chrome kullanıcılarından toplanan saha verisidir (CrUX). Kendi sitemizin Türkçe ana sayfasını 7 Ekim 2026'da Lighthouse ile ölçtüğümüzde masaüstünde performans, erişilebilirlik, en iyi uygulamalar ve SEO skorlarının dördü de 100 çıktı; mobil simülasyonda ise performans 85, LCP 3,6 saniye oldu. Bu sonuç, mobil laboratuvar testinin neden ayrıca izlenmesi gerektiğini gösteriyor: masaüstündeki 100, telefondaki deneyimi garanti etmez. Bir sonraki adım, bu sayının saha verisinde de aynı mı olduğuna Search Console'un Core Web Vitals raporundan bakmaktır.

Yayına almadan önce Next.js SEO kontrol listesi

Aşağıdaki liste, yeni bir siteyi ya da büyük bir güncellemeyi canlıya almadan önce ekibinizle birlikte üzerinden geçebileceğiniz maddelerdir. Her maddeyi tek bir sayfada değil, her şablonda (ana sayfa, hizmet, proje, blog yazısı) bir kez kontrol edin:

1. Sayfa kaynağında ana metin ve tek bir h1 var; içerik JavaScript beklemeden görünüyor.
2. Her sayfanın başlığı ve açıklaması kendine özgü, Türkçe sayfalarda Türkçe yazılmış.
3. Canonical etiketi tam adresi gösteriyor; www, sondaki eğik çizgi ve parametreli adresler tek adrese yönleniyor.
4. Her dil sürümü kendini ve diğer dilleri hreflang ile listeliyor, x-default tanımlı, var olmayan dil listelenmiyor.
5. Ziyaretçi diline ya da IP'sine göre otomatik yönlendirme yok; dil seçimi bağlantıyla yapılıyor.
6. sitemap.xml yalnızca dizine açık, 200 dönen, canonical adresleri içeriyor; lastmod gerçek tarihlerden geliyor.
7. robots.txt site haritasını gösteriyor ve önemli bir yolu engellemiyor; test ortamı parola ya da noindex ile kapalı.
8. Organization işaretlemesi bir kez, BlogPosting ve BreadcrumbList ilgili şablonlarda var ve Rich Results Test'ten hatasız geçiyor.
9. Her görselin boyutu ve alternatif metni (alt) var; ana görsel preload ile yükleniyor.
10. Lighthouse mobil ve masaüstü ölçümü canlı ortama benzer bir üretim derlemesinde yapıldı ve sonuçlar kaydedildi.
11. Menü, alt bilgi ve kartlardaki her geçiş gerçek bir <a href> bağlantısı; Türkçe sayfalar Türkçe adreslere bağlanıyor.
12. Eski siteden taşınıyorsanız her eski adresin kalıcı (301 ya da 308) yönlendirmesi yazıldı ve test edildi.
13. Search Console'da site doğrulandı ve site haritası gönderildi.

Sık yapılan hatalar

Next.js sitelerinde tekrar eden hatalar genellikle şu dört kalıba girer:

• Önizleme alan adının dizine girmesi: Barındırma sağlayıcısının test adresi açık kalır ve aynı içerik iki alan adında yarışır.
• Layout'tan gelen tek başlık: Varsayılan başlık hiçbir sayfada değiştirilmez, her sayfa arama sonucunda aynı görünür.
• Var olmayan çeviriye hreflang: Sadece Türkçe olan bir yazı, hiç yazılmamış bir İngilizce adresi alternatif olarak gösterir.
• Yönlendirmesiz taşıma: Yıllardır bağlantı alan eski adresler 404 döner ve birikmiş değer kaybolur.

Biz olsak ne yapardık?

Türkçe ve İngilizce yayın yapan, 10 ile 40 sayfa arası hizmet ve proje içeriği olan, blogunu bir CMS'ten yöneten tipik bir şirket sitesi için varsayılanımız bellidir. Next.js App Router ile kod tarafında tanımlı sayfaları statik, CMS sayfalarını ISR ile üretiriz; dilleri next-intl ile alt dizinde ve Türkçe adres kelimeleriyle sunarız. Tüm adresleri tek bir yönlendirme haritasından türetiriz: menü, canonical, hreflang, site haritası ve breadcrumb aynı kaynaktan beslenir, bu yüzden birbirleriyle çelişemez. Organization işaretlemesini kök layout'a, BlogPosting ve BreadcrumbList'i şablonlara bir kez yazarız ve her sürümü canlıya almadan önce üretim derlemesinde Lighthouse ile ölçeriz. Bu yazıda anlattığımız yapı, kendi sitemizin bugün çalışan kurulumudur. Aynı ihtiyaçların, yani çok dilli yayının ve CMS'ten yönetilen sayfaların öne çıktığı iki projemiz de var: tedavi sayfaları ve blogu birden fazla dilde yayınlanan bir sağlık turizmi koordinatörünün sitesi ve her işlem için ayrı sayfası, SSS'si ve blogu Sanity'den yönetilen bir estetik cerrahi grubunun sitesi.

Koddan önce yazılı kapsam ve sabit fiyat çıkarırız; kod deposu, alan adı ve Search Console hesabı ilk günden şirketinizin adına açılır; süreci adım adım hakkımızda sayfasında anlattık. Çok kiracılı bir ürün ya da üye girişli bir platform kuruyorsanız SaaS platformu geliştirme sayfamız, şirket içi bir panel için yönetim paneli geliştirme sayfamız daha uygun başlangıç noktalarıdır.

Maliyeti ve süreyi ne belirler?

Teknik SEO'yu ayrı bir kalem olarak fiyatlamak yerine, sitenin kuruluş kapsamına dahil etmek en ucuz yoldur; sonradan eklemek genellikle daha pahalıdır. Kapsamı ve süreyi en çok şu etkenler değiştirir:

• Dil sayısı ve adres yapısı: Her yeni dil, çeviri değil yerelleştirilmiş adresler, metadata ve hreflang test yükü demektir.
• Taşıma: Mevcut bir siteden geçiyorsanız eski adreslerin haritalanması ve yönlendirilmesi, yeni sayfa yazmak kadar zaman alabilir.
• İçeriğin kaynağı: İçerik kodda mı, bir CMS'te mi duracak; CMS varsa önizleme, yayın akışı ve SEO alanlarının editöre açılması kapsamı büyütür.
• Üçüncü taraf betikler: Ne kadar çok pazarlama aracı bağlanacaksa performans hedefini korumak o kadar emek ister.
• Sayfa şablonu sayısı: Sayfa sayısından çok şablon sayısı belirleyicidir; 200 blog yazısı tek şablondur.

Teklifleri karşılaştırırken her ajansa aynı soruları sorun: Canonical ve hreflang hangi kaynaktan üretiliyor? Site haritası otomatik mi? Lighthouse ölçümü hangi ortamda yapılacak ve sonuç teslim belgesinde yer alacak mı? Kod deposu ve Search Console hesabı kimin adına açılacak? Net cevap veremeyen bir teklif, ucuz görünse de bu işleri kapsamıyor olabilir.

Hangi durumlarda bizimle çalışmamalısınız?

Her şirket sitesi için özel bir Next.js geliştirmesi gerekmez. Beş sayfalık bir tanıtım siteniz varsa ve yakın zamanda çok dilli içerik, CMS entegrasyonu ya da özel bir iş akışı planlamıyorsanız, Webflow, Wix ya da iyi yapılandırılmış bir WordPress kurulumu gibi kodsuz veya az kodlu bir araç ihtiyacınızı daha düşük maliyetle karşılar. Bu araçlarda site haritası ve temel metadata için hazır ayarlar ya da eklentiler bulunur; birkaç sayfalık bir sitede yukarıdaki listenin çoğunu bir ayar ekranından kontrol edebilirsiniz.

Şirketinizde Next.js bilen bir geliştirme ekibi zaten varsa, bir ajansa değil, bu kontrol listesine ve odaklı bir iç çalışmaya ihtiyacınız vardır. Sorununuz altyapı değil de içerik, rakip analizi ya da bağlantı kazanımıysa, bir yazılım ekibi yerine içerik ve SEO stratejisi yapan bir danışmanla çalışmanız daha doğru olur. Son olarak, belirli bir anahtar kelimede sıralama garantisi arıyorsanız bizimle çalışmayın: bunu kimse dürüstçe garanti edemez ve biz de etmiyoruz.

Sitenizin hangi maddede takıldığını birlikte görmek isterseniz, mevcut adresinizi ve hedeflediğiniz dilleri iletişim sayfamızdan bize yazabilirsiniz; ilk yanıtı 24 saat içinde veriyoruz.