Jawaban singkat
Pengindeksan mobile-first telah selesai. Sejak Juli 2024, Google hanya menggunakan versi seluler situs Anda untuk pengindeksan dan peringkat. Jika konten, data terstruktur, atau tautan internal ada di desktop tetapi tidak di seluler, Google tidak melihatnya. Pada tahun 2026, ada tiga konsekuensi baru yang belum ditangani oleh sebagian besar pemilik situs: INP menggantikan FID sebagai Core Web Vital, AI Overviews mengambil dari konten yang dirender seluler, dan Core Update Maret 2026 meningkatkan bobot peringkat pengalaman halaman seluler.
Di bawah ini, Anda akan menemukan alur kerja audit lengkap — dan skill Codex siap pakai yang menjalankan sebagian besar pemeriksaan untuk Anda.
Apa arti sebenarnya "hanya seluler" pada tahun 2026
Google mulai memigrasikan situs ke pengindeksan mobile-first pada tahun 2018. Transisi ini memakan waktu lebih dari enam tahun. Per Juli 2024, setiap situs yang masih memiliki konten yang dapat diakses di desktop tanpa padanan seluler kehilangan konten tersebut dari indeks Google. Tidak ada opt-out dan tidak ada fallback khusus desktop.
Namun ceritanya tidak berakhir di situ. Tiga perubahan pada tahun 2025–2026 mengubah apa yang dituntut "mobile-first" dari situs Anda:
Perubahan 1: INP menggantikan FID — dan sebagian besar situs seluler gagal
Pada Maret 2024, Google mengganti First Input Delay (FID) dengan Interaction to Next Paint (INP) sebagai Core Web Vital. INP mengukur seberapa cepat halaman Anda merespons ketukan, klik, dan tekan tombol di seluruh sesi halaman, bukan hanya interaksi pertama.
Angka pastinya: sekitar 40% situs yang lulus FID tidak lulus INP. Di seluler, hanya sekitar 65% situs yang memenuhi ambang batas "baik" yaitu 200 milidetik atau kurang. Core Update Maret 2026 semakin meningkatkan bobot peringkat Core Web Vitals. Situs yang gagal INP seluler kini kehilangan posisi dari pesaing yang lebih cepat.
Perubahan 2: AI Overviews dan crawler AI membaca konten seluler Anda
AI Overviews Google muncul di sekitar 47% pencarian per pertengahan 2026. Saat sistem AI Google menghasilkan jawaban, mereka mengambil dari konten terindeks seluler yang sama yang digunakan pencarian reguler. Crawler AI pihak ketiga (GPTBot, ClaudeBot, PerplexityBot) juga mengakses halaman yang dirender seluler Anda.
Jika versi seluler Anda tidak memiliki data terstruktur, judul yang jelas, atau teks penting, sistem AI tidak dapat mengutip Anda — meskipun versi desktop memiliki konten tersebut.
Perubahan 3: Kesenjangan paritas konten kini memiliki dampak peringkat yang terukur
Pada tahun 2026, situs dengan konten seluler dan desktop yang tidak konsisten menunjukkan paparan pencarian organik 31,2% lebih rendah rata-rata dibandingkan situs dengan paritas konten penuh. Elemen yang paling sering hilang di seluler: konten tab tersembunyi, tautan sidebar, markup data terstruktur, teks alt gambar, dan tautan navigasi internal.
Elemen konten | % situs yang tidak memilikinya di seluler |
|---|---|
Data terstruktur (JSON-LD) | 23% |
Tautan internal (menu, breadcrumbs) | 18% |
Teks alt gambar | 27% |
Teks lengkap di tab/accordion | 15% |
Meta tag robots | 9% |
Cara memeriksa apakah situs Anda lulus (versi 2 menit)
Sebelum menjalankan audit lengkap, periksa tiga sinyal ini. Masing-masing memakan waktu kurang dari satu menit dan memberi tahu Anda apakah perlu menggali lebih dalam.
Sinyal 1: Status pengindeksan Google Search Console
Buka Google Search Console → klik Pengaturan (ikon roda gigi, kiri bawah) → lihat bagian "Tentang". Jika tertulis "Googlebot smartphone" di bawah "Crawler pengindeksan," situs Anda berada pada pengindeksan mobile-first. Ini berlaku untuk hampir semua situs pada tahun 2026 — tetapi verifikasikan.
Juga periksa: Alat Inspeksi URL → masukkan halaman penting apa pun → perluas "Crawl" → konfirmasi "Di-crawl sebagai: Googlebot smartphone." Lihat tangkapan layar yang disediakan Google — inilah yang sebenarnya dilihat Google. Jika konten kunci hilang dari tangkapan layar itu, konten tersebut hilang dari indeks.
Sinyal 2: PageSpeed Insights dengan data seluler nyata
Buka PageSpeed Insights, masukkan URL Anda, dan lihat bagian "Temukan apa yang dialami pengguna nyata Anda". Ini adalah data lapangan Chrome User Experience Report (CrUX) — data yang sama yang digunakan Google untuk peringkat.
Jika laporan seluler menunjukkan oranye atau merah untuk INP (Interaction to Next Paint), Anda memiliki liabilitas peringkat yang aktif. Ambang batasnya adalah di bawah 200 milidetik untuk hijau.
Sinyal 3: Pemeriksaan cepat viewport seluler Chrome DevTools
Buka Chrome DevTools (F12 atau Cmd+Option+I), klik ikon toolbar perangkat (Ctrl+Shift+M), dan pilih preset perangkat seluler seperti "Pixel 7." Muat ulang halaman. Pindai:
- Teks yang memerlukan pengguliran horizontal
- Tombol atau tautan yang terlalu kecil untuk diketuk (di bawah 48x48 piksel CSS)
- Konten yang tersembunyi di balik toggle "baca selengkapnya" yang tidak ada di sumber HTML
- Pop-up yang menutupi sebagian besar layar
Masing-masing adalah masalah pengindeksan mobile-first jika konten atau tautan di baliknya berbeda dari yang dilihat pengguna desktop.
Audit mobile-first 30 menit (dengan Codex)
Cara tercepat untuk menjalankan audit mobile-first lengkap saat ini adalah memberikan agen pengkodean AI — Claude Code atau Codex — tugas terstruktur. Agen membaca sumber situs Anda, memeriksa aturan, dan menghasilkan daftar perbaikan yang diprioritaskan.
Di bawah ini adalah file skill lengkap. Salin ke proyek Anda, lalu minta agen Anda untuk menjalankannya.
Langkah 1: Buat file skill
Buat file 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 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.
### Langkah 2: Jalankan audit
Minta agen Anda: **"Jalankan skill audit mobile-first pada [URL Anda]"** dan tempelkan URL yang ingin Anda periksa. Agen akan menghasilkan laporan dengan PASS/WARN/FAIL untuk masing-masing dari 11 pemeriksaan, ditambah antrian prioritas perbaikan.
Jika Anda ingin memeriksa beberapa halaman sekaligus, berikan daftar: **"Jalankan audit mobile-first pada 5 URL ini: [URL1, URL2, URL3, URL4, URL5]"**.
## Perbaikan #1: Paritas konten — apa yang harus diperiksa terlebih dahulu
Paritas konten adalah perbaikan dengan dampak tertinggi karena secara langsung menentukan apa yang dapat diindeks Google. Berikut adalah yang paling sering rusak dan cara memperbaikinya.
### Konten tersembunyi di tab dan accordion
Banyak situs di seluler menciutkan konten panjang ke dalam tab, accordion, atau toggle "baca selengkapnya". Ini tidak masalah **selama konten ada di sumber HTML** — Google tidak lagi mendiskon konten yang disembunyikan karena alasan UX. Tetapi jika tab Anda memuat konten melalui JavaScript setelah ketukan pengguna, Googlebot tidak memicu ketukan itu. Konten tidak terlihat.
**Cara memeriksa:** Di Chrome DevTools, klik kanan pada konten tersembunyi dan pilih "Inspect." Jika Anda melihat teks di panel Elements, teks itu ada di DOM dan Google dapat melihatnya. Jika panel Elements menampilkan kontainer kosong hingga Anda mengklik tab, konten dimuat secara dinamis dan Google melewatkannya.
**Cara memperbaiki:** Render konten tersembunyi di sisi server ke dalam HTML. Gunakan CSS (`display: none` atau toggle visibilitas) untuk perilaku tampilkan/sembunyikan alih-alih injeksi konten JavaScript.
### Data terstruktur hilang di seluler
Data terstruktur (JSON-LD) harus ada di HTML seluler. Ini mudah terlewat jika tema seluler atau versi AMP Anda menggunakan template yang berbeda.
**Cara memeriksa:** Buka halaman seluler, lihat sumber (`Cmd+Option+U`), dan cari `application/ld+json`. Kemudian lakukan hal yang sama di desktop. Blok JSON-LD yang sama harus muncul di keduanya.
**Cara memperbaiki:** Pastikan data terstruktur Anda dirender di sisi server dan disertakan dalam respons HTML yang sama untuk seluler dan desktop. Jika menggunakan CMS, periksa apakah plugin schema atau tema Anda tidak memuat skrip secara kondisional berdasarkan deteksi perangkat.
### Tautan navigasi dihapus dari menu seluler
Menu seluler sering menyederhanakan atau menghapus tautan yang ada di navigasi desktop: breadcrumbs, tautan kategori, kolom footer, tautan sidebar. Google menggunakan tautan internal untuk memahami struktur situs dan mendistribusikan PageRank. Tautan yang hilang dari seluler juga hilang dari grafik Google.
**Cara memeriksa:** Hitung tag `<a href>` di sumber desktop vs. sumber seluler. Desain responsif seharusnya memiliki jumlah yang kira-kira sama. Jika jumlah seluler 30%+ lebih rendah, selidiki tautan mana yang hilang.
**Cara memperbaiki:** Tambahkan tautan navigasi yang hilang ke menu seluler, menu hamburger, atau footer. Prioritaskan tautan ke halaman kategori penting, artikel kunci, dan halaman induk.
## Perbaikan #2: INP — metrik kecepatan seluler yang diabaikan sebagian besar situs
Interaction to Next Paint (INP) mengukur berapa lama waktu yang dibutuhkan halaman untuk merespons secara visual setelah pengguna mengetuk, mengklik, atau menekan tombol. Ambang batasnya adalah **200 milidetik atau kurang**.
Tidak seperti FID, yang hanya mengukur penundaan input interaksi pertama, INP mengukur setiap interaksi dan melaporkan yang **terburuk**. Ini menjadikannya tes yang jauh lebih ketat.
### Apa yang membunuh INP seluler
Penyebab paling umum, secara berurutan:
1. **JavaScript berat berjalan di thread utama.** Bundel besar, komponen React/Vue yang tidak dioptimalkan, dan skrip pelacakan memblokir kemampuan browser untuk merespons ketukan.
2. **Handler klik yang melakukan terlalu banyak pekerjaan sebelum memperbarui UI.** Jika ketukan memicu panggilan API, perubahan state, dan perubahan DOM sebelum menampilkan umpan balik visual apa pun, INP menderita.
3. **Tag pihak ketiga.** Analytics, widget chat, jaringan iklan, dan skrip personalisasi — terutama ketika beberapa tag bersaing untuk thread utama.
### Cara mendiagnosis INP
1. Buka [PageSpeed Insights](https://pagespeed.google.com/), masukkan URL Anda, gulir ke "Temukan apa yang dialami pengguna nyata Anda." Nilai INP di bawah "Seluler" adalah yang digunakan Google.
2. Di Chrome DevTools, buka panel **Performance**, klik rekam, berinteraksi dengan halaman (ketuk tombol, buka menu, ketik di input), lalu hentikan perekaman. Cari tugas panjang (ditandai merah, 200ms+). Ini adalah masalah INP Anda.
3. Anda juga dapat bertanya kepada agen AI Anda: **"Periksa Core Web Vitals untuk [URL] dan beri tahu saya secara spesifik apa yang merusak INP di seluler. Berikan 3 perbaikan teratas dalam urutan prioritas."**
### Cara memperbaiki INP (urutan prioritas)
```text
Prioritas 1: Tunda atau tahan skrip pihak ketiga yang tidak kritis.
→ Muat widget chat, analytics, dan tag iklan setelah halaman interaktif.
→ Gunakan <script defer> atau muat 3-5 detik setelah halaman dimuat.
Prioritas 2: Pecah tugas JavaScript yang panjang.
→ Pisahkan kode berdasarkan rute. Muat komponen below the fold secara lazy.
→ Pindahkan komputasi berat ke requestIdleCallback() atau Web Worker.
Prioritas 3: Buat handler klik segera memperbarui UI.
→ Tampilkan status loading, spinner, atau tombol yang dinonaktifkan dalam 50ms pertama.
→ Jalankan pekerjaan sebenarnya (panggilan API, pembaruan state) setelah respons visual.Perbaikan #3: Kesiapan crawler AI (lapisan 2026)
Pengindeksan mobile-first kini memiliki lapisan AI. Saat AI Overviews Google atau sistem AI pihak ketiga menjawab pertanyaan, mereka mengambil dari konten terindeks seluler yang sama. Jika halaman seluler Anda tidak memiliki sinyal yang dicari sistem AI, Anda kehilangan kutipan.
Apa yang dibutuhkan sistem AI dari halaman seluler Anda
Sinyal | Mengapa penting | Pemeriksaan cepat |
|---|---|---|
Data terstruktur (JSON-LD) | Membantu sistem AI memahami entitas, produk, artikel, FAQ | Lihat sumber → cari |
Hierarki judul yang jelas | Ekstraktor AI menggunakan H1-H4 untuk mengurai struktur halaman | Pindai halaman Anda: apakah setiap bagian memiliki judul deskriptif? |
Blok jawaban ringkas | AI Overviews lebih suka jawaban 2-4 kalimat di dekat bagian atas | Apakah halaman Anda menjawab pertanyaan utama dalam 200 kata pertama? |
Akses robots.txt untuk crawler AI | Jika diblokir, sistem AI tidak dapat mengambil konten Anda | Periksa robots.txt untuk |
File llms.txt | Membantu sistem AI menemukan konten kunci Anda secara efisien | Periksa |
Prompt pemeriksaan kesiapan AI cepat untuk agen Anda
"Periksa [URL] untuk kesiapan pencarian AI. Beri tahu saya: (1) apakah data terstruktur JSON-LD ada dan valid? (2) apakah ada jawaban yang jelas untuk pertanyaan utama halaman dalam 200 kata pertama? (3) apakah crawler AI diizinkan di robots.txt? (4) apakah llms.txt ada di root? Berikan PASS/FAIL untuk masing-masing dan beri tahu apa yang harus diperbaiki terlebih dahulu."
Prompt audit mobile-first lengkap untuk pemula
Berikut adalah serangkaian prompt yang dapat Anda salin ke Claude Code atau Codex sekarang juga. Setiap prompt melakukan satu pekerjaan spesifik — tidak diperlukan konfigurasi selain membuka agen dan mengarahkannya ke proyek atau URL Anda.
Prompt 1: Audit seluler satu halaman
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 massal di berbagai 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: Analisis mendalam paritas konten
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 rencana perbaikan
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 crawler AI dan data terstruktur
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).FAQ
T: Bisakah saya masih menggunakan situs seluler terpisah (m.example.com)? Secara teknis ya, tetapi Google merekomendasikan desain responsif. URL seluler terpisah menambah kompleksitas: Anda harus mempertahankan konten yang identik, tag canonical, dan hreflang di dua set URL. Jika ada yang tidak sinkron, Google mengindeks versi mana pun yang terakhir di-crawl. Desain responsif menghilangkan risiko ini sepenuhnya.
T: Bagaimana jika situs saya hanya desktop — tidak ada versi seluler sama sekali? Jika Googlebot Smartphone tidak dapat mengakses dan merender konten Anda, konten itu tidak akan diindeks. Titik. Situs khusus desktop pada tahun 2026 secara efektif tidak terlihat oleh Google. Jika Anda dalam situasi ini, beralih ke tema responsif adalah tugas prioritas tertinggi Anda.
T: Apakah saya perlu khawatir tentang ukuran tablet? Googlebot melakukan crawl sebagai smartphone, bukan tablet. Fokus pada viewport smartphone. Meskipun demikian, pengguna tablet adalah pengguna nyata — pastikan desain responsif Anda tidak rusak pada lebar menengah (768-1024px).
T: Bagaimana cara mengetahui apakah situs saya sudah lulus transisi mobile-first? Buka Google Search Console → Pengaturan → periksa bagian "Tentang" untuk "Crawler pengindeksan: Googlebot smartphone." Jika tertulis demikian, Anda berada pada pengindeksan mobile-first. Hampir semua situs sudah berada di sana sekarang.
T: Apakah Google masih melakukan crawl situs saya dengan user-agent desktop untuk sesuatu? Ya. Google sesekali melakukan crawl dengan user-agent desktop untuk pemeriksaan tertentu (verifikasi hubungan, pemrosesan ulang beberapa data terstruktur). Jangan khawatir jika Anda melihat Googlebot desktop di log Anda. Kunjungan itu tidak berarti situs Anda berada pada pengindeksan desktop-first.
Penulis: Julian Mercer, Praktisi SEO Teknis 14 Tahun di Auspia. Julian menulis tentang crawlability, rendering, schema, arsitektur situs, dan fondasi teknis yang membuat konten dapat ditemukan oleh mesin pencari dan sistem AI.
