Yapay zekâ ile web sitesi denetimi: yapay zekâ ajanlarıyla kanıttan doğrulanmış düzeltmeye

1. Yapay zekâ ile web sitesi denetimi nedir?

Web sitesi denetimi, bir sitenin nasıl kurulduğunu, sunulduğunu ve bağlandığını inceler: korunuyor mu, arama motorları ve yapay zekâ sistemleri onu okuyabiliyor mu, insanlar kullanabiliyor mu, ne kadar hızlı ve hangi üçüncü taraf hizmetleri yüklüyor. Yapay zekâ ile web sitesi denetimi bu işe bir yapay zekâ ajanı ekler. Ajan kontrolleri başlatır, sonuçları okur, sade bir dille açıklar, önce neyin düzeltileceğine sizinle birlikte karar verir ve düzeltmeyi yapacak kişi ya da kodlama ajanı için değişiklik talebini yazar.

Birbirinden oldukça farklı üç şey aynı sözcüklerle anlatılır:

Bu rehber üçüncü yaklaşımı anlatır; çünkü yapay zekâ gerçek zaman kazandırırken her bulgu kontrol edebileceğiniz kanıta bağlı kalır. Kontroller tekrarlanabilir kalır; ajan yargı, bağlam ve değişiklikleri yayına alan kişi ve araçlara devri ekler. MCP size yeniyse MCP rehberi host, istemci, sunucu ve araç kavramlarını sade biçimde açıklar.

2. Bir yapay zekâ ajanı tek başına neler yapabilir, neler yapamaz?

Dil modeli okuma, özetleme ve yazmada çok iyidir. Bir ağ aracı değildir. Uygulama ona bu iş için bir araç vermedikçe, görünen sayfanın altında bir tarayıcının veya tarayıcı botunun gördüğünü göremez. Tablo, en fazla bir web gezinme aracı olan tek başına çalışan ajanı, yapılandırılmış kontrollerle çalışan aynı ajanla karşılaştırır.

Claude Code, Codex veya Cursor gibi terminali olan kodlama ajanları curl, dig veya openssl komutlarını kendileri de çalıştırabilir. Bu tek bir bulguyu doğrulamaya yardım eder; ancak ajan komutları o anda seçer: kapsam aklına gelenlere bağlıdır, sonuçlar çalıştırmadan çalıştırmaya değişir ve yaptığı sorguları doğruladığınız alan adlarıyla sınırlayan hiçbir şey yoktur.

Ortadaki sütunun riskinin bir adı var. LLM uygulamaları için OWASP risk listesi yanlış bilgiyi, inandırıcı görünen yanlış veya yanıltıcı çıktı olarak tanımlar; halüsinasyon başlıca nedenlerden biridir ve insanlar doğrulamadan güvendiğinde daha da kötüleşir. Bir denetimde bu, kaydını hiç okumadığı bir alan adı için “DMARC politikanız none olarak ayarlı” demesi ya da sunucunun aslında gönderdiği bir başlığı eksik göstermesi şeklinde ortaya çıkar.

İkinci risk sayfaların kendisinden gelir. Bir web sitesini okuyan ajan güvenilmeyen metin okur ve bir sayfa, bazen insan ziyaretçilerden gizlenmiş olarak, modele yönelik talimatlar taşıyabilir. OWASP bunu dolaylı prompt injection olarak adlandırır. Özenli bir denetim kurulumu sayfa içeriğini asla talimat değil, rapor edilecek veri olarak ele alır ve ajanın attığı her adımı bir kişinin onaylamasını sağlar.

Ajanın iyi yaptığı şey kanıtın çevresindeki her şeydir: bir bulgunun bu site için ne anlama geldiğini açıklamak, ilgili bulguları gruplamak, kontrollerin bilemeyeceği bağlamı sormak (o eski staging alt alan adı hâlâ kullanımda mı?) ve bir kodlama ajanı için yeterince kesin bir düzeltme talebi yazmak. Bu iş bölümü, iyi bir yapay zekâ web sitesi denetiminin özüdür.

3. Kapsanacak altı alan ve her biri için kontrol listesi

Kapsamlı bir web sitesi denetimi altı katmana bakar. Her biri farklı bir soruyu yanıtlar ve farklı türde kanıt üretir. Web sitesi denetimi rehberi tek bir müşteri yolculuğunu altısı boyunca izler; işte çalışma kontrol listesi.

Güvenlik

• HTTPS ve TLS: güvenilir bir sertifika zinciri, önümüzdeki birkaç hafta içinde sona ermeyen sertifika, TLS 1.2 veya 1.3 ve HTTP’den HTTPS’e yönlendirme.
• Güvenlik başlıkları: HTML yanıtlarında Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, çerçeveleme koruması ve Referrer-Policy.
• CORS: özel veri taşıyan yanıtlarda Access-Control-Allow-Origin: * olmaması ve kimlik bilgileriyle birleşen yansıtılmış origin’lerin bulunmaması.
• DNS ve e-posta DNS’i: e-posta gönderen her alan adı için geçerli SPF ve DMARC kayıtları; hiç e-posta göndermeyen alan adları için kısıtlayıcı olanlar (v=spf1 -all, p=reject).
• Açıkta kalan dosyalar ve gizli bilgiler: /.env, /.git/ veya eski yedekler gibi yollarda ulaşılabilir hiçbir şey olmaması ve ön yüz JavaScript’inde API anahtarı bulunmaması.
• Alt alan adları: başkasının sahiplenebileceği, silinmiş bulut kaynaklarına işaret eden DNS kaydı bulunmaması (subdomain takeover).
• Saldırı yüzeyi: yalnızca amaçladığınız açık portlar ve HTTP yöntemleri, bildiğiniz giriş ve yönetim sayfaları ve WordPress kullanıyorsanız güncel CMS ile eklentiler.
• Tedarik zinciri: üçüncü taraf betiklerin yalnızca sizin seçtiğiniz kaynaklardan yüklenmesi.

Bu kontrollerin bir kısmı yalnızca herkese açık bilgiyi okur. Hassas yolları istemek veya port taramak gibi diğerleri sahibinin kabul etmesi gereken istekler gönderir; bu yüzden bir denetim aracı bunları yalnızca sahipliğini doğruladığınız hedeflerde çalıştırmalıdır. Web sitesi güvenlik denetimi rehberi uygulama tarafını ele alır: hesaplar, izinler ve giriş.

Teknik SEO

• Taranabilirlik: robots.txt, dizine eklenmesini istediğiniz sayfaları veya kaynakları engellemez.
• Dizinleme: önemli sayfalarda başıboş noindex yoktur ve site haritası canonical URL’leri listeler.
• Başlıklar ve meta açıklamalar: mevcut, benzersiz ve sayfayı tarif ediyor.
• Başlık hiyerarşisi: tek net ana başlık ve mantıklı bir taslak.
• Canonical’lar: her sayfa tercih edilen URL’sine işaret eder; asla bir yönlendirmeye veya hata sayfasına değil.
• Yapılandırılmış veri: görünen içerikle uyuşan geçerli JSON-LD.
• Dahili bağlantılar ve yönlendirmeler: önemli sayfalara gezinme veya içerikten ulaşılabilir; birkaç yönlendirmeden oluşan zincirler yoktur.
• Search Console verisi: gösterimi çok ama tıklama oranı düşük sayfalar ve ilk sonuçların hemen altında yer aldığınız sorgular. Bunlar çoğu zaman en hızlı kazanımlardır.

Burada bir sınır önemlidir. Google bir sayfayı dizine eklemeden önce JavaScript’i işler; ancak JavaScript SEO temelleri yine de kısmen bazı botlar JavaScript çalıştıramadığı için sunucu tarafı işleme veya ön işlemeyi önerir. Statik HTML okuyan bir denetim sayfayı bu botların gördüğü gibi görür; içeriğini tarayıcıda oluşturan bir sitede bulguları işlenmiş sayfayla karşılaştırın. Teknik SEO denetimi rehberi daha derine iner.

Yapay zekâ görünürlüğüne hazırlık

• Yapay zekâ tarayıcı politikası: her yapay zekâ tarayıcısı için robots.txt kuralları, kimsenin seçmediği bir eklenti varsayılanı değil, sizin kararınızla uyuşur. Birçok sağlayıcı arama ve eğitim tarayıcıları için ayrı belirteçler belgeler; örneğin Google, arama tarayıcılarının yanında Google-Extended’ı tanımlar.
• llms.txt: isteğe bağlı. En yararlı sayfalarınızın kısa bir Markdown dizini; özellikle dokümantasyon ağırlıklı sitelerde eklenmeye değer. llms.txt rehberi ne işe yarayıp yaramadığını açıklar.
• Varlık netliği: her yerde aynı işletme adı, açıklama, konum ve iletişim bilgileri; Organization yapılandırılmış verisiyle desteklenmiş.
• Yanıtlanabilirlik: gerçek müşteri sorularını doğrudan, üst kısımda ve görsel değil metin olarak yanıtlayan sayfalar.
• Prompt kapsamı: alıcıların bir asistana sorduğu soruların listesi ve her biri için sitenizde onu yanıtlayan sayfa.
• Kaynak sinyalleri: bir sayfanın alıntılanmasını ve atıf yapılmasını kolaylaştıran adı belli yazar veya kuruluş, tarihler ve kaynakçalar.

Bunlar kendi içeriğiniz üzerinde hazırlık kontrolleridir. Herhangi bir asistanın bugün sizi alıntılayıp alıntılamadığını göstermezler; bunun için ayrı bir soru-yanıt kaydı gerekir. Google, yapay zekâ özelliklerinin normal Arama uygunluğunun ötesinde ek bir şart taşımadığını belirtir; bu yüzden önce tarama erişimi ve net içerik gelir. Yapay zekâ görünürlüğü denetimi rehberi soru setinin nasıl kurulacağını gösterir.

Erişilebilirlik

• Metin alternatifleri: bilgilendirici her görselin anlamlı alt metni, dekoratif görsellerin boş alt metni vardır.
• Formlar: her alanın yalnızca yer tutucu metin değil, programatik bir etiketi vardır.
• Yapı: sıralı başlıklar, main ve nav gibi landmark’lar ve bir skip link.
• Adlar: her düğme ve bağlantının erişilebilir bir adı vardır; boş bağlantı yoktur.
• Dil: sayfa dilini lang özniteliğiyle bildirir.
• Manuel kontroller: yalnızca klavye kullanımı, görünür odak, renk kontrastı, yakınlaştırma ve yeniden akış ile ekran okuyucuyla bir geçiş.

W3C, araçların erişilebilirliğin tüm yönlerini otomatik kontrol edemediğini ve insan yargısının gerektiğini açıkça belirtir. Otomatik kontrol eksik etiketi bulur; etiketin anlamlı olup olmadığını ancak bir insan söyleyebilir. Erişilebilirlik denetimi rehberi, WCAG 2.2 temelinde manuel incelemeyi anlatır.

Performans

• Core Web Vitals: sayfa yüklemelerinin 75. yüzdelik diliminde Largest Contentful Paint en fazla 2,5 saniye, Interaction to Next Paint en fazla 200 milisaniye ve Cumulative Layout Shift 0,1 veya altı (web.dev).
• Önce saha verisi: sayfa veya site dahil edilecek kadar trafik alıyorsa, Chrome UX Report verisi gerçek Chrome kullanıcılarının önceki 28 günde yaşadığını gösterir; Lighthouse laboratuvar sonuçları nedeni bulmaya yardım eder.
• Önce mobil: ana sayfa, bir ürün veya hizmet sayfası ve ödeme ya da iletişim formu gibi önemli sayfaların mobil sürümünü test edin.
• Olağan nedenler: aşırı büyük bir hero görseli, işlemeyi engelleyen betikler ve yazı tipleri, boyutsuz görsellerden veya geç gelen bannerlardan kaynaklanan yerleşim kaymaları ve ağır üçüncü taraf etiketleri.

PageSpeed Insights belgeleri laboratuvar ve saha verisinin farklı olabileceğini belirtir; iyi bir laboratuvar puanı gerçek ziyaretçilerin iyi bir deneyim yaşadığı anlamına gelmez. Web sitesi performans denetimi rehberi, yavaş bir metriği ona yol açan öğeye nasıl bağlayacağınızı gösterir.

Entegrasyonlar

• Envanter: sayfadaki her analitik aracı, etiket yöneticisi, reklam pikseli, onay aracı ve site doğrulama etiketi ile her birinin sahibi.
• Kopyalar ve artıklar: aynı analitik etiketinin iki kopyası veya geçen yıl biten bir kampanyanın pikseli.
• Onay: gerektiği yerde bir onay aracı ve onayı bekleyen etiketler.
• Kişisel veri: etiketlerin okuduğu veri katmanında, URL’lerde veya sayfa başlıklarında e-posta adresi, telefon numarası ya da ad bulunmaması. Örneğin Google analitik yardımı site sahiplerinden URL’lerde, başlıklarda ve olaylarda kişisel olarak tanımlanabilir bilgiyi dışarıda tutmalarını ister.

Statik kontroller işaretlemenin neyi bildirdiğini gösterir. Bir etiketin gerçekten onayı bekleyip beklemediği veya bir tıklamadan sonra hangi olayların tetiklendiği, geliştirici araçları açık bir tarayıcı oturumu gerektirir. Web sitesi entegrasyon denetimi rehberi bu izlemeyi adım adım gösterir.

4. Yapay zekâ ile web sitesi nasıl denetlenir? Adım adım

Model Context Protocol (MCP), bir yapay zekâ uygulamasının diğer hizmetlerin araçlarını çağırması için yaygın bir yoldur. Bir denetim hizmeti bağlandığında, sohbet veya kodlama aracınızdaki ajan kontrolleri çalıştırabilir ve sonuçlarla doğrudan çalışabilir. İş akışı dokuz adımdır; ilk ikisi site başına bir kez yapılır, kalanlar her denetimde tekrarlanır.

1. Bağlanın. Denetim hizmetini yapay zekâ istemcinize MCP bağlantısı olarak ekleyin ve tarayıcı üzerinden giriş yapın. Hesap gerektiren uzak MCP sunucuları, MCP yetkilendirme şartnamesinde anlatıldığı gibi genellikle OAuth kullanır; yani erişimi bir giriş penceresinde onaylarsınız ve sohbete asla parola veya API anahtarı yapıştırmazsınız. Sitelemetry ChatGPT, Claude, Claude Code, Codex ve Cursor’da bu şekilde bağlanır; MCP bağlantı rehberi her istemci için adımları içerir.
2. Kapsamı ve yetkiyi belirleyin. Hangi sitelerin ve sayfaların kapsamda olduğuna karar verin ve yalnızca sahibi olduğunuz veya test etmek için yazılı izniniz bulunan siteleri denetleyin. Pasif kontroller herhangi bir ziyaretçinin görebildiğini okur; aktif güvenlik kontrolleri yoklama istekleri gönderir, bu yüzden yalnızca alan adının denetimini doğruladıktan sonra çalıştırılmalıdır. Kapsamı ajana sade sözlerle söyleyin: yalnızca üretim, şu üç URL, form gönderimi yok.
3. Denetimi çalıştırın. Tam bir denetim veya tek bir alan isteyin: “https://www.example.com için tam denetim çalıştır ve bulguları önem derecesine göre listele.” Uzun denetimler arka plan işi olarak çalışabilir; ajanın ikinci bir tarama başlatmak yerine sonucu beklemesine izin verin.
4. Kanıtı okuyun. Her bulgu bir önem derecesi, gözlenen kanıt, etki ve çözüm önerisiyle gelmelidir. Yüksek derecelendirilen her şey için ajandan kanıtı alıntılamasını isteyin ve bir iki bulguyu curl -sI veya dig ile kendiniz yeniden üretin. Yeniden üretebildiğiniz bulgu, güvenle düzeltebileceğiniz bulgudur.
5. Önceliklendirin. Önce önem derecesine, sonra maruziyete (sayfa herkese açık mı, giriş veya ödemeyi mi yönetiyor?), sonra emeğe göre sıralayın. Aynı sunucu yapılandırmasında ayarlanan birkaç başlık gibi tek düzeltmeyi paylaşan bulguları gruplayın ve ajana bu site için hangi bulguların önemli, hangilerinin burada az risk taşıdığını sorun.
6. Kodlama ajanına ajan için hazır bir düzeltme prompt’u verin. Seçilen bulguları kanıt, kısıtlar, kabul ölçütleri ve yeniden test adımlarıyla tek bir kesin değişiklik talebine dönüştürün (örnek aşağıda). Bunu deponuzda çalışan kodlama ajanına verin; depoya erişimi varsa aynı istemcinin ikisini de yapmasına izin verin.
7. Normal sürecinizle yayına alın. Diff’i inceleyin, staging’de test edin ve her değişiklikte olduğu gibi dağıtın. Denetim kod incelemesinin yerini almaz ve bir kodlama ajanı bir kişi onaylamadan dağıtım yapmamalıdır.
8. Doğrulamak için yeniden denetleyin. Dağıtımdan sonra aynı hedefte aynı kontrolü çalıştırın. Bir bulgu, ajan bir dosyayı düzenlediğini söylediğinde değil, yeni bir sonuç artık onu göstermediğinde kapanır.
9. İzleyin. Bir eklenti güncellemesi, yeni bir etiket veya süresi dolan bir sertifika ziyaretçiler fark etmeden önce ortaya çıksın diye denetimin tekrarlanmasını zamanlayın. Çoğu küçük site için haftalık uygundur; her gün dağıtım yapan siteler günlük çalıştırmalardan yarar görür.

MCP şartnamesi araç çağrılarını reddedebilen bir döngüdeki insanı önerir; OWASP ise bir ajanın görevinin gerektirdiğinden fazla işlevselliğe, izne veya özerkliğe sahip olması hâlinde zarar verici eylem riskini, yani aşırı yetkiyi başlı başına bir risk olarak sayar. Pratikte: denetim araçları okusun, kod değişikliklerini ve dağıtımları bir kişi onaylasın.

Bir kodlama ajanının tahmin yürütmeden uygulayabileceği düzeltme prompt’u şu biçimdedir (açıklayıcı örnek):

Fix: Strict-Transport-Security header missing
Target: https://www.example.com (all HTTPS responses)
Evidence: GET / over HTTPS returned 200 without a
Strict-Transport-Security header.
Constraints:
- Change only the header configuration of the web server or CDN.
- Use max-age=300 for now (first rollout stage); no preload.
- Do not change redirects, cookies or other headers.
Acceptance criteria:
- curl -sI https://www.example.com/ shows a
  Strict-Transport-Security header with max-age=300.
- The header is present on HTML, CSS and JavaScript responses.
Retest:
- Re-run the security audit for www.example.com and confirm
  the finding no longer appears.

Her bölümün bir görevi var. Kanıt, kodlama ajanına neyin gözlendiğini söyler; böylece sorunu yeniden keşfetmesi gerekmez. Kısıtlar değişikliği küçük tutar; HSTS’ye kısa bir max-age ile başlayıp kademeli artırmak, HSTS rehberinin anlattığı temkinli yoldur. Kabul ölçütleri herkesin çalıştırabileceği komutlardır ve yeniden test adımı, sorunu bulan aynı kontrolle döngüyü kapatır.

5. Yapay zekâ web sitesi denetim aracı nasıl değerlendirilir?

Web sitesi denetimi için en iyi yapay zekâ aracını aratırsanız uzun listeler bulursunuz. Doğru seçim sitenize bağlıdır; ancak yararlı bir yapay zekâ web sitesi denetim aracını tarama aracı eklenmiş bir sohbet botundan ayıran sorular her ürün için aynıdır.

Sonra güvenmeden önce her adayı kendi sitenizde test edin:

• İki kez çalıştırın: aynı sayfada, değişiklik yapmadan. Bulgular ve önem dereceleri eşleşmelidir.
• Üç bulguyu elle kontrol edin: güvenlik, SEO ve erişilebilirlikten birer tane; curl, dig veya sayfa kaynağıyla.
• Staging’e bilinen bir sorun yerleştirin: alt metni olmayan bir görsel veya yinelenen bir başlık gibi ve raporlanıp raporlanmadığına bakın.
• Bir bulguyu düzeltip yeniden denetleyin: bulgu kaybolmalı, ilgisiz hiçbir şey değişmemelidir.
• Sınırları okuyun: neyi kontrol etmediğini söyleyen bir araca, her şeyi kontrol ettiğini iddia edenden daha kolay güvenilir.

Bölüm 8, Sitelemetry’nin neleri kapsadığını, düzeltmeleri nasıl devrettiğini ve sınırlarının nerede olduğunu listeler.

6. Sık görülen tuzaklar ve nasıl kaçınılır?

Hepsinin ortak noktası aynıdır. Ajana, sunucuyu görmemiş hızlı ve akıcı bir meslektaş gibi davranın: ona kanıt verin, yetkilerini dar tutun ve sonucu canlı sitede kontrol edin.

7. Çalışılmış bir örnek: küçük bir klinik sitesi

Bir diş kliniği, çevrimiçi randevu formu olan bir WordPress sitesini www.example-clinic.com adresinde işletiyor. Ofis yöneticisi bir denetim hizmetini yapay zekâ asistanına bağlıyor, alan adını doğruluyor ve ana sayfa ile randevu sayfası için tam denetim istiyor. Sonuçlardan bazıları (açıklayıcı, gerçek veri değil):

Ajan ilk ikisinin neden önce geldiğini açıklıyor: yedek, yolu tahmin eden herkese veri açıyor ve izleme kodundaki adres, veri katmanını okuyan her üçüncü taraf etikete geçiyor. Yapay zekâ tarayıcı engelinin bilerek yapılıp yapılmadığını soruyor. Kimse karar vermemiş; bu yüzden bir düzeltme değil, sahibinin vereceği bir karar oluyor.

Yedek için düzeltme kod değil: dosyayı silmek, sunucuda başka kopyalar aramak ve onu hangi sürecin oluşturduğunu bulmak. Ardından erişim günlüklerinde önceki indirmelere bakın, yedeğin içerdiği parolaları veya anahtarları değiştirin ve hasta verisi açığa çıkmış olabilirse kliniğin veri ihlali prosedürünü izleyin. Form etiketleri için ajan, beş alanı ve bulundukları randevu sayfasını adlandıran, görsel tasarımın aynı kalması kısıtını ve ekran okuyucunun her alan için bir etiket okuması kabul ölçütünü içeren bir düzeltme prompt’u yazıyor. Geliştiricinin kodlama ajanı değişikliği yapıyor, geliştirici inceleyip dağıtıyor ve yeniden denetim bulgunun gittiğini gösteriyor. DMARC kaydı, DMARC devreye alma rehberinin anlattığı gibi raporlarla birlikte p=none ile başlayarak DNS’i yöneten kişiye gidiyor. Her madde aynı şekilde bitiyor: değiştirildi, dağıtıldı ve onu bulan denetimle yeniden kontrol edildi.

8. Bu iş akışını Sitelemetry ile çalıştırmak

Sitelemetry, bu rehberdeki iş akışı için geliştirilmiş bir yapay zekâ web sitesi denetim aracıdır:

• Altı alan. Enterprise planında 27’ye kadar modülle güvenlik: DNS, SPF ve DMARC, TLS, HTTPS duruşu, güvenlik başlıkları, CORS, açıkta kalan dosyalar, API ve gizli bilgi maruziyeti, subdomain takeover, tedarik zinciri, kimlik doğrulama yüzeyi, açık portlar, HTTP yöntemleri, WordPress ve daha fazlası. Google Search Console tıklamaları, TO, konum ve hızlı kazanımlar dahil teknik SEO. Yapay zekâ görünürlüğüne hazırlık, erişilebilirlik, PageSpeed Insights, Lighthouse ve CrUX saha verisiyle performans ve entegrasyonlar.
• Kanıt ve düzeltmeler. Bulgular önem derecesi, kanıt, etki ve çözüm önerisi taşır; her denetim kısıtlar, kabul ölçütleri ve yeniden test adımlarıyla ajan için hazır bir düzeltme prompt’u üretebilir.
• Yapay zekâ araçlarınızın içinde. ChatGPT, Claude, Claude Code, Codex ve Cursor’da OAuth girişli MCP üzerinden çalışır; MCP bağlantı rehberi nasıl bağlanacağınızı gösterir. OAuth girişi, erişimi bir tarayıcı penceresinde onaylamanız ve sohbete asla parola veya API anahtarı yapıştırmamanız demektir.
• Doğrulama ve izleme. Düzeltmeyi canlı sitede doğrulamak için yeniden denetleyin. Plana bağlı olarak izleme haftalık, günlük veya saatlik çalışır. Raporlar JSON veya PDF olarak dışa aktarılır; Enterprise’da beyaz etiketli raporlar vardır.
• Planlar. Starter $49/ay, Professional $149/ay ve Enterprise $249/ay; her planın neleri içerdiğini fiyatlandırma sayfası listeler.

Sınırları, bu rehberin sizden aramanızı istediği sınırlardır. Barındırılan denetimler hedefi değiştirmeden gözlemler ve aktif güvenlik kontrolleri yalnızca doğrulanmış hedeflerde çalışır. SEO, yapay zekâ görünürlüğü, erişilebilirlik ve entegrasyon kontrolleri JavaScript çalıştırmadan statik HTML okur. Yapay zekâ görünürlüğü içeriğin hazırlığını kontrol eder ve yapay zekâ asistanlarını sorgulamaz. Erişilebilirlik kontrolleri statiktir, WCAG 2.2 odaklıdır ve tam manuel değerlendirme değildir; güvenlik denetimi de sızma testi değildir. Statik analizin göremediği şeyler için 3. bölümdeki manuel kontrolleri sürdürün.