Practice investigations without risking a production site
Work through deterministic fixture incidents where every response, URL, timeline, and consequence is invented for training.
SEO Incident Simulator
Free, no signup. Practice a defensible technical SEO investigation with deterministic evidence, plausible decisions, and clear operational consequences. Every run is a hypothetical fixture case—not a live audit or a prediction about your site.
- 1Choose a caseStart with a bundled incident.
- 2Inspect evidenceReview the unlocked fixture records.
- 3DecideChoose the next diagnostic action.
- 4DebriefCarry the method into a real tool.
30 bundled cases · no URL, upload, or live check
Simulated incident · fixture data
Migration traffic collapse
A site relaunch is followed by a sharp organic-landing-page decline. Work from the affected URLs outward before changing sitewide settings.
Difficulty: intermediate
What this lab practices
- Establish a launch baseline
- Prioritize lost landing pages
- Flatten redirect chains before measuring recovery
Inspect
Fixture evidence
Each source is simulated. Review the available records before choosing a next step.
Decision trail (0) decisions made
4. Current fixture evidence
Select an evidence source
Decide
The launch date and landing-page drop line up. What should the incident team do first?
Inspect the available fixture evidence before choosing an action.
Runs entirely in your browser — nothing you paste is uploaded or stored. Progress may be saved in this browser as scenario and decision IDs only; fixture bodies and visitor input are never stored. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.
Simulated incident · fixture data: Every fact in these labs is invented for training. Endings connect the diagnostic method to real tools, but they do not claim a live observation, Google-only status, or business outcome.
How to use it
- Choose a scenario and read its learning objectives before making a decision.
- Inspect the available fixture evidence instead of guessing from the incident summary.
- Select the smallest safe next action. Consequences unlock evidence, advance the investigation, or end the path.
- At an ending, compare the evidence you found, the corrective action, and the suggested verification tool.
- Restart or rewind to test why another path is weaker. Completion is a training sequence, not a performance score.
Example scenario Fixture data
The guided Canonical conflict and index loss lab inventories five disagreeing signals for a fictional product URL. Its shortest defensible path is:
Find: HTML and HTTP canonicals disagree; navigation points to a redirecting /shop/ URL; the sitemap and redirect agree on /products/.
Fix: use /products/widget-a consistently in HTML and HTTP canonicals, sitemaps, and internal links while preserving the one-hop redirect.
Verify: retest the public signals with the Canonicalization Checker, then use Search Console for Google's selected canonical.
Every URL, date, response, and outcome in that report is invented fixture data.
What the simulation shows
An evidence artifact contains labeled facts and optional rows with a fixture observation date. A consequence explains what a choice establishes or leaves uncertain. An ending separates find, fix, and verify, records missed evidence, and names the shortest diagnostic path. It does not predict traffic recovery, crawling, indexing, or rankings.
How it works
Thirty versioned JSON scenarios define their initial step, evidence artifacts, choices, consequences, unlocked evidence, and endings. The browser-only simulator applies deterministic state transitions, records inspected evidence and decisions, and can save only scenario and decision IDs locally. No live URL, API, model, or Search Console property is queried.
Features
- Guided, intermediate, and advanced technical SEO incidents.
- Evidence spanning headers, redirects, canonical signals, crawl samples, traffic series, rendered HTML, and timelines.
- Rewindable decision paths with explicit operational consequences.
- Find → fix → verify endings linked to the relevant public tool.
Limits of the simulation
- All evidence and outcomes are authored fixtures, not measurements from your site.
- The scenario graph cannot represent every valid investigation sequence or organization constraint.
- Completing a lab does not certify production readiness or prove a fix will work elsewhere.
- Google-only states remain outside public verification and are called out as such.
Frequently asked questions
Is this a diagnosis of my website?
No. Every incident, URL, response, timeline, and outcome is fixture data bundled with the page. The simulator does not fetch your site or use your Search Console data.
Does completing a scenario prove the same fix will work on my site?
No. The labs teach a diagnostic sequence and identify what public evidence can establish. Apply the linked tools and your own evidence before making a production change.
Why does the simulator distinguish public checks from Search Console?
Status codes, headers, redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., and page markup are observable public evidence. Google’s crawl, selected canonical, and index decisionsStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. require a verified Search Console property and are not inferred by these fixtures.
Site passport Local context for this saved site
Local data
Saved targets, named lists, and recent check summaries remain only in this browser.
Rate this tool
Feature requests for SEO Incident Simulator
Upvote what you want most. New ideas can be submitted from the floating Feedback menu; requests appear here once approved, and the most-wanted rise to the top.
You won't be emailed about that request anymore.
Loading…
➕ Request a feature
New requests are reviewed before they appear here.
Where this tool helps
Common use cases
Learn to inspect evidence before choosing a fix
Review headers, redirects, canonical signals, crawl samples, rendered HTML, or timelines before the simulator unlocks a decision.
Compare defensible and incomplete diagnostic paths
Rewind decisions to see why a partial change, unsupported assumption, or overclaim leaves important evidence unresolved.
Train Find → Fix → Verify handoffs
Finish each case with a bounded finding, the corrective action, and the real public tool or Search Console step needed for verification.
Prepare teams for uncommon technical SEO incidents
Practice thirty cases across indexability, crawl controls, redirects, rendering, hreflang, sitemaps, caching, DNS, bot verification, and faceted navigation.
Watch the full workflow
SEO Incident Simulator walkthrough
Read the transcript
SEO Incident Simulator
Hi, this is the SEO Incident Simulator. It is a safe practice area for learning how to investigate technical SEO problems without touching a real website. I’ll explain how the lab works, walk through one complete case, and show you how to compare a strong answer with a weaker one.
Step 1
A technical SEO incident is a website problem that can affect how search engines crawl, understand, or index pages. This simulator gives you thirty practice cases covering problems such as redirects, sitemaps, canonicals, rendering, and crawling. Nothing here scans or changes a real website.
Step 2
You can use it to train a new team member, practice before changing a production site, or learn why an easy-looking answer may be incomplete. It is also useful for rare problems you may have read about but never handled. Each case teaches the same habit: find the evidence, choose a fix, and verify what happened.
Step 3
Before we begin, notice what is missing. There is no place to enter a URL, upload a file, or connect Search Console. That is intentional. This page teaches the investigation process with invented examples. After the lesson, you can open the suggested real tool and check a site you are authorized to inspect.
Step 4
Every case has four simple steps. First, choose a case. Second, inspect the evidence the case gives you. Third, decide what to do next. Fourth, read the debrief, which explains what you found, what to fix, and how to check the result. Your browser can remember which case and decisions you selected.
Step 5
We will use the guided canonical-conflict case. A canonical is a signal that says which URL should represent a page when several URLs are similar. In this fictional example, different signals point to different product URLs. Our job is to list those signals, choose one intended URL, and avoid claiming more than the evidence proves.
Step 6
The decision buttons begin disabled, so we cannot guess our way through the case. Let’s open “Canonical signal inventory.” It shows five places that can point to a preferred URL: the page’s HTML, an HTTP response header, the sitemap, internal links, and a redirect. Here they disagree, and every value is clearly labeled as fictional fixture data.
Step 7
Now choose the first option: inventory every public signal before editing anything. This matters because changing only one canonical tag could leave the other conflicts in place. The simulator explains that consequence, then unlocks two more records: “URL behavior” and a “Representative crawl sample.”
Step 8
Open both new records. The old shop URL returns a three-oh-one redirect to the products URL. A three-oh-one means the move is intended to be permanent. The crawl sample shows that navigation still links to the old shop address, while the sitemap uses products. We can now see the mismatch, but we still do not know which URL Google selected.
Step 9
The evidence supports one focused correction. Choose the products URL as the intended address, then point the HTML canonical, HTTP canonical, sitemap, and internal links to it. Keep the one-step redirect from the old shop URL. The simulator then moves to verification, because proposing a fix is not the same as proving it worked.
Step 10
For the final decision, retest the public signals you control, then use Search Console to check Google’s reported canonical. Here is the payoff: the debrief separates the finding, the fix, and the verification step. It links to the real Canonicalization Checker, but it never pretends this practice case changed Google’s index.
Step 11
The completed debrief is a useful handoff. Under “Find,” it lists the conflicting canonicals and the navigation link that passes through a redirect. Under “Fix,” it names the signals that should all use the products URL. Under “Verify,” it asks for a reachable two-hundred response and matching public canonical signals before checking Google-only information.
Step 12
One feature I especially like is “Rewind one decision.” Use it and choose the weaker claim that matching tags prove Google selected the URL. The simulator marks the outcome unresolved. Canonicals are hints, not commands, so a public page check cannot prove Google’s private decision. Search Console is the correct place to check that.
Step 13
Use “Choose a fixture case” to load another lesson in the same interface. The catalog includes guided, intermediate, and advanced cases. There is no score or leaderboard. Success means you can explain what the evidence shows, what it does not show, and why your next action is safer than the alternatives.
Step 14
Finally, keep the limits in mind. These cases cannot represent every website, company rule, or valid investigation path. Their outcomes are written examples, not measurements or predictions. Treat the debrief as a learning checklist, test the smallest safe change on the real site, and use Search Console only when the answer depends on Google’s private data.
Look first. Fix carefully. Check your work.
That is the full practice loop: understand the problem, inspect the evidence, choose the smallest sensible fix, and verify the result. When you work on a real site, use the linked checker with evidence you are allowed to inspect, and remember that some Google decisions can only be confirmed in Search Console.
Common issues & how to fix them
- Error Canonical signals point to different URLs Fix: Select one preferred URL and align canonical tags, redirects, sitemap entries, and internal links to it.
- Warning Migration redirects use extra hops Fix: Replace multi-hop migration redirects with one direct 301 from each legacy URL to its final destination.
- Error Robots policy blocks affected pages Fix: Remove or narrow the production robots.txt rule that blocks pages required for recovery.
- Error Noindex shipped to production Fix: Remove the production noindex directive and verify it is absent from both raw and rendered HTML.
- Warning Sitemap and canonical sets drift Fix: Regenerate the sitemap from canonical live URLs and remove stale, redirected, or noncanonical entries.