Inside RAUM: checking Search Console's Page indexing reasons against the live page

Short answer: Search Console's Page indexing report tells you what Google saw when it last looked. It doesn't tell you what's live now. RAUM takes the reason and the URL from that report, maps the reason onto a fix class and a priority, then fetches the page to see whether the reason still holds. The most valuable output is the word MISMATCH: Google's reason and the live page disagree, so stop and re-inspect before anyone writes a ticket.

Usage basics are in RAUM: how it works. Here's the logic.

What you paste in

Rows of reason and URL from the Page indexing report's example URLs. That's up to 50 unique URLs per run. A row with no reason still runs, and it's judged on the live signals only.

Reason to fix class

The reason text is matched in a fixed order, and the first hit wins:

The order matters. "Soft 404" must be tested before "404", or every soft 404 would be filed as a plain not found.

The live re-check

RAUM fetches each URL, follows redirects, and records the status, final URL, meta robots and X-Robots-Tag, canonical, title, and whether the page is thin (under 200 characters of visible text once scripts, styles and tags are stripped). Then the live signals can overrule the report:

• A live 5xx always wins. The row becomes Server error, P0, whatever the report said.
• Reported 404, but live 200: MISMATCH. It's a stale report or the wrong URL.
• Reported noindex, but live is indexable: MISMATCH. Re-inspect and resubmit.
• Reported soft 404, but live 200 with real content: flagged as a likely stale report. If it's still thin, it stays a P0 soft 404.
• "Alternate page with proper canonical", but live isn't 200: MISMATCH.
• No reason given: the live page decides. 404 or 410 becomes Not found, noindex becomes noindex, a redirect becomes Redirect, a 403 becomes Forbidden, and a different canonical becomes Canonical conflict. A clean, self-canonical 200 gets "nothing to do".

Anything P0, P1, mismatched or unfetchable is a FAIL. Only P2 rows pass.

Edge cases

• Redirects are detected, not counted. RAUM records whether the final URL differs from the one you pasted. It doesn't count hops. For chain length, use DRIFT.
• Robots reasons go to VEXA. RAUM tells you a robots block is reported and shows the live status. VEXA tells you which rule blocks it.
• "Crawled, currently not indexed" isn't a technical bug. RAUM files it as a quality and site-structure job (strengthen the page and its internal links), not a reason to force indexing.

Worked example

Not found (404),https://samplebrand.test/kits/blue-kit
Excluded by 'noindex' tag,https://samplebrand.test/guides/sizing
Soft 404,https://samplebrand.test/search?q=teal
Server error (5xx),https://samplebrand.test/kits/

Live: row 1 200 | row 2 200, no noindex | row 3 200, 90 chars | row 4 200

Rows 1 and 2 are MISMATCH: the report is behind the site, so re-inspect them rather than fixing them. Row 3 is still a thin shell, so it stays a P0 soft 404: return a real 404 or noindex the internal search URLs. Row 4 now returns 200, so it stays a P0 Server error from the report. Check the server logs for when it failed before you close it.

Run it: open RAUM

The money angle

The Page indexing report is where engineering hours get wasted. Teams fix rows that were already fixed, and miss the one P0 hiding among 400 P1s. RAUM's fixed priorities and mismatch flag put the hours on what's still broken.

Indexing gaps on commercial pages are lost revenue you can put a figure on. Value the P0 group in PAYBACK. This is also the backbone of a technical SEO audit.