PASS only has meaning within the field that contains it. A PASS value for indexStatusResult.verdict is a positive result for the indexed page. A PASS inside richResultsResult applies only to the rich-result check. It does not prove indexing, search visibility, rankings or traffic.
The URL Inspection API reports data about Google’s indexed page version. It does not run Search Console’s live URL test. Keep the original response structure. Do not group every PASS value together. Record the time of the API check and Google’s last crawl time. Also record its selected canonical and any separate live-page result. Each item answers a different question. The worksheet below helps you read and save each result. Google does not require this format.
What does PASS mean in the URL Inspection API?
PASS means the inspected page or item passed its specific check. Always read the parent field that contains the verdict. This is a basic technical SEO practice. It also prevents mistakes when comparing Search Console and Google Analytics reports. A PASS cannot answer questions outside its own field.
Google uses the same verdict type in several response areas. Its UrlInspectionResult documentation defines indexStatusResult.verdict as the main index-status check. The documentation puts richResultsResult in a separate check. Sharing the word PASS does not remove that difference. Each result still needs its full field path.
Suppose indexStatusResult.verdict is PASS. You may report a positive result for the indexed page when the API check ran. You cannot report that the page ranks. You also cannot claim the current page is indexable. The result does not promise visibility for any query. Google’s URL Inspection help says inclusion does not ensure appearance in search results.
Example only: an inspection for https://example.com/guide shows PASS under the rich-results check. Its index-status result does not prove inclusion. The accurate note is “rich-results check passed for the relevant item.” Do not write “URL indexed.” If the results were reversed, an index-status PASS would not confirm every structured-data item. It would not show that each item qualifies for a rich result.
A clear report shows the complete path: indexStatusResult.verdict = PASS. A weak report shows only verdict = PASS. The complete path ties the verdict to its check. The shorter label can mix separate tests. It can also overstate what Google reported.
Which URL Inspection verdict should you read first?
Read indexStatusResult.verdict first when checking the indexed-version check. Then review each supporting field and separate check. This order improves an SEO audit evidence checklist. It also keeps facts clear in SEO reports. Connect every finding to the field that produced it.
Your question decides which field to read. For index status, begin with indexStatusResult. For rich-result items and whether an item qualifies, read richResultsResult. The mobileUsabilityResult field is deprecated. Do not use it for a current mobile-usability check. The response contains several checks, each with its own result.
Use this order when reviewing an inspection. Keep every item in its own field. Do not replace missing values with assumptions:
- Confirm the exact inspected URL and Search Console property.
- Record the time of the API check created by your own workflow.
- Open
indexStatusResultand record its exact verdict. - Capture
coverageState, crawl time and both canonical fields without rewriting them. - Record rich-results and other checks in separate columns.
- Run and time stamp a separate live-page check if the current page matters.
Google’s index.inspect reference says the inspected URL must belong to the named Search Console property. Store the property beside the inspected URL. A mismatch may point to a request or access problem. It does not show whether Google indexed the page.
Example decision: your record for https://example.com/services shows an index-status PASS. It contains no rich-results data. Report the index check exactly as returned. Mark rich-results data as absent or unavailable, based on the response. Never create a rich-results PASS from the index verdict.
Why can an indexed URL result differ from the live page?
The indexed result describes the page version stored by Google. The live page may have changed since Google’s last crawl. Compare both states during website migration SEO and SEO reviews for a new website. Redirects, canonical tags and page content can change quickly during either process.
Google says the API reports details about its indexed version. The API cannot test a live URL’s indexability. Search Console’s interactive live test answers a different question. Your own HTTP fetch can check current access and markup. However, that fetch cannot replace Google’s live test. It also cannot replace an indexed-status result.
Example only: Google last crawled https://example.com/old-service before you added a redirect to https://example.com/new-service. The API may still describe the older indexed version. A current browser or server check may find the redirect. Both findings can be correct. They describe different versions at different times.
Record the difference instead of using one result to replace another. State that the indexed response reflects its reported crawl context. Then describe the separate live result and its check time. This wording shows that the page changed. It does not claim Google has processed the change.
The same rule applies to robots directives and canonical tags. It also applies to status codes and body content. A current HTTP 200 response means the server answered that request. It does not prove Google crawled that page version. It also does not prove selection, indexing, display or ranking.
How do crawl dates and canonical URLs change an index status check?
Crawl and canonical fields show the context behind the verdict. Include these fields in a technical SEO audit. Keep their exact dates and wording in monthly SEO reports. You can then compare records without mixing old data with recent changes. This context helps limit false conclusions.
lastCrawlTime ties the indexed data to Google’s reported crawl. The time of the API check shows when you requested that data. These times describe separate events. Google may have crawled the page before your inspection. Changes made after that crawl may not appear in the indexed version.
userCanonical shows the site’s declared canonical when data is available. googleCanonical shows Google’s selected canonical when supplied. Agreement can make the result easier to understand. It does not establish how the page ranks. A difference needs further review. Check duplicates, redirects, internal links, sitemaps and page signals. Do not assume one tag caused Google’s choice.
Example only: you inspect https://example.com/product?color=blue. The recorded user canonical is https://example.com/product. Google’s selected canonical is also the clean URL. Read a PASS for the variant with that choice in mind. Do not report the parameter URL as a separate selected search result. Its index-status check alone does not support that conclusion.
Another example record may show a self-canonical in the live HTML. The indexed response may show another user canonical from an older crawl. The safe conclusion is simple. The indexed and current data differ. Wait for new data or review the cause. Do not replace Google’s stored field with the live value.
What five fields belong in an index status record?
Keep five data groups in each index status record. Save the exact result object, time of the API check and last crawl. Add URL and canonical context, plus a separate live-page check. This supports useful SEO KPIs without treating status as performance. It also keeps server-log analysis separate from Google’s crawl report.
The “five fields” are practical data groups. They are not five Google-defined properties. Keep the raw result object because nested paths give values their meaning. Add a timestamp from your own workflow. It shows when your system stored the response. Keep the live check separate because the API does not perform one.
| Evidence group | What to record | Decision it supports | What it does not prove |
|---|---|---|---|
| Exact result object | The unflattened API result and exact paths, such as indexStatusResult.verdict. | Shows which check produced each value. | That every field belongs to the same test or purpose. |
| Inspection time | The time when your workflow requested and stored the result. | Allows you to order and compare later records. | That Google crawled or indexed the page at that time. |
| Last crawl | lastCrawlTime, if returned, with no guessed replacement. | Shows the reported crawl context for the indexed version. | That the current page matches that version. |
| URL and canonicals | Inspected URL, property, userCanonical and googleCanonical when present. | Shows which URL was inspected, declared and selected. | Guaranteed search appearance for the inspected URL. |
| Separate live check | Check type, time, resolved URL, HTTP status and observed directives. | Describes what the current page returned during that check. | Google’s indexed state, rendering decision or future processing. |
Example worksheet entry: the row for https://example.com/advice stores an inspection at 10:00 UTC. It also stores the exact result object and reported crawl time. The row includes canonical values and an independent fetch at 10:05 UTC. These times are examples, not an actual SCALZ.AI result. The record shows the order of events. It does not claim the fetch affected indexing.
Do not keep one “indexed: yes/no” cell as your full record. That cell hides canonical choices and older crawl context. It can also hide missing fields. If stakeholders need a summary, create a careful data-based label. Keep the original paths so you can explain later changes.
How should an index status check handle missing data?
Treat missing data as unknown. Never convert it to PASS, FAIL or “not indexed.” This rule matters during crawled, currently not indexed troubleshooting. It also matters in SEO audit planning. An invented value can direct work toward the wrong page, system or problem.
A field may be absent because it does not apply. The API may not have returned it. The result may also fail to establish that value. These cases differ, so avoid guesses. Store a machine-readable null. Add a plain note, such as “not returned,” when the data supports it.
Keep an absent field separate from a documented enum value. A returned NEUTRAL or FAIL verdict is data. Google documents PARTIAL as reserved and no longer used. An absent verdict is missing data. An API error is another case. It describes the request or access path. It does not describe the page’s index status. Store the error separately.
Example only: an inspection of https://example.com/private-area returns no useful result. The request lacks access to the named property. Record “inspection unavailable due to request or property access” when supported. Do not record “not indexed.” The URL must belong to the specified property.
Use the same rule for missing live-check data. If nobody tested the current page, write “not checked.” Do not copy the indexed response into the live column. A successful current fetch cannot fill a missing Google verdict. Unknown values can look untidy. Still, they keep decisions tied to data.
How should an index status review separate access from usefulness?
Write separate findings for access, crawl data and index check. Also separate canonical choice, search appearance and usefulness. A focused SEO content audit can review usefulness. A defined on-page SEO scope can review page elements. Neither process proves that Google indexed the page.
Access asks whether a request can reach the resource. It also records the response received. Crawl data asks whether Google reports a crawl and its date. Index status describes Google’s view of the indexed version. Canonical choice names the URL Google chose to stand for the page. Search appearance and rankings are later outcomes. They vary by query and context.
Usefulness is a separate editorial judgment. Ask whether the page has a clear purpose. Check whether it helps its intended visitor. Review whether it adds useful facts beyond similar pages on the site. These checks can show what needs work. They cannot turn a verdict into an indexing guarantee. An indexed page may still be thin, old or irrelevant.
Example decision: https://example.com/tax-guide returns HTTP 200 during a current check. Its stored response has an index-status PASS and the expected canonical. Its facts are now outdated. Keep the successful technical findings. Open a separate content task. Do not rewrite the older index data as a failure.
Another page may help visitors but remain blocked. Google may also group it under another canonical. Content quality cannot override that technical state. First decide whether the page should be available and indexed separately. Then align access, canonical signals and content with that goal. This order avoids work on a page that should not appear alone.
Next, export one inspection and keep its exact field paths. Complete all five data groups before assigning a status. If you need help turning the record into a practical technical review, contact SCALZ.AI.
Sources: Google’s URL Inspection index.inspect reference, UrlInspectionResult field documentation and Search Console URL Inspection help.
Frequently asked questions about URL Inspection API PASS
Does indexStatusResult.verdict PASS guarantee that a URL appears in search?
No. It is a positive result for that field of the indexed version. Google says inclusion does not ensure appearance in search results. Query relevance, canonical choice and other search systems remain separate. Read the verdict only within its field and reported context. Do not use it as a promise of search visibility or ranking.
Does richResultsResult PASS mean the page is indexed?
No. That PASS belongs only to the rich-results check. It shows validity for that check or item. It does not prove inclusion in Google’s index. Record the full path, such as richResultsResult.verdict. For the inspected URL’s index status, review indexStatusResult.verdict separately. It has its own meaning and context.
Can the URL Inspection API test the current live URL?
No. Google states that the API reports details about its indexed version. It cannot perform a live URL test. Use Search Console’s live test for current Google data. You may also run a clearly labeled independent page check. Store every live result separately. Each check answers a different question.
Does an HTTP 200 response prove that Google indexed the page?
No. HTTP 200 means the server successfully answered one request. The result applies to that request at the check time. It does not show that Google crawled that page version. It also does not prove canonical selection, indexing, search display or ranking.
What should I record when lastCrawlTime is missing?
Record the value as unknown or not returned. Do not replace it with the time of the API check. Do not use a server-log time stamp or live-check time. Those times describe separate events. Keeping them apart prevents a current observation from becoming false proof of a Google crawl.
Does requesting another inspection trigger indexing?
An inspection request retrieves available details. Do not treat the request as proof that indexing began. Repeated API polling does not prove processing either. Review the returned data instead. Check whether access and canonical signals match the page’s purpose. Wait for a later observation before claiming Google processed a change.
How this guide was prepared: AI assisted the draft and illustration. The text was checked against the linked primary sources. Tim Francis is the named editorial lead. Examples are hypothetical and do not describe a client result or a first-hand test.
