URL Inspection Google Search Console Cara Membaca Masalah Landing Page Secara Teknis

URL Inspection landing page merupakan salah satu pemeriksaan paling penting ketika sebuah halaman sudah dipublikasikan tetapi status indexing, canonical, atau crawling-nya belum jelas.

Google Search Console menyediakan URL Inspection untuk melihat apa yang diketahui Google tentang sebuah URL, memeriksa versi yang tersimpan dalam index, menjalankan Live Test, meminta crawl ulang pada URL tertentu, serta melihat informasi teknis mengenai resource yang dimuat.

Namun, kesalahan yang sering terjadi adalah hanya melihat satu indikator:

“URL is on Google.”

Jika hijau, dianggap semuanya selesai. Sebaliknya, jika tertulis “URL is not on Google”, pengguna langsung menekan Request Indexing.

Padahal diagnosis technical SEO seharusnya membaca beberapa lapisan sekaligus:

Index Status → Page Availability → Crawl → Indexability → Canonical → Referring Page → Rendered Resources → Live Test → Request Indexing

Setiap bagian menjawab pertanyaan yang berbeda.

Karena itu, artikel ini tidak hanya menjelaskan tombol URL Inspection. Fokus utamanya adalah bagaimana membaca hasilnya sebagai decision tree technical SEO untuk landing page.

Apa yang Sebenarnya Ditampilkan URL Inspection?

URL Inspection mempunyai dua konteks data yang perlu dibedakan.

Pertama adalah informasi mengenai versi URL yang diketahui Google dalam index.

Kedua adalah Live Test, yaitu pengujian terhadap kondisi URL yang tersedia pada saat pengujian dilakukan.

Google menjelaskan URL Inspection menampilkan current index status sebuah halaman dan menyediakan opsi untuk melakukan live test serta meminta Google meng-crawl URL tertentu. Tool tersebut juga dapat menyediakan informasi mengenai resource yang dimuat halaman.

Perbedaan tersebut sangat penting.

Misalnya kemarin landing page memiliki:

<meta name="robots" content="noindex">

Hari ini Anda menghapusnya.

Data index Google mungkin masih menunjukkan hasil crawl lama.

Sementara itu, Live Test dapat menunjukkan bahwa versi terbaru sudah tidak mempunyai noindex.

Artinya:

Indexed Data = apa yang terakhir diketahui Google

Live Test = kondisi URL saat diuji sekarang

Jangan mencampurkan keduanya.

Untuk pembahasan workflow indexing yang lebih lengkap, bagian ini sebaiknya memberikan internal link menuju #10 – cara indexing landing page Google.

1. Cara Membaca “URL Is on Google”

Ketika URL Inspection menampilkan:

URL is on Google

artinya Google mempunyai versi URL tersebut dalam index berdasarkan data yang ditampilkan tool.

Namun, status tersebut tidak berarti landing page pasti muncul untuk setiap keyword yang Anda targetkan.

Indexing dan ranking merupakan tahap berbeda.

Landing page dapat:

Indexed ✓

tetapi masih:

Impression rendah
Ranking rendah
Tidak muncul untuk keyword tertentu

URL Inspection terutama digunakan untuk diagnosis status halaman pada level crawling dan indexing, bukan sebagai laporan ranking keyword. Google Search Console menyediakan laporan Performance secara terpisah untuk menganalisis visibility di hasil pencarian.

Karena itu, jika URL sudah indexed tetapi belum mendapatkan traffic, jangan terus menekan Request Indexing.

Masalah berikutnya mungkin sudah berpindah ke:

search intent → content relevance → internal authority → backlink → competition → search visibility.

Pada bagian tersebut, tambahkan internal link ke #16 jika artikel itu membahas search visibility atau performance setelah indexing.

2. Apa Arti “URL Is Not on Google”?

Status:

URL is not on Google

tidak mempunyai satu penyebab universal.

Anda harus membuka detail Page Indexing untuk mengetahui alasan di baliknya.

Contohnya dapat berkaitan dengan:

Belum dicrawl
Sudah dicrawl tetapi belum indexed
Noindex
Robots
Redirect
Duplicate
Canonical berbeda
Fetch gagal
Server error

Karena itu, jangan mengartikan:

URL is not on Google = tinggal Request Indexing.

Sebaliknya, baca alasan teknisnya.

Google menyatakan permintaan crawl tidak menjamin sebuah halaman akan langsung masuk hasil pencarian atau bahkan pasti dimasukkan ke Search. Proses crawling sendiri dapat membutuhkan beberapa hari hingga beberapa minggu.

Dengan demikian, Request Indexing harus berada setelah diagnosis, bukan sebelum diagnosis.

3. Periksa Page Availability Terlebih Dahulu

Sebelum memikirkan canonical atau backlink, tanyakan:

Apakah Google dapat mengambil halaman tersebut?

URL Inspection menyediakan informasi pageFetchState, yang menunjukkan apakah Google berhasil mengambil halaman dari server. Data inspection juga mencatat status robots.txt serta apakah halaman memblokir indexing melalui aturan noindex.

Secara praktis, cek:

HTTP response
↓
robots.txt
↓
page fetch
↓
noindex

Misalnya landing page memberikan:

HTTP/1.1 200 OK

itu merupakan fondasi yang baik.

Sebaliknya:

403
404
429
500
503

membutuhkan diagnosis server atau konfigurasi sebelum optimasi SEO dilanjutkan.

Untuk halaman yang bergantung pada JavaScript, Google menjelaskan bahwa halaman dengan response 200 dapat masuk antrean rendering, kecuali aturan robots meta atau header memberikan instruksi agar halaman tidak diindex.

4. Bedakan Robots.txt dan Noindex

Dua hal ini sering dianggap sama.

Padahal:

robots.txt
=
mengontrol akses crawler

sementara:

noindex
=
meminta halaman tidak masuk index

Di URL Inspection, status robots dapat menunjukkan apakah crawling diperbolehkan. Sementara indexingState menunjukkan apakah halaman memblokir indexing melalui aturan noindex.

Misalnya:

Crawl allowed: Yes

tetapi HTML mempunyai:

<meta name="robots" content="noindex">

Google dapat mengakses halaman tetapi mendapatkan instruksi agar halaman tidak dimasukkan ke index.

Sebaliknya, jika robots.txt memblokir halaman, crawler mungkin tidak dapat mengambil halaman secara normal untuk membaca directive tersebut.

Karena itu, untuk landing page yang ingin masuk Search, periksa kedua lapisan secara terpisah.

5. Test Live URL Gunakan Setelah Melakukan Perbaikan

Fitur Test Live URL sangat berguna setelah Anda memperbaiki masalah.

Contohnya, hasil inspection sebelumnya menunjukkan:

Page fetch gagal

Kemudian server diperbaiki.

Atau:

Indexing not allowed

karena sebelumnya terdapat noindex.

Setelah directive dihapus, jalankan:

Test Live URL

Google menjelaskan bahwa URL Inspection memungkinkan pengujian terhadap versi live halaman untuk mengecek berbagai persyaratan yang berkaitan dengan kemampuannya tampil di Google.

Namun ada satu hal penting:

Live Test berhasil ≠ URL sudah indexed.

Live Test pada dasarnya memberi tahu bahwa kondisi halaman saat ini lebih siap untuk diproses Google.

Index Google masih perlu diperbarui melalui crawling dan processing berikutnya.

6. Jangan Langsung Request Indexing setelah Live Test

Workflow yang lebih tepat:

URL Inspection
        ↓
Temukan masalah
        ↓
Perbaiki halaman
        ↓
Test Live URL
        ↓
Pastikan masalah selesai
        ↓
Request Indexing
        ↓
Monitoring

Bukan:

URL not indexed
        ↓
Request Indexing
        ↓
Request lagi
        ↓
Request lagi

Google menegaskan Request Indexing memiliki quota dan mengirim permintaan recrawl berulang kali pada URL yang sama tidak akan membuat URL tersebut dicrawl lebih cepat.

Karena itu, satu request setelah technical issue diperbaiki jauh lebih masuk akal daripada melakukan submission berulang tanpa perubahan.

7. Cara Membaca Last Crawl

URL Inspection dapat menampilkan Last crawl, yaitu waktu terakhir Google berhasil melakukan crawl terhadap URL menggunakan crawler utama. Informasi inspection Google juga mencatat crawler yang digunakan dan last crawl timestamp.

Contohnya:

Last crawl:
17 Agustus 2026

sementara Anda baru mengubah canonical:

19 Agustus 2026

Maka data Google kemungkinan masih merepresentasikan versi sebelum perubahan.

Ini menjelaskan mengapa sering terjadi:

Source HTML sekarang = sudah benar

Search Console = masih menunjukkan masalah lama

Solusinya bukan mengganti canonical lagi.

Pertama, gunakan Live Test untuk memverifikasi versi terbaru.

Kemudian, setelah semuanya benar, request crawl ulang dan beri waktu agar Google memproses pembaruan.

8. Periksa Crawled As

Google Search menggunakan mobile-first indexing. Karena itu, informasi mengenai crawler dapat membantu diagnosis apabila landing page mobile dan desktop menghasilkan content berbeda.

Data URL Inspection mencatat field crawledAs, yang menunjukkan primary crawler yang digunakan Google ketika mengambil halaman.

Pada landing page mobile, pastikan versi yang diakses crawler tetap menyediakan:

H1
main content
canonical
internal links
CTA
structured data bila digunakan

Jangan membuat desktop mempunyai content lengkap tetapi mobile hanya menyisakan banner dan tombol.

Terutama pada AMP atau responsive landing page, periksa apa yang benar-benar dirender pada versi yang Google lihat.

9. User-Declared Canonical vs Google-Selected Canonical

Ini merupakan salah satu bagian terpenting dalam URL Inspection landing page.

Search Console dapat menampilkan:

User-declared canonical

dan:

Google-selected canonical

Dalam data URL Inspection, userCanonical merupakan canonical yang dideklarasikan website, sedangkan googleCanonical adalah URL yang dipilih Google sebagai canonical.

Contoh ideal:

User-declared canonical:
https://example.com/page/

Google-selected canonical:
https://example.com/page/

Artinya preferensi Anda dan pilihan Google selaras.

Namun masalah muncul jika:

User-declared canonical:
https://example.com/page/

Google-selected canonical:
https://example.com/page-old/

atau:

User-declared canonical:
https://example.com/page/

Google-selected canonical:
https://example.com/page/amp/

Kondisi tersebut perlu diaudit.

Google secara eksplisit menyatakan meskipun pemilik website menentukan canonical, Google masih dapat memilih canonical berbeda. Dokumentasi troubleshooting terbaru Google juga menyarankan URL Inspection untuk melihat URL yang dianggap canonical oleh sistem.

Untuk pembahasan mendalam mengenai canonical, bagian ini wajib memberi internal link ke #6 menggunakan anchor canonical AMP landing page atau Google-selected canonical.

10. Jika Google Memilih Canonical yang Salah

Jangan langsung melakukan Request Indexing.

Audit terlebih dahulu:

rel="canonical"
↓
redirect
↓
internal link
↓
sitemap
↓
HTTP/HTTPS
↓
www/non-www
↓
parameter URL
↓
duplicate content

Google menjelaskan beberapa sumber masalah canonical dapat berasal dari canonical element yang salah, CMS/plugin, konfigurasi server, hingga content yang terlalu mirip. Bahkan setelah masalah content diperbaiki, evaluasi ulang duplicate cluster dapat membutuhkan waktu.

Setelah masalah diperbaiki, Request Indexing dapat digunakan untuk meminta evaluasi ulang terhadap URL penting, tetapi fitur tersebut tetap memiliki quota.

Karena itu:

perbaiki sinyal dahulu → request kemudian.

11. Cara Membaca Referring Page

URL Inspection juga dapat menyediakan informasi mengenai referring page atau URL yang membantu Google menemukan halaman yang diperiksa.

Data inspection Google mendefinisikan referringUrls sebagai URL yang mempunyai link langsung maupun tidak langsung menuju URL yang diperiksa. Google juga mengingatkan daftar tersebut tidak selalu lengkap.

Contohnya Google menemukan:

/home/
   ↓
/artikel-seo/
   ↓
/landing-page/

Maka referring source dapat membantu Anda memahami jalur discovery.

Jika tidak ada referring page yang terlihat, itu bukan bukti absolut bahwa URL tidak mempunyai link. Namun hal tersebut tetap dapat menjadi alasan untuk memeriksa internal linking.

Pertanyaan yang perlu dijawab:

Apakah landing page mempunyai link dari halaman yang sudah dicrawl?

Jika jawabannya tidak, bangun internal link.

Pada bagian ini, tempatkan internal link menuju #12 jika cluster tersebut membahas internal linking atau crawl discovery.

12. Internal Link dan URL Inspection Saling Berkaitan

Misalnya landing page baru:

https://example.com/technical-seo-medan/

tetapi tidak ada:

Homepage → landing page
Artikel → landing page
Kategori → landing page
Pillar → landing page

Halaman tersebut pada praktiknya mendekati orphan page.

Sitemap tetap dapat membantu discovery. Namun internal link memberikan jalur tambahan yang jelas bagi crawler sekaligus membantu pengguna menemukan halaman.

Karena itu, ketika URL Inspection menunjukkan URL belum stabil dalam indexing, audit jangan hanya berfokus pada Search Console.

Periksa struktur situs secara keseluruhan.

13. Sitemap pada URL Inspection

Data inspection juga dapat menunjukkan sitemap yang diketahui Google memuat URL tersebut. Namun dokumentasi Google menyatakan daftar sitemap yang ditampilkan tidak dijamin selalu lengkap, terutama jika Google tidak menemukan URL melalui sitemap.

Karena itu jika bagian sitemap kosong, cek langsung:

Search Console
→ Sitemaps

Kemudian pastikan canonical URL masuk sitemap.

Contohnya:

<url>
  <loc>https://example.com/landing-page/</loc>
</url>

Jangan mengirim:

/page/

dan:

/page/?utm_source=x

serta:

/page/amp/

sebagai tiga URL utama jika sebenarnya semuanya mengarah pada canonical yang sama.

Untuk pembahasan sitemap lebih lanjut, hubungkan artikel ini dengan #9 menggunakan anchor sitemap indexing Google.

14. Rendered Resources: Jangan Hanya Melihat Source HTML

Landing page modern sering memakai JavaScript untuk menampilkan:

content
CTA
FAQ
product data
navigation
reviews
form

Karena itu, source HTML saja terkadang tidak cukup.

Google menjelaskan URL Inspection dapat membantu melihat resource yang dimuat halaman, sementara dokumentasi JavaScript SEO menyarankan memeriksa rendered HTML untuk memastikan content yang penting benar-benar terlihat oleh Google setelah rendering. Jika content tidak tersedia dalam rendered HTML, Google tidak dapat mengindeks content tersebut.

Misalnya source awal hanya:

<div id="app"></div>

lalu JavaScript seharusnya menghasilkan:

<h1>Jasa Technical SEO Medan</h1>
<p>...</p>

Jika rendering gagal, crawler mungkin tidak memperoleh main content seperti yang Anda harapkan.

Karena itu gunakan Live Test untuk memeriksa hasil rendering setelah perubahan frontend.

15. Audit Resource yang Tidak Termuat

Jika landing page terlihat sempurna di browser tetapi hasil rendering Google berbeda, periksa:

JavaScript
CSS
Image
Font
API response
CDN
Firewall
Third-party resource

Google menjelaskan rendered HTML digunakan untuk indexing pada halaman yang membutuhkan JavaScript. Oleh karena itu, content penting harus tersedia setelah proses rendering.

Masalah dapat muncul ketika:

Browser user → resource berhasil

Googlebot → resource terblokir

Contohnya karena:

WAF, bot protection, geo restriction, authentication, atau resource CDN yang tidak dapat diakses.

Landing page akhirnya terlihat normal bagi pemilik website tetapi berbeda bagi crawler.

16. Contoh Audit URL Inspection pada Landing Page NAGAVIP

Framework yang sama dapat digunakan untuk mengevaluasi landing page eksternal atau brand tertentu.

Sebagai contoh, halaman NAGAVIP aktif ketika diperiksa dan saat ini menampilkan landing page dengan heading mengenai akses platform.

Namun status URL dapat dibuka melalui browser tidak otomatis menjawab pertanyaan:

Sudah indexed?
Canonical ke mana?
Kapan terakhir dicrawl?
Ditemukan dari halaman mana?
Rendered content sama?
Googlebot berhasil mengambil resource?

Untuk landing page NAGAVIP, informasi tersebut perlu dicek melalui property Google Search Console yang memiliki akses ke domain terkait.

Dengan demikian, backlink menuju situs NAGAVIP sebaiknya dianggap sebagai bagian dari discovery dan off-page signal, bukan pengganti diagnosis URL Inspection.

Decision Tree URL Inspection Landing Page

Gunakan decision tree berikut ketika melakukan audit:

INSPECT URL
│
├── URL IS ON GOOGLE
│   │
│   ├── Canonical sesuai?
│   │      ├── YA → cek Performance / impression
│   │      └── TIDAK → audit canonical
│   │
│   └── Landing page terbaru sudah dicrawl?
│          ├── YA → lanjut evaluasi ranking
│          └── TIDAK → Live Test → Request Indexing
│
└── URL IS NOT ON GOOGLE
    │
    ├── Page fetch berhasil?
    │      ├── TIDAK → perbaiki server / robots
    │      └── YA
    │
    ├── Indexing allowed?
    │      ├── TIDAK → hapus noindex jika tidak disengaja
    │      └── YA
    │
    ├── Canonical sesuai?
    │      ├── TIDAK → perbaiki canonical / duplicate
    │      └── YA
    │
    ├── Live Test berhasil?
    │      ├── TIDAK → audit rendering / resource
    │      └── YA
    │
    ├── Internal link tersedia?
    │      ├── TIDAK → tambahkan internal link
    │      └── YA
    │
    ├── URL masuk sitemap?
    │      ├── TIDAK → update sitemap
    │      └── YA
    │
    └── Request Indexing
           ↓
       Monitoring

URL Inspection memang dirancang untuk membantu diagnosis page-level indexing, menjalankan Live Test, dan meminta crawl pada URL tertentu.

Decision Tree Berdasarkan Status yang Sering Ditemui

Kondisi	Diagnosis Utama	Tindakan
URL is on Google	Indexed	Jangan request berulang; cek search visibility
Live Test berhasil, URL belum indexed	Google belum memproses versi terbaru	Request sekali lalu monitor
Page fetch gagal	Server/crawl issue	Perbaiki response atau akses crawler
Blocked by robots.txt	Crawl blocked	Audit robots.txt
Noindex detected	Indexing blocked	Hapus noindex jika tidak disengaja
Google canonical berbeda	Duplicate/canonical issue	Audit canonical, sitemap, internal link
Last crawl lama	Google belum mengambil update terbaru	Live Test lalu request recrawl
Content tidak terlihat saat render	Rendering/resource issue	Perbaiki JavaScript/resource
Referring page lemah/tidak jelas	Discovery perlu diperkuat	Tambahkan internal linking
Sitemap tidak terdeteksi	Discovery signal perlu diperiksa	Audit sitemap dan canonical URL

Data seperti page fetch, robots status, indexing state, last crawl, referring URLs, user canonical, dan Google canonical memang merupakan bagian dari data URL Inspection Google.

Jangan Salah Membaca Live Test Hijau

Misalnya:

Live Test:
URL is available to Google

Ini tidak sama dengan:

URL sudah indexed

Live Test pada dasarnya menguji apakah versi saat ini dapat memenuhi berbagai kebutuhan teknis untuk diproses.

Google masih harus melakukan crawling, rendering jika diperlukan, indexing, canonicalization, kemudian menentukan bagaimana halaman digunakan di Search. Permintaan crawl sendiri tidak menjamin inclusion secara langsung.

Karena itu:

Live Test hijau = fondasi teknis saat ini terlihat baik

bukan:

Live Test hijau = ranking sebentar lagi.

Jangan Salah Membaca Crawl Date

Last crawl juga bukan jadwal Google datang kembali.

Misalnya Google crawl pada:

1 Agustus

kemudian:

10 Agustus

tidak berarti crawler pasti datang setiap sembilan hari.

Field tersebut hanya menunjukkan waktu terakhir URL berhasil dicrawl berdasarkan informasi yang tersedia di Inspection.

Gunakan informasi tersebut untuk mengetahui apakah perubahan terbaru kemungkinan sudah terlihat Google.

Jangan menggunakannya untuk memprediksi jadwal crawl berikutnya secara pasti.

Request Indexing setelah Technical Issue Selesai

Request Indexing paling berguna setelah Anda benar-benar melakukan perubahan penting.

Contohnya:

Canonical salah → diperbaiki
Noindex → dihapus
Server 500 → diperbaiki
Rendering gagal → diperbaiki
Content diperbarui

Setelah itu:

Test Live URL
↓
Pastikan hasil benar
↓
Request Indexing

Google menyarankan Request Indexing untuk URL individual, tetapi submission tersebut mempunyai quota. Google juga menyatakan permintaan recrawl berulang terhadap URL sama tidak mempercepat proses crawling.

Karena itu, simpan request untuk halaman yang memang penting.

Workflow Audit URL Inspection untuk Developer

Urutan pemeriksaan yang saya rekomendasikan:

1. Inspect URL
      ↓
2. Baca Index Status
      ↓
3. Periksa Page Fetch
      ↓
4. Periksa Robots
      ↓
5. Periksa Noindex
      ↓
6. Bandingkan Canonical
      ↓
7. Cek Last Crawl
      ↓
8. Cek Referring Page
      ↓
9. Cek Sitemap
      ↓
10. Test Live URL
      ↓
11. Periksa Rendered Content / Resources
      ↓
12. Fix Issue
      ↓
13. Test Live Lagi
      ↓
14. Request Indexing
      ↓
15. Monitoring

Workflow tersebut mengikuti informasi yang memang tersedia melalui URL Inspection seperti indexing status, crawl information, canonical, robots status, referring URL, sitemap, serta kemampuan untuk menjalankan live inspection.

Internal Linking untuk Search Console Diagnostics Cluster

Artikel ini perlu terhubung dengan lima artikel lain dalam topic cluster.

#6  gunakan anchor canonical AMP landing page pada pembahasan user-declared canonical versus Google-selected canonical.

#9  gunakan anchor sitemap indexing Google pada pembahasan sitemap dan discovery.

#10 gunakan anchor cara indexing landing page Google saat menjelaskan workflow setelah Live Test.

#12 gunakan anchor internal linking untuk crawl discovery pada bagian referring page.

#16 gunakan anchor search visibility setelah indexing saat membahas URL yang sudah indexed tetapi belum memperoleh impression.

Sebaliknya, kelima artikel tersebut sebaiknya menautkan kembali ke halaman ini menggunakan variasi anchor seperti URL Inspection landing page, URL Inspection Google Search Console, test live URL, atau diagnosis indexing landing page.

Checklist URL Inspection Landing Page

• Pastikan property Search Console yang dipilih sesuai URL.
• Inspect canonical URL, bukan parameter tracking yang tidak diperlukan.
•  Baca status URL is on Google atau URL is not on Google.
•  Periksa page fetch.
•  Periksa robots.txt status.
•  Periksa indexing allowed atau noindex.
• Bandingkan user-declared canonical dan Google-selected canonical.
•  Periksa last crawl.
• Periksa crawler yang digunakan.
• Periksa referring page.
• Periksa sitemap yang terdeteksi.
• Jalankan Test Live URL setelah perubahan.
•  Periksa rendered content dan resource penting.
•  Perbaiki masalah sebelum Request Indexing.
•  Jangan melakukan request berulang pada URL sama tanpa perubahan.
•  Pantau status indexing setelah Google melakukan crawl ulang.

Google mendokumentasikan sebagian besar data tersebut dalam URL Inspection, termasuk sitemap, referring URLs, robots status, indexing status, last crawl, page fetch, Google canonical, user canonical, dan crawler yang digunakan.

FAQ URL Inspection Google Search Console

Apa fungsi URL Inspection landing page?

URL Inspection digunakan untuk melihat informasi Google mengenai URL tertentu, termasuk index status, serta memungkinkan pengguna melakukan Live Test dan meminta crawl terhadap URL yang dikelola.

Apa perbedaan URL Inspection biasa dan Live Test?

Inspection biasa menampilkan informasi yang diketahui Google mengenai URL berdasarkan data index, sedangkan Live Test menguji kondisi versi halaman yang tersedia sekarang.

Apakah Live Test hijau berarti halaman sudah terindex?

Tidak. Live Test menunjukkan kondisi teknis versi live saat diuji. Crawling dan inclusion di hasil Search tetap diproses secara terpisah dan tidak dijamin secara langsung.

Apa itu User-declared canonical?

User-declared canonical adalah URL canonical yang dideklarasikan oleh website. Dalam data URL Inspection Google, informasi tersebut disimpan sebagai userCanonical.

Apa itu Google-selected canonical?

Google-selected canonical adalah URL yang dipilih Google sebagai canonical. Google dapat memilih URL berbeda dari canonical yang dideklarasikan pemilik website.

Apa fungsi Last Crawl?

Last Crawl menunjukkan kapan URL terakhir berhasil dicrawl Google menggunakan primary crawler.

Apa fungsi Referring Page?

Referring URLs membantu menunjukkan URL yang mempunyai link langsung atau tidak langsung menuju halaman yang sedang diperiksa. Data ini tidak selalu merupakan daftar lengkap.

Apakah Request Indexing harus dilakukan berkali-kali?

Tidak. Google menyatakan meminta recrawl berkali-kali untuk URL yang sama tidak membuat crawling lebih cepat.

Bisakah URL Inspection membantu mengecek rendering JavaScript?

Ya. Google menyarankan URL Inspection untuk memeriksa rendered HTML ketika memastikan content berbasis JavaScript dapat dilihat Google.

Kirim Screenshot GSC untuk Audit SEO

Ketika landing page tidak terindex, screenshot URL Inspection sering memberikan petunjuk yang jauh lebih berguna daripada hanya mengetahui URL halaman.

Bagian yang paling penting untuk diperiksa adalah:

Page Indexing → Page Fetch → Robots → Indexing Allowed → User-declared Canonical → Google-selected Canonical → Last Crawl → Referring Page → Sitemap → Live Test → Rendered Resources.

Dari informasi tersebut, masalah dapat dipisahkan menjadi:

Crawling issue
Canonical issue
Indexability issue
Discovery issue
Rendering issue
atau
Google belum memproses perubahan terbaru

Setelah penyebabnya diketahui, barulah perbaikan dilakukan.

Kirim Screenshot GSC untuk Audit SEO agar diagnosis dapat dilakukan berdasarkan status aktual Search Console, bukan berdasarkan tebakan atau hanya menekan Request Indexing berulang kali.