This guide was prepared with AI assistance using the linked documentation. Code examples are illustrative; verify them against your environment and current API documentation before use.
Start with one URL
A new tutorial is live, but it does not appear in search. First check the exact public URL in a browser without signing in. It should return the intended page, not a login screen, error, or placeholder.
Crawling, indexing, and ranking are separate steps. A page can be reachable and still not be indexed; an indexed page can appear far below other results.
For a content site with many tutorials, check several page types: the index, an article, a downloadable resource, and an unknown URL. A configuration error may affect only one route. Keep the public URL and check date with each observation so the next review can reproduce it.
Check the page the crawler receives
Inspect the response status, title, main heading, and body. Confirm that the article has a stable URL and that internal links use ordinary crawlable anchors. A JavaScript application needs particular care: verify that the important article content is available in the generated HTML rather than relying on a loading screen.
Check mobile and desktop content consistency. Google's troubleshooting guidance explains that mobile content and links matter for indexing.
Test a representative article and the blog index separately. A page might be linked on the index but blocked from retrieval, or a direct route might work while the navigation uses a fragment that is not a separate document URL. Record the HTTP status and the final URL after redirects before diagnosing the content itself.
Use canonical URLs consistently
If several URLs contain the same content, choose the preferred URL and use it consistently in internal links and canonical tags. The canonical should identify the actual public domain and page, not a local development address.
A canonical tag is a signal, not an instruction that guarantees Google's selection. Check the selected canonical in Search Console when you have verified access.
Canonical problems often come from mismatched hosts, slash policies, or a reused homepage URL on every article. Compare the canonical shown in the generated HTML with the address listed in the sitemap and linked from the site. Fix the configuration at its source instead of manually patching one exported file that will be replaced by the next build.
Make the sitemap useful
List the canonical pages you want crawled. Exclude draft pages and duplicates. Confirm that the sitemap itself returns successfully and that robots.txt points to the public sitemap if you use that discovery method.
A sitemap helps a search engine discover URLs. Google explicitly says it does not guarantee indexing or improve ranking by itself. Avoid repeatedly submitting an unchanged sitemap as a substitute for fixing page problems.
Verify a sample of sitemap entries after deployment: each should resolve to the intended public page and return the content it claims to represent. Do not include a test host or a private development address. If the public domain changes, regenerate the sitemap and canonical links together.
User-agent: *
Allow: /
Sitemap: https://example.com/sitemap.xml
# Replace example.com with the verified public host.Use structured data only for visible content
Article structured data can help Google understand details such as headline, author, and publication date. The values should match the page. Do not invent an author, image, review, or modification date to obtain an enhanced result.
Validate the markup, but remember that valid markup does not guarantee a rich result. Check current eligibility guidance before adding a schema type.
Diagnose before changing everything
With Search Console access, inspect the exact URL and the Page Indexing report. Distinguish a crawl failure from a page Google crawled but did not index. Check whether the page offers a useful answer, clear sources, and information that differs from existing results.
Track publication, crawl, and indexing dates separately. Google notes that indexing can take time and is not guaranteed. Keep an audit log of changes so you can tell what was changed before a later result appears.
An indexing report is an observation, not a diagnosis by itself. Read the reported reason and inspect the affected URL. If the page is reachable and crawlable but lacks a useful answer or clear evidence, improve that content before repeatedly requesting another crawl. Keep records of what changed and when so later observations have context.
Inspect one published page
Open the article in a private session. Check its status, canonical link, title, main heading, and body. Follow a normal link from the blog index and confirm the sitemap lists the same public URL.
With access to a verified Search Console property, inspect that URL and record the observation date and reported indexing reason. A live test and an indexed result answer different questions. Allow time for recrawling after fixing a problem.
Sources and further reading
Documentation reviewed November 9, 2026. Verify current model support, limits and pricing before implementation.