Launched this week
GSC Resolver Engine
Google Search Console errors, explained clearly.
17 followers
Google Search Console errors, explained clearly.
17 followers
GSC Resolver Engine is a local-first decision library for decoding Google Search Console warnings without AI, crawling, login, or API access. It includes 178 governed resolver states across indexing, sitemaps, Core Web Vitals, HTTPS, rich results, manual actions, security, removals, and report-lag issues. Paste or select a GSC message and get a plain-English meaning, likely cause, fix path, validation step, stop condition, and client-ready report output.
A "reverse lookup" feature where you paste a URL or batch of URLs and it tells you every GSC warning each one has triggered across all 178 states would be incredibly useful for auditing sites at scale. Right now it's all message-to-meaning, but going the other direction would round it out nicely.
@talha6u9u That’s a sharp idea, Talha — and you’re right, URL-first auditing would round it out.
The current version is intentionally message-to-meaning because I wanted to keep it offline, local-first, and free from GSC login/API/crawling requirements.
A safe next version of this could be a manual or CSV-assisted URL workspace where users paste exported GSC rows, map URLs to known warning states, and then generate grouped audit guidance without the tool needing account access.
I like the direction though. URL-to-warning grouping would be a strong agency workflow.
ran a few of my own stubborn gsc warnings through it and the plain english explanations actually matched what i was seeing in search, which is rarer than you'd think. the validation step alone saved me a back and forth with dev.
@edanuri1gw Appreciate that, Edanur. That’s exactly why I built the validation step—GSC warnings can sound urgent without clearly showing whether there’s a real issue or what actually needs to happen next. Glad it matched what you were seeing and saved you another back-and-forth with dev.
Runs fully offline with no login feels like a rare find these days, and the resolver states are genuinely specific instead of the usual generic SEO advice. Caught my sitemap warning meaning in one click.
@nihatsaydak7de Really appreciate that, Nihat.
That was the exact goal — not another generic SEO checklist, but something specific enough to help when you’re staring at an actual Search Console warning and need to know what it means fast.
Glad the sitemap warning clicked in one step. That’s the kind of use case I built it for.
Tried it on a sitemap warning I had stashed and the plain-English breakdown was spot on, plus the client-ready report saved me from rewriting the same explanation again.
@kaanwuwi Really appreciate that, Kaan.
That sitemap use case is exactly one of the reasons I built it. A lot of GSC warnings are not hard to understand once they’re explained clearly — the problem is having to rewrite the same explanation over and over for clients.
Glad the plain-English breakdown and report export helped.
How does the engine actually decide between the 178 resolver states when a real GSC warning could match more than one category at once?
@arif1grq Good question, Arif.
The engine does not try to “guess” from live account data. It uses governed resolver states with category, label, match terms, issue family, impact, risk, fixability, and stop-condition logic.
When a warning could overlap categories, the workflow is designed to keep the user grounded in the visible GSC message first, then the resolver explains related causes and escalation paths.
So for example, an indexing issue may involve canonical, robots, sitemap, or quality signals — but the selected state gives the primary interpretation first, then points to what should be checked next.
The goal is not automatic diagnosis from hidden data. It’s consistent decision guidance from the actual warning the user is seeing.
the offline-first angle is genuinely clever, especially for agencies handling sensitive client data. love that each of the 178 states includes a stop condition, thats the kind of detail that usually gets skipped.
@evren179375 Thanks Evren, I appreciate that.
The offline-first part was important to me because a lot of SEOs and agencies handle client data, and not every tool needs another login, crawler, or cloud dashboard.
And yes — the stop condition was a big part of the build. A lot of wasted SEO time comes from not knowing when an issue has been handled enough, when to wait, or when to escalate.