01
Step 1
List the URLs that should be indexed with their publication dates, sitemap inclusion, the internal paths that link to them, their robots and crawl access, the canonical each declares and the indexing status reported for each one.
Back to topic
Spark playbook scenarios · Spark: AI Store Assistant
Investigate why intended pages are not indexed
Pages the merchant published to rank have never appeared in search, and no one has traced where each one stalls. In this case, the immediate task is to investigate why intended pages are not indexed. The workflow should test each URL on the list through discovery, crawl access and canonical selection, recording where the evidence stops.
Topic
Technical SEO and Indexing
Target keyword
shopify pages not indexed
Copyable AI prompt
A prompt you can drop directly into Spark
First replace every [bracketed] placeholder with real store scope and constraints, then add any actual records or data you have, and paste it into your preferred AI assistant or Spark agent. Spark will follow this page's workflow to produce structured output and verification steps.
ai-prompt.txt
Act as a Shopify operations specialist.
Help me investigate why intended pages are not indexed.
My store context is [describe the business, products and target audience].
My scope is [specify the affected products, pages, customers or reporting period]. Use these inputs: [the URLs that should be indexed with their publication dates, sitemap inclusion, the internal paths linking to them, their robots and crawl access, their declared canonical, and the indexing status reported for each one]. Walk each URL through discovery, crawl access, canonical selection and reported status in that order, stop at the first stage where evidence fails, and record the stage as blocked where a record contradicts indexing or as unconfirmed where the records simply run out.
Return a URL-level diagnosis with evidence and follow-up checks, stating for each URL where it failed or is unconfirmed for the specified task.
Show the relevant evidence or before-and-after examples and explain how I can verify the result.
If essential data is missing, ask for it and mark unsupported conclusions as unknown.
Do not invent metrics, product claims or customer facts.
For any publication, message, account or store change, use only connected tools within my explicitly authorized scope and report success only after verification; otherwise provide the draft or proposed steps.How to solve
A recommended resolution workflow
Split the work into input, judgment, and deliverable phases. Verify each step's output before moving to the next.
02
Step 2
Walk each URL through discovery, crawl access, canonical selection and reported status in that order, stop at the first stage where evidence fails, and record the stage as blocked where a record contradicts indexing or as unconfirmed where the records simply run out.
03
Step 3
Deliver a URL-level diagnosis with evidence and follow-up checks stating for every URL the stage at which it failed or that the result is unconfirmed, then confirm that unconfirmed URLs are rechecked against a later report and that the URLs blocked at discovery are both listed in the sitemap and reachable through at least one internal path.
FAQ
Common questions when running this scenario
Cover decision rules, frequent misunderstandings, and required inputs so the team aligns on prerequisites before execution.
How does an unconfirmed URL differ from a blocked one?
A blocked URL has a record that contradicts indexing, such as a disallowed path or a canonical pointing elsewhere, so a cause can be named. An unconfirmed URL simply has no record at that stage yet, so it is reported with the missing evidence and queued for a recheck rather than assigned a cause.
Does sitemap inclusion guarantee discovery?
No. Inclusion only submits the address, and discovery still depends on the URL resolving and being reachable from somewhere the crawler follows. The check therefore records the returned status and at least one internal path, and a URL with neither is reported as failing discovery despite being listed.
Should a page that canonicalises elsewhere be chased?
Not as an indexing problem. When a page declares another URL as canonical, the page meant to rank is the target, so the action is to confirm that target with the merchant and correct the declaration. The URL stays in the report with that note so the same pair is not investigated twice.
Related scenarios
Continue with adjacent or same-topic scenarios
Start with scenarios under the same topic, then expand into cross-topic matches suggested by similarity.
Next step
Want these AI scenarios embedded directly into daily operations?
Ciwi Spark builds Shopify-native AI tools and agents around the workflows merchants actually run: research, ads, translation, and customer support. Stop rewriting the same prompts by hand.