Kısa cevap
Mobil öncelikli dizine ekleme tamamlandı. Temmuz 2024'ten bu yana Google, dizine ekleme ve sıralama için sitenizin yalnızca mobil sürümünü kullanıyor. İçerik, yapılandırılmış veri veya dahili bağlantılar masaüstünde bulunup mobilde yoksa, Google bunları görmez. 2026'da çoğu site sahibinin henüz ele almadığı üç yeni sonuç ortaya çıktı: INP, FID'in yerini aldı ve bir Core Web Vital haline geldi, AI Overviews mobilde işlenen içerikten yararlanıyor ve Mart 2026 Core Update, mobil sayfa deneyiminin sıralama ağırlığını artırdı.
Aşağıda eksiksiz bir denetim iş akışı ve çoğu kontrolü sizin için çalıştıran kopyala-yapıştır bir Codex skill'i bulacaksınız.
"Yalnızca mobil" 2026'da gerçekte ne anlama geliyor
Google, siteleri mobil öncelikli dizine eklemeye 2018'de başladı. Geçiş altı yıldan fazla sürdü. Temmuz 2024 itibarıyla, masaüstünde erişilebilir içeriğe sahip olup mobil eşdeğeri olmayan her site bu içeriği Google dizininden kaybetti. Vazgeçme seçeneği veya masaüstü yedeği yoktur.
Ancak hikaye burada bitmedi. 2025-2026'daki üç değişiklik, "mobil öncelikli"nin sitenizden ne talep ettiğini değiştirdi:
Değişim 1: INP, FID'in yerini aldı — ve çoğu mobil site başarısız oluyor
Mart 2024'te Google, First Input Delay (FID) yerine Interaction to Next Paint (INP) ölçütünü bir Core Web Vital olarak getirdi. INP, yalnızca ilk etkileşimi değil, tüm sayfa oturumu boyunca sayfanızın dokunmalara, tıklamalara ve tuş basışlarına ne kadar hızlı yanıt verdiğini ölçer.
Net rakam: FID'i geçen sitelerin yaklaşık %40'ı INP'yi geçemiyor. Mobilde, sitelerin yalnızca yaklaşık %65'i 200 milisaniye veya daha az olan "iyi" eşiğini karşılıyor. Mart 2026 Core Update, Core Web Vitals'ın sıralama ağırlığını daha da artırdı. Mobil INP'de başarısız olan siteler artık daha hızlı rakiplere pozisyon kaybediyor.
Değişim 2: AI Overviews ve yapay zeka tarayıcıları mobil içeriğinizi okuyor
Google'ın AI Overviews özelliği, 2026 ortası itibarıyla aramaların yaklaşık %47'sinde görünüyor. Google'ın yapay zeka sistemleri yanıt üretirken, normal aramanın kullandığı aynı mobil dizine eklenmiş içerikten yararlanır. Üçüncü taraf yapay zeka tarayıcıları (GPTBot, ClaudeBot, PerplexityBot) da mobilde işlenen sayfalarınıza erişir.
Mobil sürümünüzde yapılandırılmış veri, net başlıklar veya kritik metinler eksikse, masaüstü sürümü bu içeriğe sahip olsa bile yapay zeka sistemleri size atıfta bulunamaz.
Değişim 3: İçerik eşliği boşlukları artık ölçülebilir sıralama etkisine sahip
2026'da, tutarsız mobil ve masaüstü içeriğe sahip siteler, tam içerik eşliğine sahip sitelere kıyasla ortalama %31,2 daha düşük organik arama görünürlüğü gösteriyor. Mobilde en sık eksik olan öğeler: gizli sekme içeriği, kenar çubuğu bağlantıları, yapılandırılmış veri işaretlemesi, görsel alt metni ve dahili navigasyon bağlantıları.
İçerik öğesi | Mobilde eksik olan site yüzdesi |
|---|---|
Yapılandırılmış veri (JSON-LD) | %23 |
Dahili bağlantılar (menüler, breadcrumbs) | %18 |
Görsel alt metni | %27 |
Sekme/akordeonlardaki tam metin | %15 |
Meta robots etiketleri | %9 |
Sitenizin testi geçip geçmediğini kontrol etme (2 dakikalık sürüm)
Tam bir denetim yapmadan önce şu üç sinyali kontrol edin. Her biri bir dakikadan az sürer ve daha derine inmeniz gerekip gerekmediğini gösterir.
Sinyal 1: Google Search Console dizine ekleme durumu
Google Search Console'u açın → Ayarlar (dişli simgesi, sol alt) → "Hakkında" bölümüne bakın. "Dizine ekleme tarayıcısı" altında "Googlebot smartphone" yazıyorsa, siteniz mobil öncelikli dizine eklemededir. Bu, 2026'da neredeyse her site için geçerlidir — yine de doğrulayın.
Ayrıca şunu kontrol edin: URL Denetleme aracı → önemli bir sayfanın URL'sini girin → "Tarama"yı genişletin → "Googlebot smartphone olarak tarandı"yı doğrulayın. Google'ın sağladığı ekran görüntüsüne bakın — bu tam olarak Google'ın gördüğüdür. Anahtar içerik o ekran görüntüsünde eksikse, dizinde de eksiktir.
Sinyal 2: Gerçek mobil verilerle PageSpeed Insights
PageSpeed Insights adresine gidin, URL'nizi girin ve "Gerçek kullanıcılarınızın ne deneyimlediğini keşfedin" bölümüne bakın. Bu, Chrome User Experience Report (CrUX) alan verisidir — Google'ın sıralama için kullandığı verinin aynısıdır.
Mobil raporu INP (Interaction to Next Paint) için turuncu veya kırmızı gösteriyorsa, aktif bir sıralama yükümlülüğünüz var demektir. Yeşil için eşik 200 milisaniyenin altıdır.
Sinyal 3: Chrome DevTools mobil görüntü alanı hızlı kontrolü
Chrome DevTools'u açın (F12 veya Cmd+Option+I), cihaz araç çubuğu simgesine tıklayın (Ctrl+Shift+M) ve "Pixel 7" gibi bir mobil cihaz ön ayarı seçin. Sayfayı yeniden yükleyin. Şunları tarayın:
- Yatay kaydırma gerektiren metinler
- Dokunmak için çok küçük düğmeler veya bağlantılar (48×48 CSS pikselin altında)
- HTML kaynağında olmayan "devamını oku" geçişlerinin arkasına gizlenmiş içerik
- Ekranın çoğunu kaplayan pop-up'lar
Bunların her biri, arkalarındaki içerik veya bağlantılar masaüstü kullanıcılarının gördüğünden farklıysa bir mobil dizine ekleme sorunudur.
30 dakikalık mobil öncelikli denetim (Codex ile)
Bugün tam bir mobil öncelikli denetim yapmanın en hızlı yolu, bir yapay zeka kodlama ajanına (Claude Code veya Codex) yapılandırılmış bir görev vermektir. Ajan, sitenizin kaynağını okur, kuralları kontrol eder ve öncelikli bir düzeltme listesi üretir.
Aşağıda eksiksiz bir skill dosyası bulunmaktadır. Projenize kopyalayın, ardından ajanınızdan çalıştırmasını isteyin.
Adım 1: Skill dosyasını oluşturun
.claude/skills/mobile-first-audit/SKILL.md (Claude Code için) veya .codex/skills/mobile-first-audit/SKILL.md (Codex için) konumunda bir dosya oluşturun:
name: mobile-first-audit
description: Audit a URL or list of URLs for mobile-first indexing readiness. Checks content parity, Core Web Vitals, structured data, mobile UX, and AI crawler access.
# Mobile-First Indexing Audit
Run a structured mobile-first indexing audit on one or more URLs. The agent must report findings, not make edits, unless the user explicitly approves a fix plan.
## Input
The user provides one or more page URLs. If they provide a sitemap URL or a list of more than 5 URLs, sample 5 URLs that represent different page types (homepage, product page, article, category page, landing page).
## Audit Checklist
For each URL, check and report on all eleven items below. Mark each item as `PASS`, `WARN`, or `FAIL`. Include the evidence for every WARN and FAIL.
### 1. Viewport Meta Tag
Check that `<meta name="viewport" content="width=device-width, initial-scale=1">` is present in the HTML `<head>`. If missing or if it sets a fixed width or disables user-scaling without a valid accessibility reason, mark FAIL.
### 2. Content Parity (Text)
Fetch the page with a desktop user-agent and a mobile user-agent (Googlebot Smartphone). Compare the visible text content. If any text block over 50 words exists on desktop but not in the mobile HTML source, mark WARN. If important body text, headings, or product descriptions are missing, mark FAIL.
### 3. Structured Data Parity
Extract all JSON-LD blocks from both desktop and mobile fetches. If any schema type present on desktop is missing from mobile, mark FAIL. If schema content differs between versions, mark WARN.
### 4. Meta Tags Parity
Compare title, meta description, canonical, robots, and hreflang tags between desktop and mobile versions. Any difference is a WARN. A missing canonical or conflicting robots tag is FAIL.
### 5. Internal Links and Navigation
Count the number of internal `<a href>` links in the desktop and mobile HTML. If the mobile version has 20%+ fewer internal links, mark WARN. If breadcrumb links, category navigation, or footer links present on desktop are missing from mobile, mark FAIL.
### 6. Image Alt Text
Count images in the mobile HTML. Report the number and percentage missing alt attributes. If more than 10% of images lack alt text, mark WARN. If hero images or product images lack alt text, mark FAIL.
### 7. Core Web Vitals (Field Data)
Look up the URL's Chrome UX Report (CrUX) field data. If accessible via PageSpeed Insights API or a direct CrUX lookup, report LCP, INP, and CLS for mobile. Mark thresholds: LCP > 2.5s = WARN, > 4.0s = FAIL. INP > 200ms = WARN, > 500ms = FAIL. CLS > 0.1 = WARN, > 0.25 = FAIL.
If CrUX data is unavailable (insufficient traffic), note this and use lab data from Lighthouse as a fallback with the caveat that lab data is not used for ranking.
### 8. Tap Target Sizing
Inspect CSS for buttons, links, and interactive elements. Flag any element whose computed height or width is under 48 CSS pixels. Flag adjacent interactive elements with less than 8px spacing. Mark WARN for 1-3 violations, FAIL for 4+.
### 9. Font Sizing
Check that body text uses a computed font-size of at least 16px. Flag any text below 12px. Mark WARN if body text is 14-15px, FAIL if below 12px.
### 10. Interstitials and Pop-ups
Visually inspect the mobile viewport. If a pop-up, banner, or interstitial covers more than 30% of the initial viewport and is not legally required (cookie consent, age verification), mark WARN. If the pop-up prevents scrolling or reading content, mark FAIL.
### 11. AI Crawler Access
Check robots.txt for rules blocking GPTBot, ClaudeBot, PerplexityBot, Google-Extended, or OAI-SearchBot. If any AI crawler is blocked, note that as a deliberate choice. If AI crawlers are allowed but the page has no structured data, mark WARN (AI systems rely on structured data for citations).
## Output Format
Produce a Markdown report:
```markdown
# Mobile-First Audit Report
**Date:** YYYY-MM-DD
**URLs audited:** N
**Overall score:** X/11 PASS items per URL average
## Summary
| Check | URL 1 | URL 2 | URL 3 | URL 4 | URL 5 |
|-------|-------|-------|-------|-------|-------|
| 1. Viewport | PASS | PASS | ... | ... | ... |
| ... | ... | ... | ... | ... | ... |
## Detailed Findings
### URL 1: [url]
**FAIL items (must fix):**
- [Item name]: [evidence and fix instructions]
**WARN items (should fix):**
- [Item name]: [evidence and fix instructions]
**PASS items:** [list]
### Priority Fix Queue
1. [Highest priority fix] — affects indexing directly
2. [Next fix] — affects ranking
3. ...Rules
- Do not make any changes to the site without explicit user approval of a fix plan.
- If you cannot check an item because the page requires authentication, note it as "NOT CHECKED — authentication required."
- For CrUX data, use the official Chrome UX Report API or PageSpeed Insights API if available. If neither is accessible, use Lighthouse mobile audit as a fallback.
- Never fabricate metrics, scores, or check results. If data is unavailable, say so.
- Do not access or expose API keys, cookies, tokens, or credentials.
### Adım 2: Denetimi çalıştırın
Ajanınıza şunu sorun: **"Run the mobile-first audit skill on [URL'niz]"** ve kontrol etmek istediğiniz URL'yi yapıştırın. Ajan, 11 kontrolün her biri için PASS/WARN/FAIL içeren bir rapor ve bir öncelikli düzeltme kuyruğu üretecektir.
Aynı anda birden fazla sayfayı kontrol etmek isterseniz, bir liste verin: **"Run the mobile-first audit on these 5 URLs: [URL1, URL2, URL3, URL4, URL5]"**.
## Düzeltme #1: İçerik eşliği — ilk neyi kontrol etmeli
İçerik eşliği en yüksek etkili düzeltmedir çünkü Google'ın neyi dizine ekleyebileceğini doğrudan belirler. İşte en sık bozulanlar ve her birinin nasıl düzeltileceği.
### Sekmelerde ve akordeonlarda gizli içerik
Birçok site mobilde uzun içeriği sekmelere, akordeonlara veya "devamını oku" geçişlerine daraltır. İçerik HTML kaynağında olduğu sürece bu sorun değildir — Google artık UX nedenleriyle gizlenen içeriği düşük değerli saymaz. Ancak sekmeleriniz kullanıcı dokunuşundan sonra JavaScript ile içerik yüklüyorsa, Googlebot bu dokunuşu tetiklemez. İçerik görünmezdir.
**Nasıl kontrol edilir:** Chrome DevTools'da, gizli içeriğe sağ tıklayın ve "İncele"yi seçin. Elements panelinde metni görüyorsanız, DOM'dadır ve Google görebilir. Elements paneli, sekmeye tıklayana kadar boş bir kapsayıcı gösteriyorsa, içerik dinamik olarak yükleniyordur ve Google bunu kaçırır.
**Nasıl düzeltilir:** Gizli içeriği sunucu tarafında HTML'ye işleyin. Göster/gizle davranışı için JavaScript içerik enjeksiyonu yerine CSS (`display: none` veya görünürlük geçişleri) kullanın.
### Mobilde eksik yapılandırılmış veri
Yapılandırılmış veri (JSON-LD), mobil HTML'de bulunmalıdır. Mobil temanız veya AMP sürümünüz farklı bir şablon kullanıyorsa bunu gözden kaçırmak kolaydır.
**Nasıl kontrol edilir:** Mobil sayfayı açın, kaynağı görüntüleyin (`Cmd+Option+U`) ve `application/ld+json` için arama yapın. Ardından aynısını masaüstünde yapın. Her ikisinde de aynı JSON-LD blokları görünmelidir.
**Nasıl düzeltilir:** Yapılandırılmış verinizin sunucu tarafında işlendiğinden ve hem mobil hem masaüstü için aynı HTML yanıtına dahil edildiğinden emin olun. Bir CMS kullanıyorsanız, şema eklentinizin veya temanızın cihaz algılamaya dayalı olarak koşullu script yüklemediğini kontrol edin.
### Mobil menülerden çıkarılan navigasyon bağlantıları
Mobil menüler genellikle masaüstü navigasyonunda bulunan bağlantıları basitleştirir veya kaldırır: breadcrumbs, kategori bağlantıları, footer sütunları, kenar çubuğu bağlantıları. Google, site yapısını anlamak ve PageRank dağıtmak için dahili bağlantıları kullanır. Mobilde eksik olan bağlantılar, Google'ın grafında da eksiktir.
**Nasıl kontrol edilir:** Masaüstü kaynağındaki ve mobil kaynağındaki `<a href>` etiketlerini sayın. Duyarlı bir tasarımda sayılar yaklaşık olarak eşit olmalıdır. Mobil sayısı %30+ daha düşükse, hangi bağlantıların kaybolduğunu araştırın.
**Nasıl düzeltilir:** Eksik navigasyon bağlantılarını mobil menüye, hamburger menüye veya footer'a ekleyin. Önemli kategori sayfalarına, kilit makalelere ve üst sayfalara giden bağlantılara öncelik verin.
## Düzeltme #2: INP — çoğu sitenin görmezden geldiği mobil hız metriği
Interaction to Next Paint (INP), bir kullanıcı dokunduktan, tıkladıktan veya tuşa bastıktan sonra sayfanın görsel olarak yanıt vermesinin ne kadar sürdüğünü ölçer. Eşik **200 milisaniye veya daha azdır**.
Yalnızca ilk etkileşimin giriş gecikmesini ölçen FID'in aksine, INP her etkileşimi ölçer ve **en kötü** olanı raporlar. Bu, onu çok daha katı bir test haline getirir.
### Mobil INP'yi ne öldürür
Sırasıyla en yaygın nedenler:
1. **Ana iş parçacığında çalışan ağır JavaScript.** Büyük bundle'lar, optimize edilmemiş React/Vue bileşenleri ve izleme scriptleri tarayıcının dokunmalara yanıt vermesini engeller.
2. **UI'yi güncellemeden önce çok fazla iş yapan tıklama işleyicileri.** Bir dokunuş, görsel geri bildirim göstermeden önce bir API çağrısı, state güncellemesi ve DOM değişikliği tetikliyorsa, INP zarar görür.
3. **Üçüncü taraf etiketler.** Analitik, sohbet widget'ları, reklam ağları ve kişiselleştirme scriptleri — özellikle birden fazla etiket ana iş parçacığı için rekabet ettiğinde.
### INP nasıl teşhis edilir
1. [PageSpeed Insights](https://pagespeed.google.com/) adresini açın, URL'nizi girin, "Gerçek kullanıcılarınızın ne deneyimlediğini keşfedin" bölümüne kaydırın. "Mobil" altındaki INP değeri Google'ın kullandığıdır.
2. Chrome DevTools'da **Performance** panelini açın, kaydı başlatın, sayfayla etkileşime geçin (düğmelere dokunun, menüleri açın, girişlere yazın), ardından kaydı durdurun. Uzun görevleri arayın (kırmızı ile işaretli, 200ms+). Bunlar sizin INP sorunlarınızdır.
3. Ayrıca yapay zeka ajanınıza şunu sorabilirsiniz: **"[URL] için Core Web Vitals'ı kontrol et ve bana özellikle mobilde INP'yi neyin kötü etkilediğini söyle. Öncelik sırasına göre ilk 3 düzeltmeyi ver."**
### INP nasıl düzeltilir (öncelik sırası)
```text
Öncelik 1: Kritik olmayan üçüncü taraf scriptleri erteleyin veya geciktirin.
→ Sohbet widget'larını, analitiği ve reklam etiketlerini sayfa etkileşimli hale geldikten sonra yükleyin.
→ <script defer> kullanın veya sayfa yüklendikten 3-5 saniye sonra yükleyin.
Öncelik 2: Uzun JavaScript görevlerini parçalayın.
→ Rota bazında code-split yapın. Ekranın altındaki bileşenleri lazy-load edin.
→ Ağır hesaplamaları requestIdleCallback() veya bir Web Worker'a taşıyın.
Öncelik 3: Tıklama işleyicilerinin UI'yi hemen güncellemesini sağlayın.
→ İlk 50ms içinde bir yükleme durumu, spinner veya devre dışı düğme gösterin.
→ Asıl işi (API çağrısı, state güncellemesi) görsel yanıttan sonra çalıştırın.Düzeltme #3: Yapay zeka tarayıcı hazırlığı (2026 katmanı)
Mobil öncelikli dizine eklemenin artık bir yapay zeka katmanı var. Google'ın AI Overviews'u veya üçüncü taraf yapay zeka sistemleri bir soruyu yanıtladığında, aynı mobil dizine eklenmiş içerikten yararlanırlar. Mobil sayfalarınız, yapay zeka sistemlerinin aradığı sinyalleri kaçırıyorsa, atıf alma fırsatını kaybedersiniz.
Yapay zeka sistemlerinin mobil sayfalarınızdan ihtiyaç duydukları
Sinyal | Neden önemli | Hızlı kontrol |
|---|---|---|
Yapılandırılmış veri (JSON-LD) | Yapay zeka sistemlerinin varlıkları, ürünleri, makaleleri, SSS'leri anlamasına yardımcı olur | Kaynağı görüntüle → |
Net başlık hiyerarşisi | Yapay zeka çıkarıcıları sayfa yapısını ayrıştırmak için H1-H4 kullanır | Sayfanızı tarayın: her bölümün açıklayıcı bir başlığı var mı? |
Kısa yanıt blokları | AI Overviews, üste yakın 2-4 cümlelik yanıtları tercih eder | Sayfanız ana soruyu ilk 200 kelimede yanıtlıyor mu? |
Yapay zeka tarayıcıları için robots.txt erişimi | Engellenirse, yapay zeka sistemleri içeriğinizi getiremez | robots.txt'de |
llms.txt dosyası | Yapay zeka sistemlerinin kilit içeriğinizi verimli şekilde keşfetmesine yardımcı olur |
|
Ajanınız için hızlı yapay zeka hazırlık komutu
"Check [URL] for AI search readiness. Tell me: (1) is JSON-LD structured data present and valid? (2) is there a clear answer to the page's main question in the first 200 words? (3) are AI crawlers allowed in robots.txt? (4) does llms.txt exist at the root? Give me a PASS/FAIL for each and tell me what to fix first."Yeni başlayanlar için eksiksiz mobil öncelikli denetim komutları
İşte Claude Code veya Codex'e hemen kopyalayabileceğiniz bir dizi komut. Her komut belirli bir işi yapar — ajanın açık olması ve projenize veya bir URL'ye yönlendirilmiş olması dışında yapılandırma gerekmez.
Komut 1: Tek sayfa mobil denetimi
Run a mobile-first indexing audit on [SİZİN URL'NİZ].
Check these 8 things and report PASS or FAIL for each with the evidence:
1. Viewport meta tag is correct
2. All body text visible on desktop is also in the mobile HTML source
3. JSON-LD structured data is the same on desktop and mobile
4. Title tag, meta description, and canonical are identical across desktop and mobile
5. Internal link count is roughly equal (not 20%+ fewer on mobile)
6. Images have alt text
7. Mobile Core Web Vitals (LCP, INP, CLS) from CrUX field data if available
8. AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) are not blocked in robots.txt
For each FAIL, give me the exact fix in one sentence.Komut 2: Sayfa türleri arasında toplu denetim
I need to audit mobile-first readiness across different page types on my site. Here are 5 URLs, each representing a different template:
1. [ANA SAYFA URL'Sİ]
2. [ÜRÜN VEYA HİZMET SAYFASI URL'Sİ]
3. [BLOG YAZISI VEYA MAKALE URL'Sİ]
4. [KATEGORİ VEYA KOLEKSİYON SAYFASI URL'Sİ]
5. [HAKKINDA VEYA İLETİŞİM SAYFASI URL'Sİ]
For each URL, check: viewport meta tag, content parity (text + structured data), meta tags consistency, internal links, image alt coverage, and mobile font/tap-target sizing.
Then produce a single table with all 5 URLs as columns and each check as a row. Color-code PASS green, WARN yellow, FAIL red (use emoji 🟢 🟡 🔴 if colors are not supported). Below the table, list the top 3 fixes across all pages in priority order.Komut 3: İçerik eşliği derinlemesine inceleme
Fetch [URL] with both a desktop user-agent and the Googlebot Smartphone user-agent (Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)).
Compare the two versions and report any differences in:
- Visible text content (highlight blocks missing from mobile)
- Structured data (JSON-LD blocks)
- Meta tags (title, description, canonical, robots, hreflang)
- Internal link count and which sections lost links
- Image alt attributes
Do not make any edits. Just produce a diff report.Komut 4: INP teşhisi ve düzeltme planı
Analyze [URL] for Interaction to Next Paint (INP) issues on mobile.
1. Check if CrUX field data is available and report the current mobile INP value.
2. If CrUX data is unavailable, run a Lighthouse mobile audit and report the Total Blocking Time (TBT) as a proxy indicator.
3. Identify the top 3 JavaScript tasks blocking the main thread during page load and after user interaction.
4. For each problem, give me: the specific file or script causing it, the impact on INP, and the one-line fix.
Format the output as a table: Problem | Source | Impact | Fix.Komut 5: Yapay zeka tarayıcı + yapılandırılmış veri denetimi
Check [URL] for AI search and AI crawler readiness:
1. Crawl robots.txt at the domain root. List all rules that mention these user-agents: GPTBot, ClaudeBot, PerplexityBot, Google-Extended, OAI-SearchBot, Amazonbot, Bytespider. If any are blocked, flag it.
2. Extract all JSON-LD blocks from the page. Validate each against Schema.org types. Report which types are present and whether they are complete (all required properties filled).
3. Check if /llms.txt exists at the domain root. If it does, report its content summary. If it does not, note that as a missing AI discovery asset.
4. Check if the page has a clear, self-contained answer (2-4 sentences) to its main topic within the first 200 words of body text.
5. Score the page on AI readiness: 0-100. Deduct points for: missing structured data (-30), blocked AI crawlers (-20 per crawler), no llms.txt (-15), no clear answer block (-20), headings not descriptive (-15).SSS
S: Hala ayrı bir mobil site (m.example.com) kullanabilir miyim? Teknik olarak evet, ancak Google duyarlı tasarımı önerir. Ayrı mobil URL'ler karmaşıklık ekler: iki URL seti arasında aynı içeriği, canonical etiketlerini ve hreflang'i korumanız gerekir. Herhangi bir şey senkronizasyondan çıkarsa, Google en son taradığı sürümü dizine ekler. Duyarlı tasarım bu riski tamamen ortadan kaldırır.
S: Sitem yalnızca masaüstü ise — hiç mobil sürümü yoksa ne olur? Googlebot Smartphone içeriğinize erişemez ve işleyemezse, bu içerik dizine eklenmez. Nokta. 2026'da yalnızca masaüstü bir site, Google için etkili şekilde görünmezdir. Bu durumdaysanız, duyarlı bir temaya geçmek en yüksek öncelikli görevinizdir.
S: Tablet boyutları hakkında endişelenmem gerekiyor mu? Googlebot bir akıllı telefon olarak tarama yapar, tablet olarak değil. Akıllı telefon görüntü alanına odaklanın. Bununla birlikte, tablet kullanıcıları gerçek kullanıcılardır — duyarlı tasarımınızın ara genişliklerde (768-1024px) bozulmadığından emin olun.
S: Sitemin mobil öncelikli geçişi geçip geçmediğini nasıl anlarım? Google Search Console'u açın → Ayarlar → "Dizine ekleme tarayıcısı: Googlebot smartphone" için "Hakkında" bölümünü kontrol edin. Bunu yazıyorsa, mobil öncelikli dizine eklemedesiniz. Artık neredeyse her site böyledir.
S: Google hala herhangi bir şey için sitemi masaüstü user-agent ile tarıyor mu? Evet. Google, belirli kontroller (ilişki doğrulama, bazı yapılandırılmış veri yeniden işleme) için zaman zaman masaüstü user-agent ile tarama yapar. Günlüklerinizde masaüstü Googlebot görürseniz panik yapmayın. Bu ziyaretler, sitenizin masaüstü öncelikli dizine eklemede olduğu anlamına gelmez.
S: Mobil öncelikli sorunları düzeltmek AI Overviews görünürlüğümü artırır mı? Mobil öncelikli dizine ekleme onarımları temeli iyileştirir. Mobil içeriğiniz, yapılandırılmış veriniz ve sayfa hızınız sağlamsa, içeriğiniz atıf almaya uygundur — ancak Google'ın yapay zeka sistemleri, alaka düzeyi, otorite ve yanıt kalitesine göre neye atıfta bulunacağını seçer. Mobil öncelikli sorunları düzeltmek bir engeli kaldırır; yapay zeka dahil edilmeyi garanti etmez.
Yazar: Julian Mercer, Auspia'da 14 Yıllık Teknik SEO Uygulayıcısı. Julian, taranabilirlik, işleme, şema, site mimarisi ve içeriğin arama motorları ve yapay zeka sistemleri tarafından keşfedilebilir olmasını sağlayan teknik temeller hakkında yazmaktadır.
