Robots.txt JS Dosyası Erişimi

Robots.txt JS dosyası erişimi, arama motoru botlarının bir web sitesindeki JavaScript kaynaklarını tarayıp tarayamadığını belirleyen teknik yapılandırmadır. 2026 itibarıyla JavaScript dosyalarına erişimi engellenen sitelerde Googlebot'un render başarı oranı %0'a düşmekte ve bu sayfalar yalnızca ham HTML üzerinden değerlendirilmektedir. Render edilemeyen sayfaların indeksleme kalitesini doğrudan belirleyen bu erişim kuralı, robots.txt dosyasındaki Disallow direktiflerinin kapsamıyla kontrol altına alınır.

JavaScript Dosyalarının Tarama Sürecindeki Rolü

Googlebot bir sayfayı taradığında, ham HTML'deki <script src> referanslarını takip ederek JavaScript dosyalarını indirir. İndirilen bu dosyalar WRS (Web Rendering Service) tarafından çalıştırılır ve sayfanın nihai DOM yapısı oluşturulur. Eğer bot, JavaScript dosyasını indiremezse render işlemi başarısız olur ve sayfa yalnızca ham HTML haliyle değerlendirilir.

Bu durum, JavaScript ile dinamik olarak oluşturulan tüm içeriğin bot tarafından görünmez kalması anlamına gelir. Ürün açıklamaları, fiyatlar, yorum bölümleri, navigasyon menüleri ve hatta başlık etiketleri JavaScript'e bağımlıysa, bu elemanların hiçbiri indekslenmez. Dolayısıyla robots.txt dosyasında JavaScript kaynaklarının Disallow kuralıyla engellenmesi, sitenin render edilebilirliğini kökten ortadan kaldıran kritik bir yapılandırma hatasıdır.

Robots.txt Disallow Kuralının JavaScript Dosyalarına Uygulanma Biçimi

Robots.txt dosyasında /wp-includes/, /wp-content/themes/ veya /assets/js/ gibi dizinleri toplu olarak engellemek, o dizinlerdeki tüm dosyaları tarama dışı bırakır. Bu engellemeler genellikle güvenlik gerekçesiyle veya tarama bütçesi tasarrufu amacıyla yapılır. Ancak bu dizinler aynı zamanda sayfanın render edilmesi için zorunlu olan JavaScript ve CSS dosyalarını barındırır.

WordPress altyapısında /wp-includes/js/ dizini jQuery ve diğer çekirdek JavaScript dosyalarını, /wp-content/themes/tema-adi/js/ dizini ise tema JavaScript'lerini barındırır. Bu dizinleri Disallow kuralıyla kapatmak, sitenin frontend'inin bot tarafından render edilememesine neden olur. Dolayısıyla robots.txt'te dizin bazlı Disallow kuralı yazarken, o dizinde JavaScript veya CSS dosyası olup olmadığını kontrol etmek zorunlu bir adımdır.

WordPress Varsayılan Robots.txt Yapılandırmasında Gizli Riskler

WordPress'in dinamik olarak ürettiği varsayılan robots.txt dosyası /wp-admin/ dizinini engeller. Bu engelleme doğrudur; yönetim paneline botun erişmesine gerek yoktur. Ancak /wp-admin/admin-ajax.php dosyası bunun istisnasıdır. Birçok tema ve eklenti, frontend'deki dinamik içerik yüklemeleri için bu dosyaya istek gönderir.

Varsayılan WordPress robots.txt'i bu istisnayı içermez. Dolayısıyla admin-ajax.php'ye bağımlı frontend bileşenleri bot tarafından render edilemez. Çözüm, robots.txt dosyasına şu kuralı eklemektir:

    
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php       
    

Allow kuralı, Disallow kuralından daha spesifik olduğu için bot /wp-admin/admin-ajax.php dosyasına erişebilir ancak dizinin geri kalanı kapalı kalır. Bu yapılandırma, WordPress tabanlı sitelerde standart bir uygulama olmalıdır.

CSS Dosyalarının Engellenmesinin Render Üzerindeki Etkisi

Robots.txt dosyasındaki Disallow kuralları yalnızca JavaScript'i değil, CSS dosyalarını da etkileyebilir. CSS dosyalarına erişim engellendiğinde bot, sayfayı stilsiz bir HTML olarak render eder. Bu durum, botun sayfanın layout yapısını anlayamamasına ve above-the-fold içerik tespitini yanlış yapmasına neden olur.

Google, CSS dosyalarının engellenmesini açıkça önerilmeyen bir uygulama olarak tanımlamıştır. Bot, CSS bilgisi olmadan hangi içeriğin görünür alanda, hangisinin gizli veya display:none ile saklandığını ayırt edemez. Bu ayrım, gizli içerik cezası değerlendirmesi açısından kritiktir. Dolayısıyla CSS dosyalarını barındıran dizinler (/css/, /styles/, /wp-content/themes/*/style.css) robots.txt'te kesinlikle engellenmemelidir.

Search Console "Engellenen Kaynaklar" Raporunun Kullanımı

Search Console, bir sayfanın render edilmesi için gereken ancak robots.txt tarafından engellenen kaynakları raporlar. Bu rapora URL Denetleme aracı üzerinden ulaşılır. URL'yi girdikten sonra "Canlı URL'yi Test Et" ve ardından "Taranmış Sayfayı Görüntüle" seçeneğini kullanın. "Diğer bilgiler" bölümündeki "Sayfa kaynakları" listesi, engellenen kaynakları kırmızı ikonla işaretler.

Bu rapordaki her kırmızı kaynak, botun render sürecinde eksik kalan bir parçadır. Engellenen kaynaklar arasında sitenin kendi JavaScript ve CSS dosyaları varsa, robots.txt kurallarınızda düzeltme yapmanız zorunludur. Üçüncü parti kaynaklar (analytics scriptleri, reklam ağı dosyaları) engellenmiş olabilir; bu kaynaklar genellikle render için kritik değildir ve görmezden gelinebilir. Ayrım, kaynağın sayfanın içerik render'ı için gerekli olup olmadığına göre yapılmalıdır.

Üçüncü Parti JavaScript Dosyalarının Robots.txt Etkisi

Bir sayfada yüklenen JavaScript dosyaları yalnızca sitenin kendi sunucusundan gelmez. Analytics araçları, reklam ağları, A/B test platformları, canlı sohbet widget'ları ve sosyal medya eklentileri kendi CDN'lerinden JavaScript dosyaları yükler. Bu dosyaların erişilebilirliği, sitenin robots.txt dosyasından değil, ilgili üçüncü parti domain'in robots.txt dosyasından kontrol edilir.

Dolayısıyla sitenizin robots.txt dosyasında üçüncü parti JavaScript URL'lerini Allow veya Disallow olarak belirtmeniz etkisizdir. Bot, cdn.thirdparty.com/script.js dosyasına erişip erişemeyeceğini cdn.thirdparty.com/robots.txt dosyasından kontrol eder. Üçüncü parti bir script, sayfanın içerik render'ı için kritikse ve o domain'in robots.txt'i botu engelliyorsa, bu sorunu çözmek sizin elinizde değildir. Bu durumda o script'in işlevini kendi sunucunuzdan barındırılan bir alternatifle değiştirmek veya SSR ile içeriği JavaScript'ten bağımsız hale getirmek gerekir.

Webpack, Vite ve Build Araçlarının Ürettiği Dosya Yolları

Modern JavaScript framework'leri, Webpack veya Vite gibi build araçları kullanarak JavaScript dosyalarını bundle eder. Bu araçlar, dosya adlarına hash ekler (örneğin main.a1b2c3d4.js) ve dosyaları genellikle /_next/static/, /assets/, /static/js/ veya /build/ gibi dizinlere yerleştirir. Robots.txt'te bu dizinleri Disallow kuralıyla engellemek, sitenin tüm frontend JavaScript'ini bot erişimine kapatır.

Next.js projelerinde /_next/ dizini, CSS, JavaScript ve statik varlıkların tamamını barındırır. Bu dizinin engellenmesi, Next.js ile oluşturulan sitenin render edilebilirliğini tamamen ortadan kaldırır. Nuxt.js'te /_nuxt/ dizini aynı işlevi görür. Create React App projelerinde /static/ dizini bu dosyaları barındırır. Framework'ün build çıktısını barındıran dizin, robots.txt'te asla Disallow olarak tanımlanmamalıdır. Bu kural, hangi framework kullanılırsa kullanılsın değişmez.

CDN Üzerinden Sunulan JavaScript Dosyalarının Erişim Kontrolü

JavaScript dosyalarını CDN üzerinden sunmak, performans açısından standart bir uygulamadır. Ancak CDN domain'i, ana domain'den farklı bir host olduğunda, bu dosyaların erişilebilirliği CDN domain'inin robots.txt dosyasından kontrol edilir. static.example.com veya cdn.example.com gibi subdomain'ler kullanılıyorsa, bu subdomain'lerin robots.txt dosyalarında JavaScript ve CSS dosyalarının engellenmediğinden emin olunmalıdır.

CDN sağlayıcıları (Cloudflare, AWS CloudFront, Fastly) genellikle varsayılan olarak robots.txt dosyası sunmaz; bu durumda tüm dosyalar bot tarafından erişilebilir olur. Ancak özel bir CDN yapılandırmasında robots.txt tanımlanmışsa, bu dosyanın JavaScript ve CSS kaynaklarını engellemediğini doğrulamak gerekir. curl -I https://cdn.example.com/robots.txt komutuyla CDN'in robots.txt durumunu hızlıca kontrol edebilirsiniz.

Inline JavaScript ve Robots.txt İlişkisi

HTML dosyasının içine doğrudan yazılan inline JavaScript (<script> etiketleri arasındaki kod), harici bir dosya referansı içermediği için robots.txt kurallarından etkilenmez. Bot, HTML'i indirdiğinde inline JavaScript kodunu da alır. Dolayısıyla inline JavaScript, robots.txt engellemelerinden bağımsızdır.

Ancak bu durum, tüm JavaScript'i inline olarak yazmanın çözüm olduğu anlamına gelmez. Inline JavaScript, tarayıcı cache'inden yararlanamaz, sayfa boyutunu artırır ve Content-Security-Policy (CSP) kısıtlamalarıyla çatışabilir. Büyük JavaScript bloklarını inline olarak yazmak, performans açısından zararlıdır. Doğru yaklaşım, harici JavaScript dosyalarının robots.txt'te erişime açık tutulmasıdır; inline JavaScript'e sığınmak değildir.

Service Worker Dosyalarının Robots.txt Durumu

Service worker, tarayıcının arka planında çalışan ve ağ isteklerini yakalayabilen bir JavaScript dosyasıdır. Service worker dosyası genellikle sitenin kök dizininde (/sw.js veya /service-worker.js) yer alır. Bu dosyanın robots.txt ile engellenmesi, botun PWA (Progressive Web App) yapılandırmasını anlayamamasına neden olabilir.

Ancak pratikte service worker'lar, botun sayfa render'ı için doğrudan kritik değildir. Bot, service worker'ı çalıştırmaz; yalnızca sayfanın HTML, JavaScript ve CSS kaynaklarını kullanarak render yapar. Dolayısıyla service worker dosyasının robots.txt'te engellenmesi, render kalitesini doğrudan etkilemez. Yine de gereksiz Disallow kurallarından kaçınmak adına, service worker dosyasını engellememeniz önerilir.

JavaScript Modüllerinin (ES Modules) Zincirleme Bağımlılık Riski

Modern JavaScript uygulamaları ES Modules (import/export) yapısını kullanır. Bir JavaScript dosyası, başka dosyalardan modül import eder; bu dosyalar da kendi bağımlılıklarını import eder. Bu zincirleme yapı, tek bir robots.txt engeli ile domino etkisi oluşturabilir. Ana bundle dosyası erişilebilir olsa bile, import ettiği bir modül dosyası engelleniyorsa, render zinciri kırılır.

Build araçları (Webpack, Vite, Rollup) bu modülleri genellikle tek bir bundle dosyasına birleştirir; bu durumda zincirleme bağımlılık sorunu ortadan kalkar. Ancak code splitting uygulandığında, JavaScript birden fazla chunk dosyasına bölünür. Her chunk, ayrı bir HTTP isteği ile indirilir ve robots.txt kurallarına tabi olur. Code splitting uygulanan projelerde tüm chunk dosyalarının robots.txt'te erişime açık olduğu doğrulanmalıdır. Aksi halde belirli sayfalarda render başarısız olur ve sorunun kaynağı tespit etmesi zor bir noktada gizlenir.

Google Fonts ve Harici Font Dosyalarının Erişilebilirliği

Web fontları, CSS @font-face kuralı veya Google Fonts API üzerinden yüklenir. Font dosyalarının bot tarafından erişilebilir olması, sayfanın doğru render edilmesi için gereklidir. Font yüklenemediğinde bot, sistem fontlarına geri döner ve sayfanın layout'u değişebilir. Bu değişiklik, CLS (Cumulative Layout Shift) skorunu etkiler ve botun layout değerlendirmesini bozabilir.

Google Fonts, fonts.googleapis.com ve fonts.gstatic.com domain'leri üzerinden sunulur. Bu domain'lerin robots.txt dosyaları, bot erişimine izin verir. Ancak kendi sunucunuzda barındırdığınız (self-hosted) fontlar, sitenizin robots.txt kurallarına tabidir. Font dosyalarını barındıran dizini (/fonts/, /assets/fonts/) Disallow kuralıyla engellemek, font yüklemesini bozar. Bu dizinlerin açık tutulması gerekir.

JavaScript Source Map Dosyalarının Robots.txt Yapılandırması

Source map dosyaları (.js.map), minified JavaScript kodunun orijinal kaynak koduyla eşleştirilmesini sağlar. Bu dosyalar, geliştirme ve hata ayıklama amacıyla üretilir. Üretim ortamında source map dosyalarının herkese açık olması güvenlik riski oluşturabilir; çünkü uygulama kodunun okunabilir versiyonuna erişim sağlar.

Source map dosyalarının robots.txt ile engellenmesi, güvenlik perspektifinden kabul edilebilir bir uygulamadır. Bot, source map dosyalarını render sürecinde kullanmaz; bu dosyalar yalnızca DevTools'ta hata ayıklama amaçlıdır. Dolayısıyla Disallow: /*.map$ kuralı, JavaScript dosyalarının render'ını etkilemeden source map'leri bot erişimine kapatır. Bu kural, wildcard ve satır sonu ($) operatörlerini kullanarak yalnızca .map uzantılı dosyaları hedefler.

Robots.txt Değişikliklerinin Test Edilmesi ve Doğrulanması

Robots.txt dosyasında yapılan her değişiklik, beklenmedik kaynakların engellenmesine veya açılmasına neden olabilir. Değişiklikleri üretime almadan önce test etmek, kritik hataların önlenmesi için zorunludur. Search Console'daki robots.txt Test Aracı, belirli URL'lerin mevcut kurallar tarafından engellenip engellenmediğini kontrol eder.

Test sürecinde sitenizin ana JavaScript ve CSS dosyalarının URL'lerini araca girerek erişim durumunu doğrulayın. Bu URL'leri tespit etmek için Chrome DevTools'ta Network sekmesini açın, sayfayı yenileyin ve "JS" ve "CSS" filtrelerini uygulayın. Listelenen dosyaların URL'lerini kopyalayarak robots.txt test aracına yapıştırın. Her birinin "İzin verildi" sonucunu döndürmesi gerekir. Bu testi her robots.txt değişikliğinden sonra ve aylık teknik SEO denetimlerinde tekrarlamak, güvenli bir operasyonel standart oluşturur.

JavaScript Dosyalarının Tarama Bütçesi Üzerindeki Etkisi

JavaScript dosyalarının bot tarafından taranması, tarama bütçesinden pay alır. Büyük bir JavaScript uygulamasında onlarca hatta yüzlerce JavaScript chunk dosyası bulunabilir. Bot, sayfayı render etmek için bu dosyaların tamamını indirmek zorundadır. Her dosya ayrı bir HTTP isteği tüketir.

Bu maliyet, tarama bütçesinin JavaScript dosyalarına mı yoksa HTML sayfalarına mı harcanacağı sorusunu gündeme getirir. Ancak JavaScript dosyalarını engelleyerek bütçe tasarrufu yapmak yanlış bir stratejidir; çünkü engellenen dosyalar render başarısızlığına neden olur ve sayfa içeriği indekslenemez. Doğru yaklaşım, JavaScript bundle boyutunu küçültmek, code splitting ile yalnızca gerekli chunk'ları yüklemek ve HTTP/2 multiplexing ile dosya indirme süresini optimize etmektir. Tarama bütçesini korumak, erişimi engellemekle değil, dosya boyutunu ve sayısını azaltmakla sağlanır.

Güvenlik Gerekçesiyle JavaScript Engellemenin Riskleri

Bazı site yöneticileri, JavaScript dosyalarını robots.txt ile engelleyerek kaynak kodlarını botlardan gizlemeye çalışır. Bu yaklaşım güvenlik açısından anlamsızdır; çünkü robots.txt bir erişim engeli değil, bir tavsiye protokolüdür. Kötü niyetli aktörler robots.txt kurallarını görmezden gelir. Ayrıca JavaScript dosyaları, tarayıcının DevTools'u ile zaten herkesin erişimine açıktır.

Güvenlik gerekçesiyle JavaScript dosyalarını engellemenin SEO maliyeti, elde edilen güvenlik kazancından katlanarak yüksektir. LinkedIn üzerindeki web güvenliği ve SEO topluluklarında tartışılan vaka analizleri gösteriyor ki, JavaScript engeli nedeniyle render başarısızlığı yaşayan sitelerin organik trafiği, engel kaldırıldıktan sonra ortalama 4-6 hafta içinde %40-60 oranında toparlanıyor. Bu veri, engelin ne denli büyük bir indeksleme kaybına yol açtığını somutlaştırır.

Crawl Delay ve JavaScript Dosya İsteklerinin Zamanlama İlişkisi

Robots.txt dosyasında Crawl-delay direktifi, botun ardışık istekler arasında beklemesi gereken süreyi saniye cinsinden tanımlar. Google bu direktifi resmi olarak desteklemez, ancak Bing ve Yandex dikkate alır. Crawl-delay değeri yüksek tutulduğunda, JavaScript dosyalarının indirilme süresi de uzar ve render işlemi gecikmektedir.

Bir sayfanın render edilmesi için 15 JavaScript chunk dosyası gerekiyorsa ve Crawl-delay 10 saniye olarak ayarlanmışsa, yalnızca JavaScript dosyalarının indirilmesi 150 saniye sürer. Bu gecikme, botun tarama verimliliğini dramatik biçimde düşürür. Bing ve Yandex botları için Crawl-delay kullanılacaksa, değerin 1-2 saniyeyi aşmaması önerilir. Google için ise bu direktif yerine Search Console üzerinden tarama hızı ayarlarını kullanmak doğru yaklaşımdır.

Dinamik Rendering ve JavaScript Dosya Erişimi Etkileşimi

Dinamik rendering, bot isteklerini tespit edip önceden render edilmiş HTML sunarken normal kullanıcılara CSR deneyimi sunmayı ifade eder. Bu mimaride bot, JavaScript dosyalarına erişim ihtiyacı duymaz; çünkü zaten tam HTML alır. Dolayısıyla dinamik rendering kullanan sitelerde JavaScript dosyalarının robots.txt ile engellenmesi, teorik olarak render kalitesini etkilemez.

Ancak bu yaklaşım iki risk barındırır. Birincisi, dinamik rendering altyapısı arızalandığında bot, CSR versiyonuyla karşılaşır ve JavaScript dosyalarına erişemezse sayfa boş kalır. İkincisi, dinamik rendering'den SSR'e geçiş yapıldığında robots.txt'teki eski engeller kaldırılmazsa, SSR çıktısı da render edilemez hale gelir. Dolayısıyla dinamik rendering kullansanız bile JavaScript dosyalarını açık tutmak, savunma derinliği ilkesiyle doğru bir stratejidir.

Robots.txt Dosyasının Versiyon Kontrolü ve Değişiklik Takibi

Robots.txt dosyası, sitedeki en kritik yapılandırma dosyalarından biridir. Tek bir satırlık hata, tüm sitenin indekslenmesini engelleyebilir. Bu dosyanın versiyon kontrolü altında tutulması, değişikliklerin izlenebilmesi ve geri alınabilmesi için zorunludur.

Robots.txt dosyasını Git deposuna dahil ederek her değişikliği commit mesajıyla kaydedin. CI/CD pipeline'ında robots.txt değişikliğini algılayan bir adım ekleyerek, otomatik doğrulama testlerini tetikleyin. Bu testler, kritik JavaScript ve CSS dizinlerinin Disallow kuralıyla engellenmediğini, sitemap bildiriminin mevcut olduğunu ve sözdizimi hatası bulunmadığını kontrol etmelidir. Sahadaki gerçek tecrübemiz gösteriyor ki, robots.txt değişikliklerinin versiyon kontrolü olmadan yapıldığı projelerde, yanlışlıkla eklenen bir Disallow kuralının fark edilmesi ortalama 3-4 hafta sürüyor ve bu sürede ciddi indeksleme kaybı yaşanıyor.

JavaScript Erişim Denetiminin Teknik Kontrol Listesi

Kapsamlı bir JavaScript erişim denetimi, sistematik kontrol adımları gerektirir. Aşağıdaki maddeler, her teknik SEO denetiminde uygulanması gereken kontrol noktalarını içerir:

• Framework build dizinini doğrulayın: /_next/, /_nuxt/, /static/js/, /build/ gibi framework çıktı dizinlerinin robots.txt'te Disallow olarak tanımlanmadığını kontrol edin.
• WordPress çekirdek dizinlerini kontrol edin: /wp-includes/js/ ve /wp-content/themes/*/js/ dizinlerinin engellenmediğini, /wp-admin/admin-ajax.php dosyasının Allow kuralıyla açıldığını doğrulayın.
• CDN subdomain robots.txt dosyasını inceleyin: JavaScript dosyalarını sunan CDN domain'inin robots.txt dosyasında Disallow kuralı olmadığını teyit edin.
• Search Console engellenen kaynaklar raporunu kontrol edin: URL Denetleme aracında kırmızı işaretli kaynakların JavaScript veya CSS dosyası olup olmadığını tespit edip gerekli düzeltmeleri yapın.
• Source map dosyalarını seçici biçimde engelleyin: .map uzantılı dosyaları engellerken ana JavaScript dosyalarının erişilebilir kaldığını doğrulayın.

Robots.txt Kural Sıralamasının JavaScript Erişimine Etkisi

Robots.txt dosyasında birden fazla kural aynı URL ile eşleştiğinde, Google en uzun karakter eşleşmesini öncelikli kabul eder. Bu davranış, JavaScript dosya erişiminde hayati önem taşır. Örneğin /assets/ dizinini Disallow ile kapatıp /assets/js/critical.js dosyasını Allow ile açmak mümkündür:

    
User-agent: *
Disallow: /assets/
Allow: /assets/js/    
    

Bu yapılandırmada /assets/js/ yolu, /assets/ yolundan daha uzun olduğu için Allow kuralı öncelik kazanır. Ancak kural sırasının değil, eşleşme uzunluğunun belirleyici olduğunu unutmamak gerekir. Kuralları dosyada hangi sıraya yazarsanız yazın, Google eşleşme uzunluğuna göre karar verir. Bu davranış, yalnızca Google için geçerlidir; diğer botlar farklı önceliklendirme kuralları uygulayabilir.

Periyodik Erişim Denetimi ve Regresyon Önleme Mekanizması

İşin mutfağında durum farklıdır: robots.txt dosyası ilk yapılandırmada doğru kurulsa bile, sonraki süreçte eklenen güvenlik kuralları, CDN değişiklikleri veya eklenti güncellemeleri JavaScript erişimini farkında olmadan kısıtlayabilir. Bir güvenlik eklentisinin güncellenmesi sırasında robots.txt'e eklenen yeni Disallow kuralı, JavaScript dizinini kapsamına alabilir.

Bu riski yönetmek için iki mekanizma birlikte çalışmalıdır. Birincisi, robots.txt dosyasındaki her değişikliği izleyen ve kritik dizinlerin engellenip engellenmediğini kontrol eden otomatik bir monitoring scriptidir. İkincisi, aylık teknik SEO denetiminde Search Console URL Denetleme aracıyla örneklem sayfaların render kalitesini kontrol etmektir. Bu iki katman birlikte çalıştığında, JavaScript erişim regresyonları hem otomatik hem de manuel olarak yakalanır ve indeksleme kaybı önlenir.

Robots.txt JavaScript dosya erişimi, teknik SEO'nun en düşük maliyetli ancak en yüksek etkili düzeltme alanlarından biridir. Tek bir satırlık Allow kuralı, sitenin render edilebilirliğini ve dolayısıyla indeksleme kalitesini kökten değiştirebilir. Bu kontrolü ihmal etmek, diğer tüm SEO çalışmalarının temelini çürüten bir yapısal hatadır.