A practical indexing diagnosis for Saudi business websites, covering URL inspection, final HTML, canonicals, crawlable links, useful service pages, and verification.
Start with the exact canonical URL
Inspect the final URL you want in search and record its indexing status, last crawl, fetch result, indexing permission, and Google-selected canonical. The aggregate report can lag behind individual URL inspection and may include subdomains or old routes. A total alone cannot diagnose a particular service page.
Keep a baseline with the URL, reported reason, crawl date, and repair date. An accepted indexing request confirms queue submission; it does not confirm inclusion in the index.
Separate access failure from an indexing decision
If fetching fails, review response codes, robots directives, authentication, and firewall rules. Public service content should be available without an account. Test a nonexistent route too: it should return a genuine 404 rather than a successful-looking homepage.
If the fetch succeeds and indexing is allowed, investigate the canonical, content, and links. A successful live test demonstrates current accessibility. It does not establish that Google will retain the page or show it for a particular query.
Validate HTML after the final build transformation
During a static-site audit, an article returned 200 and had a valid title and canonical. A breadcrumb transformation nevertheless removed the closing header and opening main landmark. The article heading appeared inside the theme button and the browser looked almost empty. Metadata checks had missed the broken structure.
The repair constrained the transformation to the breadcrumb and prevented it from crossing the end of an SVG. Final-output checks then verified a separate main landmark, one heading, intact navigation controls, and ordered header, content, and footer boundaries. Inspect readability with and without JavaScript; essential article text should remain available.
Resolve canonical versions before changing URLs
Compare HTTP and HTTPS, www and the bare domain, and the final destination after redirects. Secondary versions should lead directly to the chosen URL, which should agree with canonicals, sitemaps, and internal links. Requesting an old redirect is different from requesting its destination.
When Google selects another canonical, inspect that page and the signals pointing to it. A separate English translation should retain its language relationship rather than redirect to Arabic. A genuine migration needs a documented old-to-new URL map.
Give discovered pages a crawlable route
For a discovered page that has not been crawled, review crawl statistics and host health before assigning a cause. Check for ordinary HTML links from known pages and connect the service, guide, and case study where they answer the same customer need. A JavaScript-only interaction is not a substitute for a crawlable link.
Include final, indexable canonical URLs in the sitemap and update lastmod after a real change. A smaller sitemap can define a commercial reporting group in Search Console. Splitting a sitemap does not force crawl priority or indexing.
Make crawled pages useful and reviewable
The crawled-but-not-indexed label does not disclose Google’s internal assessment. Check whether the page serves a distinct purpose and provides scope, deliverables, real examples, and information that helps a customer choose. Do not infer a penalty or a particular quality judgement from the label alone.
Connect service pages to case studies that describe goals, delivery decisions, scope, and a public implementation. Avoid unsupported outcome metrics and interchangeable district pages. There is no magic word count: a specific example can be more useful than a long generic explanation.
From this website: a source revision lost during publishing
While reviewing this website's release on 20 October 2026, I found a final transformation that fixed every article's review date at 3 October. Updating the source date alone did not survive publishing: the transformation overwrote structured metadata and visible dates, and the sitemap then inherited the result. This is why the deployed output needs checking after the entire build pipeline.
The repair preserves a newer article revision while retaining the earlier editorial cleanup date for unchanged articles. A final-output check now compares source revisions with machine-readable visible dates, structured data and sitemap lastmod in both languages. The implementation can be reviewed in this website's repository. An accurate lastmod describes a real change; it does not demonstrate recrawling or indexing.
Verify the release before measuring search outcomes
Repair access, canonical ambiguity, broken links, and damaged content before expanding the publishing schedule. Check the live output and sitemap after deployment. Use live inspection for materially changed pages; repeated requests for the same URL do not accelerate crawling.
Track three separate outcomes: a crawl after the repair, an indexing-status change, and relevant search impressions or clicks. They may change at different times. A passing build and an accepted request are implementation evidence, not substitutes for actual indexing.
