Jawapan ringkas
Pengindeksan mobile-first telah selesai. Sejak Julai 2024, Google hanya menggunakan versi mudah alih laman anda untuk pengindeksan dan penarafan. Jika kandungan, data berstruktur, atau pautan dalaman wujud pada desktop tetapi tidak pada mudah alih, Google tidak melihatnya. Pada tahun 2026, ini mempunyai tiga akibat baharu yang kebanyakan pemilik laman masih belum tangani: INP menggantikan FID sebagai Core Web Vital, AI Overviews menarik daripada kandungan yang dipaparkan pada mudah alih, dan Kemas Kini Mac 2026 meningkatkan berat penarafan pengalaman halaman mudah alih.
Di bawah, anda akan menemui aliran kerja audit yang lengkap — dan kemahiran Codex salin-tampal yang menjalankan kebanyakan semakan untuk anda.
Apa maksud "hanya mudah alih" sebenarnya pada tahun 2026
Google mula memindahkan laman ke pengindeksan mobile-first pada tahun 2018. Peralihan ini mengambil masa lebih enam tahun. Mulai Julai 2024, setiap laman yang masih mempunyai kandungan boleh diakses desktop tanpa setara mudah alih kehilangan kandungan tersebut daripada indeks Google. Tiada pilihan keluar dan tiada sandaran desktop sahaja.
Tetapi cerita tidak berakhir di situ. Tiga perubahan dalam tempoh 2025–2026 mengubah apa yang dituntut "mobile-first" daripada laman anda:
Perubahan 1: INP menggantikan FID — dan kebanyakan laman mudah alih gagal
Pada Mac 2024, Google menggantikan First Input Delay (FID) dengan Interaction to Next Paint (INP) sebagai Core Web Vital. INP mengukur betapa pantas halaman anda bertindak balas terhadap ketukan, klik dan tekan kekunci sepanjang keseluruhan sesi halaman, bukan hanya interaksi pertama.
Angka sebenar: kira-kira 40% laman yang lulus FID tidak lulus INP. Pada mudah alih, hanya kira-kira 65% laman memenuhi ambang "baik" iaitu 200 milisaat atau kurang. Kemas Kini Mac 2026 meningkatkan lagi berat penarafan Core Web Vitals. Laman yang gagal INP mudah alih kini kehilangan kedudukan kepada pesaing yang lebih pantas.
Perubahan 2: AI Overviews dan perangkak AI membaca kandungan mudah alih anda
AI Overviews Google muncul dalam kira-kira 47% carian setakat pertengahan 2026. Apabila sistem AI Google menjana jawapan, mereka menarik daripada kandungan diindeks mudah alih yang sama yang digunakan carian biasa. Perangkak AI pihak ketiga (GPTBot, ClaudeBot, PerplexityBot) juga mengakses halaman mudah alih anda.
Jika versi mudah alih anda kekurangan data berstruktur, tajuk yang jelas, atau teks kritikal, sistem AI tidak boleh memetik anda — walaupun versi desktop mempunyai kandungan tersebut.
Perubahan 3: Jurang pariti kandungan kini mempunyai kesan penarafan yang boleh diukur
Pada tahun 2026, laman dengan kandungan mudah alih dan desktop yang tidak konsisten menunjukkan 31.2% pendedahan carian organik yang lebih rendah secara purata berbanding laman dengan pariti kandungan penuh. Elemen yang paling kerap hilang pada mudah alih: kandungan tab tersembunyi, pautan sidebar, penanda data berstruktur, teks alt imej, dan pautan navigasi dalaman.
Elemen kandungan | % laman yang kekurangannya pada mudah alih |
|---|---|
Data berstruktur (JSON-LD) | 23% |
Pautan dalaman (menu, breadcrumbs) | 18% |
Teks alt imej | 27% |
Teks penuh dalam tab/akordion | 15% |
Tag meta robots | 9% |
Cara memeriksa sama ada laman anda lulus (versi 2 minit)
Sebelum menjalankan audit penuh, periksa tiga isyarat ini. Setiap satu mengambil masa kurang dari seminit dan memberitahu anda sama ada perlu menggali lebih dalam.
Isyarat 1: Status pengindeksan Google Search Console
Buka Google Search Console → klik Settings (ikon gear, bahagian bawah kiri) → lihat di bawah bahagian "About". Jika ia menyatakan "Googlebot smartphone" di bawah "Indexing crawler", laman anda menggunakan pengindeksan mobile-first. Ini benar untuk hampir setiap laman pada tahun 2026 — tetapi sahkan ia.
Juga periksa: Alat Pemeriksaan URL → masukkan mana-mana halaman penting → kembangkan "Crawl" → sahkan "Crawled as: Googlebot smartphone." Lihat tangkapan skrin yang disediakan Google — inilah yang sebenarnya dilihat Google. Jika kandungan utama hilang dari tangkapan skrin tersebut, ia hilang dari indeks.
Isyarat 2: PageSpeed Insights dengan data mudah alih sebenar
Pergi ke PageSpeed Insights, masukkan URL anda, dan lihat bahagian "Discover what your real users are experiencing". Ini ialah data lapangan Chrome User Experience Report (CrUX) — data yang sama digunakan Google untuk penarafan.
Jika laporan mudah alih menunjukkan oren atau merah untuk INP (Interaction to Next Paint), anda mempunyai liabiliti penarafan aktif. Ambangnya ialah di bawah 200 milisaat untuk hijau.
Isyarat 3: Semakan pantas viewport mudah alih Chrome DevTools
Buka Chrome DevTools (F12 atau Cmd+Option+I), klik ikon bar alat peranti (Ctrl+Shift+M), dan pilih pratetap peranti mudah alih seperti "Pixel 7." Muat semula halaman. Imbas untuk:
- Teks yang memerlukan skrol mendatar
- Butang atau pautan terlalu kecil untuk diketuk (di bawah 48×48 piksel CSS)
- Kandungan tersembunyi di sebalik togol "baca lagi" yang tiada dalam sumber HTML
- Pop timbul yang meliputi kebanyakan skrin
Setiap satu ini adalah masalah pengindeksan mudah alih jika kandungan atau pautan di belakangnya berbeza daripada apa yang dilihat pengguna desktop.
Audit mobile-first 30 minit (dengan Codex)
Cara terpantas untuk menjalankan audit mobile-first penuh hari ini ialah memberi ejen pengekodan AI — Claude Code atau Codex — tugas berstruktur. Ejen membaca sumber laman anda, menyemak peraturan, dan menghasilkan senarai pembaikan berkeutamaan.
Di bawah ialah fail kemahiran lengkap. Salin ke dalam projek anda, kemudian minta ejen anda menjalankannya.
Langkah 1: Cipta fail kemahiran
Cipta fail di .claude/skills/mobile-first-audit/SKILL.md (untuk Claude Code) atau .codex/skills/mobile-first-audit/SKILL.md (untuk Codex):
name: mobile-first-audit
description: Audit URL atau senarai URL untuk kesediaan pengindeksan mobile-first. Menyemak pariti kandungan, Core Web Vitals, data berstruktur, UX mudah alih, dan akses perangkak AI.
# Audit Pengindeksan Mobile-First
Jalankan audit pengindeksan mobile-first berstruktur pada satu atau lebih URL. Ejen mesti melaporkan penemuan, bukan membuat suntingan, melainkan pengguna meluluskan pelan pembaikan secara jelas.
## Input
Pengguna menyediakan satu atau lebih URL halaman. Jika mereka menyediakan URL peta laman atau senarai lebih daripada 5 URL, sampel 5 URL yang mewakili jenis halaman berbeza (laman utama, halaman produk, artikel, halaman kategori, halaman pendaratan).
## Senarai Semak Audit
Untuk setiap URL, semak dan laporkan kesemua sebelas item di bawah. Tandakan setiap item sebagai `PASS`, `WARN`, atau `FAIL`. Sertakan bukti untuk setiap WARN dan FAIL.
### 1. Tag Meta Viewport
Periksa bahawa `<meta name="viewport" content="width=device-width, initial-scale=1">` hadir dalam `<head>` HTML. Jika tiada atau jika menetapkan lebar tetap atau melumpuhkan penskalaan pengguna tanpa alasan aksesibiliti yang sah, tandakan FAIL.
### 2. Pariti Kandungan (Teks)
Ambil halaman dengan ejen pengguna desktop dan ejen pengguna mudah alih (Googlebot Smartphone). Bandingkan kandungan teks yang kelihatan. Jika mana-mana blok teks melebihi 50 perkataan wujud pada desktop tetapi tidak dalam sumber HTML mudah alih, tandakan WARN. Jika teks badan penting, tajuk, atau penerangan produk hilang, tandakan FAIL.
### 3. Pariti Data Berstruktur
Ekstrak semua blok JSON-LD daripada kedua-dua pengambilan desktop dan mudah alih. Jika mana-mana jenis schema hadir pada desktop tetapi hilang dari mudah alih, tandakan FAIL. Jika kandungan schema berbeza antara versi, tandakan WARN.
### 4. Pariti Tag Meta
Bandingkan tag tajuk, keterangan meta, kanonikal, robots, dan hreflang antara versi desktop dan mudah alih. Sebarang perbezaan adalah WARN. Ketiadaan kanonikal atau tag robots yang bercanggah adalah FAIL.
### 5. Pautan Dalaman dan Navigasi
Kira bilangan tag `<a href>` pautan dalaman dalam HTML desktop dan mudah alih. Jika versi mudah alih mempunyai 20%+ lebih sedikit pautan dalaman, tandakan WARN. Jika pautan breadcrumb, navigasi kategori, atau pautan footer hadir pada desktop tetapi hilang dari mudah alih, tandakan FAIL.
### 6. Teks Alt Imej
Kira imej dalam HTML mudah alih. Laporkan bilangan dan peratusan yang kekurangan atribut alt. Jika lebih daripada 10% imej kekurangan teks alt, tandakan WARN. Jika imej hero atau imej produk kekurangan teks alt, tandakan FAIL.
### 7. Core Web Vitals (Data Lapangan)
Cari data lapangan Chrome UX Report (CrUX) URL. Jika boleh diakses melalui API PageSpeed Insights atau carian langsung CrUX, laporkan LCP, INP, dan CLS untuk mudah alih. Tandakan ambang: LCP > 2.5s = WARN, > 4.0s = FAIL. INP > 200ms = WARN, > 500ms = FAIL. CLS > 0.1 = WARN, > 0.25 = FAIL.
Jika data CrUX tidak tersedia (trafik tidak mencukupi), catatkan ini dan gunakan data makmal dari Lighthouse sebagai sandaran dengan kaveat bahawa data makmal tidak digunakan untuk penarafan.
### 8. Saiz Sasaran Ketuk
Periksa CSS untuk butang, pautan, dan elemen interaktif. Tandakan mana-mana elemen yang ketinggian atau lebar terkomput berada di bawah 48 piksel CSS. Tandakan elemen interaktif bersebelahan dengan jarak kurang dari 8px. Tandakan WARN untuk 1-3 pelanggaran, FAIL untuk 4+.
### 9. Saiz Fon
Periksa bahawa teks badan menggunakan saiz fon terkomput sekurang-kurangnya 16px. Tandakan mana-mana teks di bawah 12px. Tandakan WARN jika teks badan ialah 14-15px, FAIL jika di bawah 12px.
### 10. Interstisial dan Pop Timbul
Periksa secara visual viewport mudah alih. Jika pop timbul, sepanduk, atau interstisial meliputi lebih daripada 30% viewport awal dan tidak diperlukan secara undang-undang (persetujuan kuki, pengesahan umur), tandakan WARN. Jika pop timbul menghalang skrol atau membaca kandungan, tandakan FAIL.
### 11. Akses Perangkak AI
Periksa robots.txt untuk peraturan menyekat GPTBot, ClaudeBot, PerplexityBot, Google-Extended, atau OAI-SearchBot. Jika mana-mana perangkak AI disekat, catatkan sebagai pilihan sengaja. Jika perangkak AI dibenarkan tetapi halaman tidak mempunyai data berstruktur, tandakan WARN (sistem AI bergantung pada data berstruktur untuk petikan).
## Format Output
Hasilkan laporan Markdown:
```markdown
# Laporan Audit Mobile-First
**Tarikh:** YYYY-MM-DD
**URL diaudit:** N
**Skor keseluruhan:** X/11 item PASS purata setiap URL
## Ringkasan
| Semakan | URL 1 | URL 2 | URL 3 | URL 4 | URL 5 |
|-------|-------|-------|-------|-------|-------|
| 1. Viewport | PASS | PASS | ... | ... | ... |
| ... | ... | ... | ... | ... | ... |
## Penemuan Terperinci
### URL 1: [url]
**Item FAIL (mesti dibaiki):**
- [Nama item]: [bukti dan arahan pembaikan]
**Item WARN (patut dibaiki):**
- [Nama item]: [bukti dan arahan pembaikan]
**Item PASS:** [senarai]
### Senarai Gilir Pembaikan Keutamaan
1. [Pembaikan keutamaan tertinggi] — menjejaskan pengindeksan secara langsung
2. [Pembaikan seterusnya] — menjejaskan penarafan
3. ...Peraturan
- Jangan buat sebarang perubahan pada laman tanpa kelulusan jelas pengguna terhadap pelan pembaikan.
- Jika anda tidak dapat menyemak item kerana halaman memerlukan pengesahan, catatkan sebagai "NOT CHECKED — authentication required."
- Untuk data CrUX, gunakan API Chrome UX Report rasmi atau API PageSpeed Insights jika tersedia. Jika kedua-duanya tidak boleh diakses, gunakan audit mudah alih Lighthouse sebagai sandaran.
- Jangan sesekali mereka metrik, skor, atau keputusan semakan. Jika data tidak tersedia, nyatakan.
- Jangan akses atau dedahkan kunci API, kuki, token, atau kelayakan.
### Langkah 2: Jalankan audit
Minta ejen anda: **"Run the mobile-first audit skill on [your URL]"** dan tampalkan URL yang ingin anda periksa. Ejen akan menghasilkan laporan dengan PASS/WARN/FAIL untuk setiap 11 semakan, serta senarai gilir pembaikan keutamaan.
Jika anda ingin menyemak berbilang halaman sekaligus, sediakan senarai: **"Run the mobile-first audit on these 5 URLs: [URL1, URL2, URL3, URL4, URL5]"**.
## Pembaikan #1: Pariti kandungan — apa yang perlu diperiksa dahulu
Pariti kandungan adalah pembaikan berimpak tertinggi kerana ia secara langsung menentukan apa yang boleh diindeks Google. Berikut adalah yang paling kerap rosak dan cara membaiki setiap satunya.
### Kandungan tersembunyi dalam tab dan akordion
Banyak laman pada mudah alih meruntuhkan kandungan panjang ke dalam tab, akordion, atau togol "baca lagi". Ini baik **selagi kandungan berada dalam sumber HTML** — Google tidak lagi menolak kandungan yang disembunyikan atas alasan UX. Tetapi jika tab anda memuatkan kandungan melalui JavaScript selepas ketukan pengguna, Googlebot tidak mencetuskan ketukan tersebut. Kandungan itu tidak kelihatan.
**Cara menyemak:** Dalam Chrome DevTools, klik kanan pada kandungan tersembunyi dan pilih "Inspect." Jika anda melihat teks dalam panel Elements, ia berada dalam DOM dan Google boleh melihatnya. Jika panel Elements menunjukkan bekas kosong sehingga anda mengklik tab, kandungan dimuatkan secara dinamik dan Google terlepasnya.
**Cara membaiki:** Paparkan kandungan tersembunyi ke dalam HTML melalui pelayan. Gunakan CSS (`display: none` atau togol keterlihatan) untuk tingkah laku tunjuk/sembunyi dan bukannya suntikan kandungan JavaScript.
### Data berstruktur hilang pada mudah alih
Data berstruktur (JSON-LD) mesti hadir dalam HTML mudah alih. Ini mudah terlepas jika tema mudah alih atau versi AMP anda menggunakan templat berbeza.
**Cara menyemak:** Buka halaman mudah alih, lihat sumber (`Cmd+Option+U`), dan cari `application/ld+json`. Kemudian lakukan yang sama pada desktop. Blok JSON-LD yang sama sepatutnya muncul dalam kedua-duanya.
**Cara membaiki:** Pastikan data berstruktur anda dipaparkan sisi pelayan dan disertakan dalam respons HTML yang sama untuk kedua-dua mudah alih dan desktop. Jika menggunakan CMS, periksa bahawa plugin schema atau tema anda tidak memuatkan skrip secara bersyarat berdasarkan pengesanan peranti.
### Pautan navigasi dilucutkan dari menu mudah alih
Menu mudah alih sering memudahkan atau membuang pautan yang wujud dalam navigasi desktop: breadcrumbs, pautan kategori, lajur footer, pautan sidebar. Google menggunakan pautan dalaman untuk memahami struktur laman dan mengagihkan PageRank. Pautan yang hilang dari mudah alih hilang dari graf Google.
**Cara menyemak:** Kira tag `<a href>` dalam sumber desktop vs sumber mudah alih. Reka bentuk responsif sepatutnya mempunyai kiraan yang hampir sama. Jika kiraan mudah alih 30%+ lebih rendah, siasat pautan mana yang hilang.
**Cara membaiki:** Tambah pautan navigasi yang hilang ke menu mudah alih, menu hamburger, atau footer. Utamakan pautan ke halaman kategori penting, artikel utama, dan halaman induk.
## Pembaikan #2: INP — metrik kelajuan mudah alih yang kebanyakan laman abaikan
Interaction to Next Paint (INP) mengukur berapa lama masa diambil untuk halaman bertindak balas secara visual selepas pengguna mengetuk, mengklik, atau menekan kekunci. Ambangnya ialah **200 milisaat atau kurang**.
Tidak seperti FID, yang hanya mengukur kelewatan input interaksi pertama, INP mengukur setiap interaksi dan melaporkan yang **terburuk**. Ini menjadikannya ujian yang jauh lebih ketat.
### Apa yang membunuh INP mudah alih
Punca paling biasa, mengikut urutan:
1. **JavaScript berat berjalan pada urutan utama.** Bundle besar, komponen React/Vue tidak dioptimumkan, dan skrip penjejakan menyekat penyemak imbas daripada bertindak balas kepada ketukan.
2. **Pengendali klik yang melakukan terlalu banyak kerja sebelum mengemas kini UI.** Jika ketukan mencetuskan panggilan API, kemas kini keadaan, dan perubahan DOM sebelum menunjukkan sebarang maklum balas visual, INP terjejas.
3. **Tag pihak ketiga.** Analitik, widget sembang, rangkaian iklan, dan skrip pemperibadian — terutamanya apabila berbilang tag bersaing untuk urutan utama.
### Cara mendiagnosis INP
1. Buka [PageSpeed Insights](https://pagespeed.google.com/), masukkan URL anda, skrol ke "Discover what your real users are experiencing." Nilai INP di bawah "Mobile" adalah yang digunakan Google.
2. Dalam Chrome DevTools, buka panel **Performance**, klik rekod, berinteraksi dengan halaman (ketuk butang, buka menu, taip dalam input), kemudian hentikan rakaman. Cari tugas panjang (ditanda merah, 200ms+). Ini adalah masalah INP anda.
3. Anda juga boleh bertanya ejen AI anda: **"Check the Core Web Vitals for [URL] and tell me specifically what is hurting INP on mobile. Give me the top 3 fixes in priority order."**
### Cara membaiki INP (urutan keutamaan)
```text
Keutamaan 1: Tangguh atau lengahkan skrip pihak ketiga tidak kritikal.
→ Muatkan widget sembang, analitik, dan tag iklan selepas halaman interaktif.
→ Gunakan <script defer> atau muatkannya 3-5 saat selepas halaman dimuatkan.
Keutamaan 2: Pecahkan tugas JavaScript panjang.
→ Pecah kod mengikut laluan. Lazy-load komponen di bawah lipatan.
→ Alihkan pengiraan berat ke requestIdleCallback() atau Web Worker.
Keutamaan 3: Jadikan pengendali klik mengemas kini UI serta-merta.
→ Tunjukkan keadaan memuatkan, pemutar, atau butang dilumpuhkan dalam 50ms pertama.
→ Jalankan kerja sebenar (panggilan API, kemas kini keadaan) selepas tindak balas visual.Pembaikan #3: Kesediaan perangkak AI (lapisan 2026)
Pengindeksan mobile-first kini mempunyai lapisan AI. Apabila AI Overviews Google atau sistem AI pihak ketiga menjawab soalan, mereka menarik daripada kandungan diindeks mudah alih yang sama. Jika halaman mudah alih anda kekurangan isyarat yang dicari sistem AI, anda kehilangan petikan.
Apa yang diperlukan sistem AI dari halaman mudah alih anda
Isyarat | Mengapa ia penting | Semakan pantas |
|---|---|---|
Data berstruktur (JSON-LD) | Membantu sistem AI memahami entiti, produk, artikel, FAQ | Lihat sumber → cari |
Hierarki tajuk yang jelas | Pengekstrak AI menggunakan H1-H4 untuk menghuraikan struktur halaman | Imbas halaman anda: adakah setiap bahagian mempunyai tajuk deskriptif? |
Blok jawapan ringkas | AI Overviews mengutamakan jawapan 2-4 ayat berhampiran bahagian atas | Adakah halaman anda menjawab soalan utama dalam 200 perkataan pertama? |
Akses robots.txt untuk perangkak AI | Jika disekat, sistem AI tidak boleh mengambil kandungan anda | Periksa robots.txt untuk |
Fail llms.txt | Membantu sistem AI menemui kandungan utama anda dengan cekap | Periksa |
Prompt kesediaan AI pantas untuk ejen anda
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.Prompt audit mobile-first lengkap untuk pemula
Berikut adalah set prompt yang boleh anda salin ke dalam Claude Code atau Codex sekarang. Setiap prompt melakukan satu tugas khusus — tiada konfigurasi diperlukan selain membuka ejen dan menghalakannya ke projek atau URL anda.
Prompt 1: Audit mudah alih halaman tunggal
Run a mobile-first indexing audit on [YOUR URL HERE].
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.Prompt 2: Audit pukal merentas jenis halaman
I need to audit mobile-first readiness across different page types on my site. Here are 5 URLs, each representing a different template:
1. [HOMEPAGE URL]
2. [PRODUCT PAGE OR SERVICE PAGE URL]
3. [BLOG POST OR ARTICLE URL]
4. [CATEGORY OR COLLECTION PAGE URL]
5. [ABOUT OR CONTACT PAGE URL]
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.Prompt 3: Selam dalam pariti kandungan
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.Prompt 4: Diagnosis INP dan pelan pembaikan
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.Prompt 5: Audit perangkak AI + data berstruktur
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).Soalan Lazim
S: Bolehkah saya masih menggunakan laman mudah alih berasingan (m.example.com)? Secara teknikal ya, tetapi Google mengesyorkan reka bentuk responsif. URL mudah alih berasingan menambah kerumitan: anda mesti mengekalkan kandungan, tag kanonikal, dan hreflang yang sama merentas dua set URL. Jika apa-apa tidak selari, Google mengindeks mana-mana versi yang terakhir dirangkak. Reka bentuk responsif menghapuskan risiko ini sepenuhnya.
S: Bagaimana jika laman saya desktop sahaja — tiada versi mudah alih langsung? Jika Googlebot Smartphone tidak boleh mengakses dan memaparkan kandungan anda, kandungan tersebut tidak akan diindeks. Titik. Laman desktop sahaja pada tahun 2026 secara berkesan tidak kelihatan kepada Google. Jika anda dalam situasi ini, beralih ke tema responsif adalah tugas keutamaan tertinggi anda.
S: Adakah saya perlu risau tentang saiz tablet? Googlebot merangkak sebagai telefon pintar, bukan tablet. Fokus pada viewport telefon pintar. Walau bagaimanapun, pengguna tablet adalah pengguna sebenar — pastikan reka bentuk responsif anda tidak rosak pada lebar pertengahan (768-1024px).
S: Bagaimana saya tahu jika laman saya sudah lulus peralihan mobile-first? Buka Google Search Console → Settings → periksa bahagian "About" untuk "Indexing crawler: Googlebot smartphone." Jika ia menyatakan demikian, anda menggunakan pengindeksan mobile-first. Hampir setiap laman kini begitu.
S: Adakah Google masih merangkak laman saya dengan ejen pengguna desktop untuk apa-apa? Ya. Google kadangkala merangkak dengan ejen pengguna desktop untuk semakan khusus (pengesahan hubungan, beberapa pemprosesan semula data berstruktur). Jangan bimbang jika anda melihat Googlebot desktop dalam log anda. Lawatan tersebut tidak bermakna laman anda menggunakan pengindeksan desktop-first.
S: Adakah membaiki isu mobile-first akan meningkatkan keterlihatan AI Overviews saya? Pembaikan pengindeksan mobile-first memperbaiki asas. Jika kandungan mudah alih, data berstruktur, dan kelajuan halaman anda semua kukuh, kandungan anda layak untuk dipetik — tetapi sistem AI Google masih memilih apa yang hendak dipetik berdasarkan kerelevanan, autoriti, dan kualiti jawapan. Membaiki isu mobile-first menghapuskan penghalang; ia tidak menjamin penyertaan AI.
Penulis: Julian Mercer, Pengamal SEO Teknikal 14 Tahun di Auspia. Julian menulis tentang kebolehrangkakan, pemaparan, schema, seni bina laman, dan asas teknikal yang menjadikan kandungan boleh ditemui oleh enjin carian dan sistem AI.
