Check in bulk which of your pages Google has actually indexed

Build me an indexing triage console for Google Search Console. Search Console only lets me inspect one URL at a time, so I want a screen where I can throw a whole batch of URLs at it and see, in one table, which pages Google has actually indexed and which it has quietly skipped.

At the top of every view there is a property picker. A handler calls Google Search Console List Sites to populate it, and the selected siteUrl is passed verbatim to every other handler, because an inexact property string silently returns empty data instead of erroring. Remember the last selected property per viewer so the app opens where they left off.

The main surface is the batch inspection view. It has two ways to load URLs: paste them into a textarea (one per line, deduplicated and trimmed), or load them from the property's submitted sitemaps. Once a batch is staged, show the count, an estimate of how long the run will take, and a Run inspection button. The run itself loops Google Search Console Inspect URL across the batch in a handler, writing each result into app storage as it lands, and the UI shows a live progress bar with the number completed, the number remaining and the current URL.

Throttling matters here. Google caps URL inspection at 2,000 checks per day and 600 per minute per property, so the run must pace itself under both limits, track how much of the daily allowance this property has already consumed, and display that remaining budget before the user commits to a batch. If a batch is larger than the remaining daily allowance, warn before starting and offer to inspect as many as will fit. Treat a 429 response as quota exhaustion: stop the run cleanly, keep every result already collected, and show a plain message saying the daily quota is used up and the rest of the batch can resume tomorrow, with a Resume button that picks up exactly where it stopped.

Results land in a sortable, filterable table with one row per URL. Columns: the URL, coverage state, indexing verdict, Google-selected canonical, my declared canonical, last crawl date, mobile usability status and rich results status. Every column sorts, and there is a free-text filter on the URL. Above the table put one-click filter chips for the three views I care about most: not indexed, crawled but not indexed, and canonical mismatch (Google-selected canonical differs from the declared one). Each chip shows its own count. Colour-code the verdict column so a bad row is obvious at a glance, and let me select rows with checkboxes.

A second panel lists the property's sitemaps. Populate it with Google Search Console List Sitemaps, then Get Sitemap for per-sitemap detail, showing for each one: the sitemap path, its type, last submitted and last downloaded dates, submitted versus indexed page counts, and its error and warning totals. Flag any sitemap with errors, and any where indexed is far below submitted. Note that the errors, warnings, contents.submitted and contents.indexed fields sometimes come back as strings, so cast them to numbers before comparing or summing, and sitemap feedpath values must be URL-encoded when used in a request path.

Each sitemap row gets a Resubmit sitemap button backed by Google Search Console Submit Sitemap. That call returns an empty body on success, so treat the HTTP status as the signal, then show a confirmation toast and refresh the row. Because Google's sitemap counts, especially the indexed count, can lag the live state by several days, every number in this panel and every inspection result in the table must be date-stamped with when it was fetched, and the panel should carry a short line explaining that these counts are Google's last known figures rather than a live reading.

Every table row gets a File fix ticket button that creates a Linear issue through Create Issue, prefilled with the URL in the title and a description carrying the coverage state, indexing verdict, Google-selected canonical, declared canonical, last crawl date and the date the inspection was run. Let me pick the Linear team once in settings and reuse it. Once a ticket exists for a row, show its identifier inline and link out to it instead of offering to create a duplicate.

The app also has a Diagnose these URLs button that kicks off a background agent over the currently flagged or selected rows. The agent reads the inspection results, groups the URLs by likely root cause (canonical conflicts, soft-404 patterns, orphan pages that appear in no submitted sitemap, thin or duplicate clusters), and can call Google Search Console Inspect URL again on a few representative URLs and List Sitemaps to confirm whether a page is actually orphaned. It then writes a prioritized remediation plan back into the app, one section per root cause, ordered by how many URLs each cause explains, with the concrete fix and the affected URLs listed under it. Finally it files one Linear issue per root cause using Create Issue, with the grouped URL list and the recommended fix in the description, and adds a comment through Add Comment to Issue linking back to the plan in the app. One grouped issue per cause, never one issue per URL.

The agent's output lands in a Diagnosis panel inside the app, showing the run status while it works and then the plan itself, with each root cause section linking to the Linear issue it filed and to the matching filtered view of the table. Keep past diagnosis runs so I can compare this week against last week.

Persist inspection results per property so the table survives a reload and I can see how a URL's verdict has changed since the previous run, highlighting rows whose verdict moved since last time. Handle the obvious failure modes plainly: no verified properties on the account, a property the account cannot access, an empty sitemap list, and a run interrupted partway through.