Prioritize observations and verify changes safely

Explanation

Separate fact, interpretation, and action. Use three levels for this short training exercise:

• P0 — blocker: an important public page is unavailable, accidentally blocked from crawling/indexing, or creates a critical user-facing error; first confirm the effect on the exact URL.
• P1 — material mismatch: an important page has a discovery path or opens, but its content, language, canonical/links, or form makes it hard to understand or use. The statement “the search system discovered this page” needs separate confirmation in a panel or verified log.
• P2 — improvement: the issue does not block access or mislead the user; record it and schedule it after blockers.

This is a working scale for the course, not a search-engine standard. When urgency is similar, prioritize an issue with stronger reproducible evidence and greater user impact.

Verifiable criteria:

• Discovery path: a normal HTML link from a checked staging page or a URL in the checked sitemap. Record each source; this shows how a system could find the URL, not that it has.
• System discovery: confirm it in the relevant search-system report or verified crawl logs.
• URL and canonical consistency: the link reaches the expected final URL, the response is correct, the canonical matches the target version, and the sitemap lists that canonical URL. Check the canonical selected by the search system separately in its report.
• None of these checks alone confirms indexing.

Fictional example

The training staging mockup for /robots has these signals: a catalog link goes to an http:// URL that redirects; the HTML canonical points to /robots-v2, while the sitemap contains /robots. This is a P1 mismatch if both pages are available and users can access the content; raise priority only with additional evidence of a block or loss of access. Canonical, robots/noindex, and WAF changes can affect access and site signals, so any real change requires the owner, prior review, and a tested rollback plan.

Practice

Work only on staging or a local copy of example.test:

1. Add a conflicting link/canonical/sitemap state to the staging mockup for /robots.
2. Fill in the log row with raw evidence and the limits of the conclusion.
3. Assign P0/P1/P2 using the criteria above.
4. Propose a correction and the expected observable change, but do not apply it in production.
5. Check the correction in staging using the same methods. Any real production change to robots.txt, noindex, canonical, or WAF first requires a confirmed owner, written impact review, and rollback plan; deployment follows the usual release process. Do not change production for this exercise.

Checklist

• URL, time, tool, and raw evidence are recorded.
• The discovery path (link/sitemap) is separate from confirmed system discovery (panel/verified log).
• URL, redirect, canonical, and sitemap are checked separately.
• Priority is explained by impact and reliability of the observation.
• The exercise and correction were done only on staging/example.test.
• Any future production change names the owner, review, and rollback.
• Before/after checks use the same URL, tool, and conditions.

Common mistake

Changing production robots.txt, canonical, or WAF “just to try it” and checking afterward. Such a change can block a useful section or alter access. Start on staging, with the owner, review, and rollback plan.

Reusable question set and migration baseline

For repeatable AI-answer checks, keep a small, stable set of real customer questions. Store the exact wording, language, region, product surface, date, and account/session conditions. Include discovery questions, comparisons, and decision questions; do not add brand names to every query. A sample for a fictional site is: “What should I check before moving a small documentation site to a new domain?” Record the full answer and cited URLs. This is a measurement protocol, not a recommended prompt count or a promise of citation.

Before a migration, export the old URL list and prepare one row per important URL: old URL, intended destination, redirect status, final response, canonical target, internal links, and sitemap presence. Test the mapping on staging, including query strings and trailing-slash variants that the site actually uses. Compare a representative sample before launch, then recheck the same URLs after launch. Do not replace a redirect map with a blanket homepage redirect; do not change production without an owner-approved release and rollback plan.

For this exercise, the “After-launch result” column is a future baseline only: enter “not applicable — no production release.” Fill it only after an owner-approved release.

The .test host and all rows above are fictional examples.

Primary sources

• URL Inspection in Search Console
• URL Inspection in Bing Webmaster Tools
• How to specify a canonical URL
• Troubleshoot Google Search crawling errors