Büyük Web Sitelerinde Teknik SEO: Enterprise SEO Rehberi

Teknik SEO, 10 sayfalık bir site için de 10 milyon sayfalık bir platform için de aynı temel prensiplere dayanır. Ancak ölçek büyüdükçe sorunların karmaşıklığı, etki alanı ve çözüm maliyeti dramatik biçimde artar. Küçük bir sitede manuel olarak çözülebilen bir crawl sorunu, büyük bir e-ticaret platformunda on binlerce sayfayı etkileyen bir sistem hatasına dönüşebilir.

Enterprise SEO, yalnızca büyük hacimlerle değil; büyük organizasyonların teknik kısıtları, çok ekipli geliştirme süreçleri ve karmaşık CMS mimarileriyle de uğraşmayı gerektirir. Bu rehberde büyük ölçekli web sitelerinde karşılaşılan temel teknik SEO sorunlarını ve bunları sistematik biçimde yönetmenin yollarını ele alacağız.

Genel teknik SEO temellerini yeni öğreniyorsanız önce teknik SEO rehberimize ve teknik SEO denetimi nasıl yapılır yazımıza bakmanızı öneririz; bu yazı ise doğrudan büyük ölçekte ortaya çıkan ek katmanlara odaklanır.

Büyük Site Nedir?

Enterprise veya büyük ölçekli web sitesi tanımı için kesin bir sayı yoktur; ancak sektörde yaygın olarak kullanılan göstergeler şunlardır:

• Sayfa sayısı: 10.000’den fazla benzersiz, indekslenmiş URL
• İçerik türü çeşitliliği: Ürün sayfaları, kategori sayfaları, blog yazıları, kullanıcı profilleri gibi birden fazla farklı şablon türü
• Uluslararası yapı: Birden fazla ülke veya dil için ayrı içerik versiyonları (hreflang)
• Organizasyonel karmaşıklık: Birden fazla ekip, farklı CMS’ler veya bağımsız mikro siteler

Bu kategoriye giren siteler arasında büyük e-ticaret platformları, haber ve medya siteleri, çok konumlu yerel işletme ağları, SaaS platformlarının ürün ve destek belgeleri ve kurumsal içerik merkezleri sayılabilir.

Türkiye pazarında bu tanıma giren siteler genellikle üç grupta toplanır: yerli pazaryerleri ve büyük e-ticaret markaları (onlarca ila yüzlerce bin ürün sayfası), haber portalları (günlük yüzlerce yeni URL üreten, arşivi milyonlara ulaşan yapılar) ve çok şubeli/çok lokasyonlu hizmet işletmeleri (her şube veya şehir için ayrı açılış sayfası üreten zincirler). Her üç grup da farklı teknik önceliklere sahiptir; bir haber portalının en büyük sorunu genellikle tazelik ve hızlı indeksleme iken, bir e-ticaret platformunun en büyük sorunu genellikle faceted navigation ve stok döngüsüdür.

Küçük Site Alışkanlıklarının Büyük Sitede Neden İşe Yaramadığı

Küçük ve orta ölçekli sitelerde geçerli olan pek çok pratik, ölçek büyüdüğünde tersine döner. Aşağıdaki tablo bu farkı somutlaştırır:

Crawl Budget: Nedir, Neden Kritik, Nasıl Korunur?

Crawl Budget Nedir?

Crawl budget, Google’ın bir siteye belirli bir zaman diliminde tahsis ettiği tarama kapasitesidir. İki bileşenden oluşur:

Crawl rate limit: Sitenin sunucusunu aşırı yüklememek için Googlebot’un saniyede gönderebileceği maksimum istek sayısı. Bu değer, sunucunuzun yanıt süresi ve hata oranına göre dinamik olarak belirlenir.

Crawl demand: Google’ın sitenizden ne kadar içerik çekmek istediğini gösteren talep tarafı. Sitenizin popülaritesi, içeriklerinizin tazeliği ve güncelleme sıklığı bu talebi belirler.

Büyük siteler için crawl budget kritiktir çünkü sınırlı kapasite, binlerce önemli sayfanın düzenli olarak taranmasını engelleyebilir.

Gereksiz URL’leri Engelleme

Crawl bütçesinin en yaygın israf kaynakları şunlardır:

Faceted navigation URL’leri: Renk, beden, fiyat aralığı filtreleri her kombinasyon için ayrı URL üretir. 50 renk ve 30 beden seçeneği olan bir sayfa, teorik olarak 1.500 farklı URL üretebilir. Bu URL’lerin büyük çoğunluğu taranmamalıdır.

URL parametreleri: ?sort=price&order=asc, ?ref=email, ?utm_source=google gibi parametreler aynı içeriği farklı URL’lerde gösterir. Bunları robots.txt veya GSC parametreleri aracılığıyla yönetin.

Sayfalandırma URL’leri: Büyük kataloglarda yüzlerce /sayfa/47/ URL’si Googlebot’un zamanını tüketir. Sayfalandırmanın makul bir derinlik sınırı içinde kalmasını sağlayın.

Robots.txt örneği (e-ticaret):

User-agent: Googlebot
Disallow: /arama/
Disallow: /*?ref=
Disallow: /*?sort=
Disallow: /*?order=
Disallow: /sepet/
Disallow: /hesap/
Disallow: /checkout/

Ancak dikkatli olun: robots.txt ile engellenen URL’ler taranmaz ama bu sayfaları indekslemeden çıkarmaz. Kanonical tag veya noindex birlikte kullanılmalıdır.

Crawl Rate Optimizasyonu

Sunucu yanıt süresi ve uptime, Google’ın sitenize atadığı crawl rate’i doğrudan etkiler. Sunucu 5xx hataları verdiğinde Googlebot yavaşlar; yanıt süreleri kısaldığında Googlebot daha agresif tarar.

Google Search Console > Eski Araçlar > Crawl Stats raporunda tarama hızını ve hata oranlarını izleyebilirsiniz.

Crawl Budget Denetimi: Adım Adım Süreç

Büyük bir sitede crawl bütçesi sorununu teşhis etmek ve düzeltmek genellikle şu sırayla ilerler:

1. Toplam URL envanterini çıkarın. CMS veritabanından veya sitemap’lerden gerçek, canlı URL sayısını alın. Bu, “kaç sayfamız var” sorusunun kesin cevabıdır.
2. GSC kapsam raporunu indirin. “Dizine eklendi”, “Dizine eklenmedi” ve alt nedenleri (tarandı - dizine eklenmedi, keşfedildi - şu an dizine eklenmedi, yinelenen içerik) kategorilere ayırın.
3. Log dosyalarından Googlebot’un fiilen taradığı benzersiz URL sayısını çıkarın. Bu değeri toplam URL envanterine bölerek “crawl coverage” oranını hesaplayın.
4. Coverage düşükse (genellikle %70’in altı bir uyarı eşiği kabul edilir) israf kaynaklarını sınıflandırın. Faceted URL’ler mi, parametre varyantları mı, yoksa düşük değerli arşiv sayfaları mı bütçeyi tüketiyor?
5. Önceliklendirilmiş bir engelleme/noindex planı hazırlayın. En büyük israf kaynağından başlayarak robots.txt, noindex ve canonical kombinasyonlarını uygulayın.
6. Değişiklik sonrası 4-6 hafta boyunca log ve GSC verilerini karşılaştırın. Crawl coverage oranındaki değişim, müdahalenin etkisini doğrular.

Bu döngü tek seferlik bir proje değil, büyük sitelerde çeyreklik olarak tekrarlanan sürekli bir disiplin olmalıdır.

Yapay Zeka Botları ve Crawl Bütçesi (2026 Perspektifi)

2026 itibarıyla büyük sitelerin sunucu trafiğinde yalnızca Googlebot ve Bingbot değil; GPTBot, ClaudeBot, PerplexityBot gibi yapay zeka asistanlarına ait tarayıcılar da kayda değer bir pay almaya başladı. Bu botlar klasik anlamda “crawl budget” mantığına dahil değildir (Google’ın indeksleme sistemiyle doğrudan ilişkili değildir) ancak sunucu kaynaklarını tüketir ve log dosyalarınızda ayrı bir segment olarak izlenmelidir. Büyük sitelerde önerilen yaklaşım: bu botları tamamen engellemek yerine, robots.txt üzerinden hangi bölümlere erişebileceklerini bilinçli biçimde tanımlamak (örneğin ürün ve içerik sayfalarına izin verirken hesap ve ödeme akışlarını kapatmak) ve sunucu yükünü düzenli izlemektir. Bazı büyük yayıncılar ve e-ticaret siteleri, llms.txt benzeri deneysel dosyalarla yapay zeka sistemlerine site yapısı hakkında özet bilgi sunmayı test etmeye başlamıştır; bu alan henüz standart bir protokol haline gelmemiş olsa da izlenmeye değer bir gelişmedir.

İndeksleme Yönetimi Büyük Ölçekte

Hangi Sayfalar İndekslensin?

Büyük sitelerin en temel kararı budur. Her sayfa indekslenmeye değmez; aksine, değersiz sayfaların indekslenmesi hem crawl bütçesini tüketir hem de sitenin genel kalite sinyalini düşürür.

Noindex Kullanım Senaryoları

<meta name="robots" content="noindex"> etiketi, sayfanın taranmasına izin verir ama indekslenmesini engeller. Bu, robots.txt’in taramayı tamamen engellediğinden farklıdır. Noindex şu durumlarda tercih edilir:

• İçerik değeri düşük ancak iç linkler nedeniyle taranması gereken sayfalar
• Sayfalandırma sayfalarının ikinci sayfadan itibaren engellenmesi
• Tekrar veya ince içerik barındıran ancak silinmeyen sayfalar
• Oturum açık kullanıcılara yönelik kişiselleştirilmiş sayfalar

Canonical Tag Yönetimi

Büyük sitelerde canonical tag, birden fazla URL’nin aynı içeriği gösterdiği durumları yönetmenin temel aracıdır. Ancak canonical yanlış uygulandığında sorunlara yol açar:

Yaygın canonical hataları:

• Her sayfanın kendini canonical olarak işaretlemesi (otomatik canonical sistemlerinde en sık görülen hata)
• Sayfalandırmada tüm sayfaların 1. sayfayı canonical yapması (Google’ın önerdiği bu değildir)
• İçeriği farklı olan sayfaların birbirini canonical yapması (Google bu sinyali görmezden gelir)
• HTTP ve HTTPS URL’lerinin birbirini canonical yapması

Canonical tag denetimi için Screaming Frog’un “Canonicals” raporunu kullanın. Bu rapor, zincirlenen canonical’ları, canonical kendi kendini işaretlemeyen sayfaları ve canonical URL’nin 4xx döndürdüğü durumları listeler. Canonical etiketinin çalışma mantığını ve doğru kullanım örneklerini canonical etiketi nedir yazımızda daha detaylı işledik.

Hreflang (Çok Dilli Siteler)

Birden fazla dil veya ülke hedefleyen büyük siteler için hreflang uygulaması kritik ancak hata yapmaya son derece açık bir süreçtir.

Hreflang uygulamak için üç yöntem mevcuttur: HTML head içinde <link rel="alternate">, HTTP response header’da Link: field ve XML sitemap’ta <xhtml:link>. Büyük siteler için sitemap yöntemi daha kolay ölçeklenir.

Sık yapılan hreflang hataları:

• Tek yönlü hreflang (her sayfanın tüm dil versiyonlarını ve kendisini işaret etmesi gerekirken yalnızca bir yönde işaret etmek)
• Yanlış dil kodu kullanımı (Türkiye için tr değil tr-TR veya tr kullanılabilir; ama Google kendi belgelerinde her iki formatı da desteklediğini açıklamaktadır)
• Hreflang’da URL’nin 404 veya redirect dönmesi

Site Mimarisi Büyük Ölçekte

Flat vs Deep Architecture

Crawl depth rehberinde ele aldığımız üzere, düz mimari (flat architecture) büyük siteler için temel hedeftir. Ancak gerçekçi olmak gerekir: 500.000 ürünlü bir e-ticaret sitesinde tüm ürünlerin ana sayfadan 2 tıklamayla erişilebilir olması mümkün değildir. Bu nedenle büyük siteler için hedef şöyle yeniden çerçevelenmelidir:

“Stratejik değeri yüksek sayfalar (en yüksek trafikli kategori ve ürünler) mümkün olan en düşük derinlikte; uzun kuyruk sayfalar ise en fazla 4-5 tıklamada erişilebilir olmalıdır.”

Silo Yapısı

Silo, içeriklerin konusal kümelere ayrılarak her kümenin kendi iç link ağını oluşturduğu mimari modeldir. Örnek:

Silo 1: Erkek Giyim
  - /erkek-giyim/ (pillar sayfa)
    - /erkek-giyim/t-shirt/
    - /erkek-giyim/pantolon/
    - /erkek-giyim/ceket/

Silo 2: Kadin Giyim
  - /kadin-giyim/ (pillar sayfa)
    - /kadin-giyim/elbise/
    - /kadin-giyim/bluz/

Silo’nun avantajı, Google’ın tematik otoriteyi net biçimde algılamasıdır. Her silo kendi konusunda uzmanlaşmış bir içerik kümesi oluşturur ve bu kümeler arası iç link yoğunluğu, Google’ın o konuda siteye atfettiği otoriteyi güçlendirir.

Pillar Page + Cluster Modeli

Pillar page (sütun sayfa), geniş bir konuyu kapsamlı biçimde ele alan ana sayfadır. Cluster sayfaları ise o konunun alt başlıklarını derinlemesine işleyen destekleyici içeriklerdir.

Pillar: "Teknik SEO Rehberi" (kapsamli, genel)
  Cluster: Crawl budget nedir?
  Cluster: Canonical tag nasil kullanilir?
  Cluster: Core Web Vitals optimizasyonu
  Cluster: JavaScript SEO
  Cluster: Log analizi ile SEO

Her cluster sayfası pillar’a ve birbiriyle ilgili cluster’lara bağlanır. Bu yapı, hem crawl depth’i kontrol altında tutar hem de konusal otoriteyi güçlendirir.

Internal Linking Otomasyonu ve Stratejisi

Büyük sitelerde iç linkleme manuel olarak yönetilemez. Otomasyon şart koşulur.

Otomatik İç Link Stratejileri

Etiket/kategori tabanlı bağlantı: Her içerik, etiket veya kategori üzerinden otomatik olarak ilgili içeriklerle ilişkilendirilir. Bu, CMS seviyesinde “ilgili yazılar” veya “aynı kategorideki ürünler” mekanizmasıyla uygulanır.

Anahtar kelime tabanlı otomatik link: Bir içerik metni belirli bir anahtar kelime veya ifadeyi geçtiğinde, o anahtar kelimeden hedef URL’ye otomatik iç link eklenir. WordPress’te “SEO Smart Links” gibi eklentiler bu işlevi yerine getirir; ancak çok agresif kullanım doğal okumayı bozabilir.

Breadcrumb otomasyonu: Her içeriğin şablon seviyesinde breadcrumb barındırması zorunlu kılınır. Bu, her sayfanın otomatik olarak üst kategori ve ana sayfaya link vermesi anlamına gelir.

İç Link Denetimi

Büyük siteler için aylık iç link denetimi standart uygulama olmalıdır. Denetimde şu metriklere bakın:

• İç link almayan sayfalar (yetim sayfa listesi) → Yetim sayfalar rehberine bakın
• En fazla iç link alan sayfalar (link gücü yoğunlaşması)
• Kırık iç linkler (hedefi 404 dönen iç linkler)
• Uzun yönlendirme zincirleri üzerinden verilen iç linkler

Sayfalandırma (Pagination) Yönetimi

Sayfalandırma, büyük sitelerde hem crawl bütçesi hem de indeksleme açısından en karmaşık sorunlardan birini oluşturur.

Modern Yaklaşım: rel=“next” / rel=“prev” Desteği Kalktı

Google, 2019’da rel="next" ve rel="prev" etiketlerini artık desteklemediğini açıkladı. Bu, sayfalandırma stratejisinin yeniden değerlendirilmesi gerektiği anlamına gelir.

Önerilen Yaklaşım

Noindex + canonical kombinasyonu: 2. sayfa ve sonrası için noindex ekleyin. Canonical olarak sayfanın kendisini gösterin (tüm sayfalandırma sayfalarını 1. sayfaya canonical yapmak Google tarafından “soft 404” olarak yorumlanabilir).

Sayfa başına içerik artırımı: Sayfa başına gösterilen öğe sayısını artırmak (örneğin 20’den 50’ye) hem UX’i iyileştirir hem de sayfalandırma URL sayısını azaltır.

”Load more” ve infinite scroll: Sayfalandırma URL’leri oluşturmayan alternatiflerdir. Ancak JavaScript bağımlılığı nedeniyle Googlebot’un bu içerikleri düzgün işleyip işlemediğini test etmek gerekir. <link rel="alternate"> ile HTML sayfalandırma versiyonu sunulabilir.

Duplicate Content Yönetimi Büyük Ölçekte

Büyük sitelerde duplicate content neredeyse kaçınılmazdır. Önemli olan tamamen ortadan kaldırmak değil, sistematik biçimde yönetmektir.

Duplicate Content Kaynakları

URL parametreleri: Oturum ID’leri, izleme parametreleri ve sıralama parametreleri aynı içeriği farklı URL’lerde gösterir.

Baskı versiyonları: /urun/ornek/?print=1 gibi baskı sürümleri ana sayfayı kopyalar.

Mobil subdomain: m.ornek.com varlığı, tüm içeriği çoğaltır. Responsive tasarım bu sorunu ortadan kaldırır.

Çapraz kategoriler: Bir ürün birden fazla kategoride listelendiğinde, /kategori-a/urun/ ve /kategori-b/urun/ aynı içeriği iki URL’de sunar.

Çözüm Stratejileri

Canonical tag: Tercih edilen URL’yi canonical olarak işaretleyin; diğer URL’ler aynı içeriği barındırsa da search engine tarafından duplicate olarak değerlendirilmez.

Parameter handling (GSC): Google Search Console’daki URL parametreleri aracıyla hangi parametrelerin içeriği değiştirip değiştirmediğini belirtin. Bu araç Eylül 2022’de deprecated oldu; artık canonical ve robots.txt tercih edilmektedir.

Parametre canonicalization: Tüm parametre varyantlarından canonical URL’ye yönlendirme kurun.

JavaScript Rendering Sorunları

JavaScript ağırlıklı büyük siteler, Googlebot’un içeriği işleme biçimi nedeniyle ek karmaşıklıkla karşılaşır. Googlebot, JavaScript’i oluşturur (renders); ancak bu işlem gecikmeli gerçekleşir: önce HTML taranır, sonra JavaScript işleme kuyruğuna alınır.

JavaScript Rendering Kontrol Adımları

URL Inspection Tool: Google Search Console’da URL inceleme aracıyla “Rendered Page” sekmesini açın. Bu, Googlebot’un sayfayı nasıl gördüğünü gösterir. İçerik orada yoksa Googlebot da göremez.

Rich Results Test: Structured data JavaScript ile yükleniyorsa bu araçla doğrulayın.

Screaming Frog JavaScript rendering: Screaming Frog, embedded Chromium ile JavaScript’i işleyerek Googlebot’un gördüğüne yakın bir çıktı üretir. Bu, rendering sorunlarını proxy araçlara gerek kalmadan tespit etmeyi sağlar.

SSR ve Prerendering

Büyük JavaScript uygulamaları için önerilen yaklaşım:

• Server-Side Rendering (SSR): Next.js, Nuxt.js veya SvelteKit gibi framework’lerle içerik sunucu tarafında render edilir. Googlebot HTML içeriği anında alır.
• Static Site Generation (SSG): Build sırasında tüm sayfalar HTML olarak üretilir. Hızlı ve bot dostudur.
• Prerendering servisi: prerender.io gibi araçlar, bot isteklerini algılayıp önceden render edilmiş HTML ile yanıt verir.

JavaScript SEO konusunun teknik detaylarını, rendering aşamalarını ve yaygın sorunları JavaScript SEO rehberimizde ayrıca ele aldık.

Site Hızı Enterprise Ölçekte

Core Web Vitals (LCP, INP, CLS) büyük siteler için özellikle zorlu bir hedeftir çünkü binlerce sayfa şablonu üzerinde tek tek optimizasyon yapmak mümkün değildir. Metriklerin tanımları ve hedef eşik değerleri için Core Web Vitals rehberimize bakabilirsiniz.

Şablon Tabanlı Optimizasyon

Büyük sitelerde performans optimizasyonu sayfa sayfa değil, şablon bazında yürütülür. Bir e-ticaret sitesinde 3 ana şablon olabilir: kategori sayfası, ürün sayfası, blog sayfası. Her şablonu optimize etmek, o şablonu kullanan binlerce sayfayı tek seferde iyileştirir.

CDN ve Edge Caching

Büyük sitelerde içerik dağıtım ağı (CDN) kullanımı zorunludur. Cloudflare, Fastly veya AWS CloudFront gibi CDN’ler statik kaynakları (CSS, JS, görseller) edge node’lardan sunarak TTFB (Time to First Byte) değerini düşürür.

Edge caching için dikkat edilmesi gereken nokta, dinamik içeriklerin (sepet, kullanıcı verisi) yanlışlıkla cache’lenmemesidir. Cache bypass kurallarını titizlikle yapılandırın.

Görsellerin Toplu Optimizasyonu

Büyük e-ticaret sitelerinde onlarca bin ürün görseli bulunabilir. Bunları toplu olarak optimize etmek için:

• WebP formatına otomatik dönüştürme (Cloudinary, Imgix veya Cloudflare Images)
• Lazy loading (tüm alt sayfa görsellerinde)
• Responsive images (srcset ve sizes attribute)

Log Analizi Büyük Siteler İçin

Log analizi SEO rehberinde temel log analizi konularını ele alıyoruz. Büyük siteler için özel olarak şu analizlere odaklanın:

Crawl coverage: Googlebot’un günde kaç benzersiz URL taradığını ve bu sayının toplam sayfa havuzuna oranını hesaplayın. Coverage %70’in altındaysa ciddi bir crawl bütçesi sorunu var demektir.

Segment analizi: Log verilerini sayfa türüne göre filtreleyin. Ürün sayfaları mı yoksa filtrelenmiş URL’ler mi daha fazla taranan? Bu analiz, robots.txt ve noindex optimizasyonunuz için veri sağlar.

Crawl frekansı dağılımı: Hangi sayfalar haftada bir taranıyor, hangileri aylık taranıyor? Değerli içeriklerin seyrek taranması, içerik kalitesi veya iç link sinyallerini güçlendirme ihtiyacına işaret eder.

Bot davranışı değişimi: Önemli teknik değişiklikler sonrası (sitemap güncellemesi, robots.txt değişikliği) log verilerini karşılaştırın. Googlebot’un tepkisi değişikliğin etkisini doğrulayan en güvenilir veridir.

Teknik SEO Audit Checklist (Büyük Siteler İçin)

Araçlar: Büyük Siteler İçin Teknik SEO Stack

Screaming Frog SEO Spider: 500 URL üzerindeki sitelerde lisanslı versiyon gereklidir. CLI modu ile otomatik raporlama ve periyodik tarama kurulabilir. Büyük siteler için “Crawl Config” ile tarama kapsamını sınırlandırın.

Sitebulb: Görsel crawl haritaları ve derinlik analizleriyle öne çıkar. Her taramanın versiyonlanması, zaman içindeki değişimleri karşılaştırmayı sağlar.

Botify: Enterprise düzeyde log analizi, JavaScript rendering takibi ve crawl simulation sunar. 100.000’den fazla sayfaya sahip siteler için tasarlanmıştır.

ContentKing (SEOmonitor): Gerçek zamanlı site izleme sunar. Bir sayfanın title veya meta description’ı değiştiğinde ya da yeni bir noindex hatası oluştuğunda anında uyarı verir. Büyük organizasyonlarda geliştirici kaynaklı değişikliklerin anlık takibi için kritik önemdedir.

DeepCrawl (Lumar): Enterprise crawl ve raporlama platformu. API entegrasyonuyla CI/CD pipeline’lara bağlanabilir; her deployment sonrası otomatik teknik SEO denetimi yürütülür.

Platform Göçü ve Yeniden Yapılanma (Migration) Riskleri

Büyük siteler için en yüksek riskli teknik SEO olayı genellikle günlük operasyon değil, platform göçüdür: CMS değişikliği, alan adı değişikliği, URL yapısı revizyonu veya tamamen yeni bir tasarıma geçiş. Bu tür projelerde organik trafiğin geçici veya kalıcı olarak düşmesi, iyi planlanmamış SEO göçlerinde sık görülen bir sonuçtur.

Migration Öncesi Kontrol Listesi

• Mevcut sitenin tüm indekslenmiş URL’lerinin tam listesi çıkarıldı mı (Screaming Frog taraması + GSC + analytics + sitemap birleştirilerek)?
• Her eski URL için yeni URL eşleştirmesi (redirect map) hazırlandı mı?
• 301 yönlendirmelerin tek adımda (zincirsiz) çalıştığı test ortamında doğrulandı mı?
• Yeni sitenin robots.txt dosyası test ortamında “tüm botları engelle” durumundan canlıya geçerken güncellendi mi?
• İç link yapısı yeni URL şemasına göre yeniden kuruldu mu, yoksa eski URL’lere mi işaret ediyor?
• XML sitemap yeni URL’lerle güncellendi ve GSC’ye yeniden gönderildi mi?
• Structured data (schema markup) yeni şablonlarda korunuyor mu?
• Analytics ve Search Console mülkiyeti (property) geçiş sonrası doğru şekilde izleniyor mu?

Migration Sonrası İzleme

Geçişten sonraki ilk 4-8 hafta kritik bir izleme dönemidir. Günlük olarak GSC kapsam raporunu, 404 hata sayısını ve log dosyalarındaki Googlebot aktivitesini kontrol edin. Organik trafikte beklenmedik bir düşüş fark ederseniz, önce redirect map’te eksik veya hatalı eşleştirme olup olmadığını, ardından robots.txt ve noindex etiketlerinin yanlışlıkla canlıya taşınıp taşınmadığını kontrol edin. Büyük göçlerde en sık karşılaşılan hata, test ortamındaki Disallow: / kuralının veya site geneli noindex meta etiketinin canlı ortama sızmasıdır.

Sık Yapılan Hatalar

Büyük ölçekli sitelerde tekrar tekrar karşılaşılan teknik SEO hataları şunlardır:

1. Robots.txt ile noindex’i karıştırmak. Bir sayfayı robots.txt ile engelleyip aynı zamanda noindex etiketi eklemek işe yaramaz; Googlebot sayfayı taramadığı için noindex etiketini hiç göremez. Sayfa, daha önce indekslenmişse dizinde kalmaya devam edebilir. Doğru sıralama: önce noindex ile dizinden çıkarın, indeksten düştüğü doğrulandıktan sonra robots.txt ile tarama engelleyin.
2. Otomatik canonical sistemlerini test etmeden yayına almak. CMS’in her sayfaya otomatik canonical ataması, parametre içeren URL’lerde beklenmedik biçimde bozulabilir; örneğin bir filtre URL’si kendisini canonical gösterip asıl kategori sayfasını değil, işlenmemiş ham URL’yi işaretleyebilir.
3. Sitemap’e 404, redirect veya noindex’li URL eklemek. Sitemap yalnızca 200 durum kodu döndüren, indekslenmesi istenen kanonik URL’leri içermelidir. Aksi halde GSC’de “gönderildi ama dizine eklenmedi” oranı gereksiz yere şişer ve bu, Google gözünde site kalitesi hakkında olumsuz bir sinyal olarak yorumlanabilir.
4. Mobil ve masaüstü şablonları arasında içerik tutarsızlığı bırakmak. Google mobile-first indexing kullandığından, mobil şablonda eksik olan içerik (örneğin gizlenen ürün açıklamaları veya yorumlar) tamamen görmezden gelinebilir.
5. Faceted navigation için tek bir kural uygulayıp tüm kombinasyonlara aynı muameleyi yapmak. Bazı filtre kombinasyonları (örneğin “kadın spor ayakkabı 37 numara”) gerçek arama hacmine sahipken bazıları (örneğin “kırmızı beden XXL fiyat 500-1000 TL sıralama fiyat artan”) hiçbir arama talebi barındırmaz. Detaylı bir yaklaşım için faceted navigation SEO rehberimize bakın.
6. Log dosyalarını hiç incelememek. Büyük sitelerde GSC verisi örneklem üzerinden çalışır ve gerçek crawl davranışını tam yansıtmaz; ham sunucu logları olmadan crawl bütçesi sorunlarını kesin biçimde teşhis etmek mümkün değildir.
7. SEO ekibini geliştirme sürecine geç dahil etmek. Yeni bir özellik veya şablon canlıya alındıktan sonra SEO sorunlarının fark edilmesi, büyük sitelerde binlerce sayfayı etkileyen geri dönüşü zor hatalara yol açabilir.
8. Yetim sayfaları (orphan pages) fark etmemek. İç link almayan ama sitemap’te veya CMS’te var olan sayfalar hem taranma hem de otorite açısından dezavantajlıdır. Bu konuyu yetim sayfalar rehberimizde ayrıntılı ele aldık.

Vaka Kurgusu: 220.000 Ürünlü Bir Pazaryerinde Crawl Bütçesi Sorunu

Aşağıdaki senaryo, büyük ölçekli sitelerde sık karşılaşılan bir örüntüyü göstermek amacıyla temsili olarak kurgulanmıştır.

Durum: Orta ölçekli bir Türkiye pazaryeri, 220.000 aktif ürün ve 18.000 kategori/alt kategori sayfası barındırmaktadır. Site trafiği son altı ayda yatay seyretmiş, yeni eklenen ürünlerin organik aramada görünür hale gelmesi ortalama 5-6 hafta sürmeye başlamıştır. Pazarlama ekibi, içerik üretimini artırmasına rağmen organik trafiğin büyümediğini fark eder.

Teşhis süreci: Teknik ekip önce GSC kapsam raporunu inceler ve “keşfedildi - şu an dizine eklenmedi” kategorisinde 340.000’den fazla URL olduğunu görür — bu, toplam ürün sayısının neredeyse iki katıdır. Log dosyası analizinde bu fazlalığın kaynağının renk, beden ve stok durumu filtrelerinden üretilen faceted navigation URL’leri olduğu ortaya çıkar. Googlebot, son 30 günde bu filtre URL’lerine toplam isteklerin yaklaşık üçte ikisini harcamış, gerçek ürün sayfalarına ayrılan pay ise sınırlı kalmıştır.

Uygulanan adımlar:

• Filtre parametreleri (?renk=, ?beden=, ?stok=) robots.txt üzerinden taramaya kapatılır.
• Daha önce indekslenmiş, gerçek arama hacmi taşıyan az sayıda popüler filtre kombinasyonu (örneğin “kadın-spor-ayakkabi?beden=37”) istisna olarak taramaya açık bırakılır ve statik, temiz bir URL yapısına taşınır.
• Kategori sayfalarındaki “ilgili ürünler” ve “benzer kategoriler” blokları genişletilerek yeni eklenen ürünlere daha güçlü iç link akışı sağlanır.
• XML sitemap yeniden yapılandırılır; yalnızca 200 durum kodu dönen, canonical olan ürün ve kategori URL’leri sitemap’te yer alır ve sitemap günlük olarak otomatik güncellenir.

Sonuç penceresi (temsili): Değişikliklerin uygulanmasından yaklaşık 8 hafta sonra log analizinde Googlebot’un ürün sayfalarına ayırdığı tarama payı belirgin biçimde artmış, yeni ürünlerin ortalama indekslenme süresi birkaç günün altına inmiştir. GSC’de “keşfedildi - şu an dizine eklenmedi” kategorisindeki URL sayısı önemli ölçüde azalmıştır. Bu örnek, crawl bütçesi optimizasyonunun içerik üretimi artırmadan da organik görünürlüğü iyileştirebildiğini göstermektedir. (Vaka temsilidir.)

Büyük Site Yönetiminde Organizasyonel Zorluklar

Teknik SEO büyük sitelerde yalnızca teknik bir sorun değil, organizasyonel bir sorundur. Geliştirici takımları, SEO takımları, içerik takımları ve ürün yöneticileri arasındaki koordinasyon eksikliği en yaygın sorunların kaynağıdır.

Önerilen organizasyonel çerçeve:

• SEO review gate: Her yeni özellik veya büyük değişiklik öncesi teknik SEO denetimi zorunlu kılınmalıdır.
• SEO monitoring alerting: ContentKing veya benzer bir araçla kritik değişiklikler (noindex hatası, canonical kayması, site hızı düşüşü) anında ilgili kişilere bildirilmelidir.
• Teknik SEO dokümantasyonu: URL yapısı, robots.txt kuralları ve canonical stratejisi merkezi bir wiki’de belgelenmelidir.

Siteniz için enterprise ölçekte teknik SEO stratejisi geliştirmek istiyorsanız iletisim sayfamizdan bize ulasabilirsiniz.

Sik Sorulan Sorular