Setting Up Google Search Console Properly for a Malaysian Business
Domain versus URL-prefix properties, verification methods, sitemap submission, and what Discovered/Crawled — currently not indexed really mean.
Search Console is free, and most businesses set it up once, glance at it during a slow month, and rarely open it again. That's worth changing, because it's the closest thing to a direct line into how Google is actually treating your website — not how you assume it is. Most of what goes quietly wrong with a Malaysian business site's search presence shows up here weeks before it shows up in enquiry numbers, but only if the property was set up correctly in the first place and the reports are read for what they actually say.
Domain property or URL-prefix property?
The first decision Search Console asks for, when adding a new property, is between two types that behave differently.
A URL-prefix property is scoped exactly to what's typed in: https://example.com.my/ and https://www.example.com.my/ register as two separate properties, each showing data only for that exact protocol and host. Google's own guidance describes it as covering "only URLs with the specified prefix, including the protocol" (see Add a website or platform property to Search Console).
A Domain property covers the whole domain in one property — "all subdomains... and multiple protocols (http, https, ftp)," per the same page. Set up example.com.my as a Domain property and its data combines www.example.com.my, the bare domain, m.example.com.my if it exists, and both http and https traffic, in one view.
For most Malaysian business websites, a Domain property is the more sensible default. Search traffic doesn't respect a www/non-www or http/https split that may have been decided years ago for unrelated reasons, and a Domain property means you're not quietly missing half your own data because it landed on the "other" URL-prefix property you didn't set up. Google's guidance is direct about this: if you want a property to match any protocol or subdomain, "consider creating a Domain property instead" of a URL-prefix one. The case where URL-prefix still earns its place is when you specifically need to isolate data by path — a /blog/ subfolder tracked separately from the rest of the site, for instance — which a Domain property can't do on its own.
Verifying ownership: the method that actually applies to you
Verification proves to Google that you genuinely control the property, and the available methods differ by type. For a Domain property, Google requires DNS record verification — adding a TXT record through your domain registrar or DNS provider — and there is no HTML file or meta tag alternative for this property type.
For a URL-prefix property, several methods work: uploading an HTML verification file to the site's root directory, adding a meta tag to the homepage's <head>, verifying through an existing Google Analytics or Google Tag Manager snippet already installed on the site, or DNS if that's simply the method you'd rather use anyway (see Verify your site ownership).
In practice, if you're setting up a Domain property — the usual recommendation above — you'll need DNS access regardless, which means whoever manages your domain's nameservers has to be involved, and that isn't always the same person who manages the website itself. Worth arranging early, since DNS changes don't always propagate immediately and it's frustrating to be blocked on verification the day you actually need it done.
Submitting a sitemap: what it does, and what it doesn't
Once a property is verified, submitting an XML sitemap (Indexing → Sitemaps → enter the path, typically sitemap.xml) tells Google which URLs you consider worth showing in search results. It's genuinely useful — and it has never been, and isn't now, a guarantee of anything beyond that.
Google's documentation states the limit plainly: "submitting a sitemap is merely a hint: it doesn't guarantee that Google will download the sitemap or use the sitemap for crawling URLs on the site" (see Build and submit a sitemap). A sitemap makes discovery easier and passes along useful metadata, such as when a page last changed, but crawling and indexing remain separate decisions Google makes afterward, weighing factors a sitemap has no influence over.
If a proposal or brief for your site promises that submitting a sitemap gets pages "indexed," that promise doesn't survive contact with Google's own description of what a sitemap actually does.
Reading the Pages report honestly
The Pages report, under Indexing, shows how many known URLs are indexed and, more usefully, why the rest aren't. Two statuses account for most of the confusion business owners run into, because they read as near-synonyms and mean genuinely different things.
"Discovered — currently not indexed"
Google's own wording: "The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl" (see the Page Indexing report documentation). In plain terms: Google knows the page exists and simply hasn't gotten to it — often a scheduling or crawl-capacity matter rather than a rejection. A handful of these on a small site usually resolves on its own over time; a large and growing count, especially paired with a slow-responding server, is worth investigating from the hosting side.
"Crawled — currently not indexed"
This one is a decision Google has already made, not a queue it's working through. Google's wording: "The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling." Google visited the page, read it, and chose not to add it to the index — commonly because the page duplicates content that exists elsewhere on the site, adds little beyond what's already indexed, or simply didn't clear the bar Google applies to pages it serves to searchers. Resubmitting the same URL for crawling, or repeatedly requesting indexing through the URL Inspection tool, doesn't change this outcome. Google says so directly.
What the report can't tell you
Neither status arrives with a page-specific reason attached — Search Console groups causes into these two buckets rather than diagnosing each URL individually. If a page sits in "Crawled — currently not indexed" for months, the realistic options are to genuinely improve or consolidate its content, check whether it duplicates something else on the site, or accept that not every page a business wants indexed will be. There's no setting, resubmission, or support ticket that overrides an indexing decision Google has already reached.
Where JagaWeb fits
Reading a Pages report correctly, and telling a queue delay apart from a quality decision, is part of the indexing check inside JagaWeb's Essential System Review (RM1,500, currently RM999 until 16 September 2026, one site up to 25 pages). It's a diagnostic look at what's actually happening on your property, not a promise about what Google will do with it next — nobody can offer that honestly. Reach us at sales@jagaweb.my, or on WhatsApp through jagaweb.my.
Ready to verify who owns your website?
Replace uncertainty with a decision-ready ownership and access report. The fixed Ownership & Access Review is RM1,500 before SST and includes a 30-day action plan.