Auto-Index Extension (Google Search Console)

BlogShoot Auto-Index is a Chrome extension that automates the Request Indexing button in Google Search Console (GSC) for articles published through BlogShoot. You sign in to GSC once; the extension pulls your pending-article queue from BlogShoot and clicks through the URL Inspection flow for each one — manually or on a schedule.

Why a browser extension?

Google’s official Indexing API only accepts JobPosting and BroadcastEvent pages. For normal blog content, the only sanctioned way to actively ask Google to crawl a URL is to open Search Console and click Request Indexing yourself.

The extension automates exactly that click, using your own GSC login session in your own browser. No service accounts, no API workarounds — from Google’s side it looks like what it is: a signed-in property owner requesting indexing.

Install & setup

1. Load the extension (private beta: chrome://extensions → Developer mode → Load unpacked → select the blogshoot-extension/ folder).
2. Sign in to Google Search Console in the same browser, with an account that has Owner or Full user permission on every site you want indexed.
3. Click the extension icon → paste your BlogShoot API key (from app.blogshoot.com → API Keys) → Sign in.
4. Click Check GSC connection. Every workspace should show ✓ with the signed-in Google account’s email.
5. Click Start indexing now, or enable Auto-run (6/12/24 hours) on a machine that stays on.

Which URL gets submitted: BlogShoot uses the real published URL — the permalink returned by your WordPress/Shopify integration when the article was pushed, or, as a fallback, the URL found in your site’s verified sitemap.xml (the one you confirmed during workspace setup) matched by slug. URLs are never guessed, so the extension never submits a 404.

The unwritten rules of Request Indexing

Most “the extension doesn’t work” reports are actually Google enforcing limits it never documents. Read this section before troubleshooting.

There is no visible quota — anywhere

Google does not expose the Request Indexing quota in the GSC interface or in any API. You cannot check how many requests you have left. The only signal is the response after you submit. Community testing puts the cap at roughly 10 requests per property per day, and that number can shrink for new or low-trust properties.

”Oops! Something went wrong” is not (usually) a bug

The dialog “We had a problem submitting your indexing request. Please try again later” (Chinese UI: 「糟糕！出了点问题…请稍后重试」) is Google’s generic refusal. It appears when:

• The daily per-property cap is hit — even though the dialog never mentions a quota.
• You submitted several URLs back-to-back — 6–10 rapid submissions can trigger a soft block that lasts hours to days.
• Your Google account has low trust — see below. This is the one that surprises everyone.
• Google is simply having a bad day (rare, resolves on its own).

The extension recognizes this dialog, stops hitting that property for the rest of the run, and leaves the affected articles in the queue — no retry budget is burned, and they’re picked up again on the next cycle.

New Google accounts often can’t request indexing at all

This is the most important and least documented rule. A freshly registered Google account may be refused on its very first Request Indexing submission, manually, every time — even with verified Owner permission on the property. Google applies account-level trust scoring, and a new Gmail + a new property + a new website is precisely the profile that gets the generic “Something went wrong” refusal.

How to confirm: try one submission by hand in the same browser. If manual submission fails the same way, the extension is not the problem — the account is.

The fix: run the extension under an established, regularly-used Google account — and because the extension uses the GSC session of the machine it’s installed on, that has to be an account belonging to whoever operates that machine. Don’t create a fresh Gmail for automation; it will inherit the same low trust.

1. Pick (or ask the site operator for) a Google account they already use day-to-day.
2. Any existing verified owner can delegate access: in GSC → Settings → Users and permissions, add that account as Owner — no DNS re-verification needed. (Independent DNS verification also works and doesn’t depend on the original owner.)
3. On the machine that runs the extension, create a dedicated Chrome profile signed in to only that account, and run the extension there. The extension’s GSC tabs use the browser’s default Google account; having multiple accounts signed in can route to the wrong one.
4. Submit 1–2 URLs manually on day one to confirm the account is trusted, then enable Auto-run.

”Indexing request rejected” is a different problem

If GSC runs its live test and shows “Indexing request rejected” (「索引编制请求遭拒」), the issue is the page itself: noindex, blocked by robots.txt, a redirect, a 404, or a canonical pointing elsewhere. Fix the page; resubmitting the same URL won’t help. The extension marks these as failed (with the reason) and moves on to the next article.

Pacing expectations

• ~10 successful requests per property per day is the realistic ceiling. The extension caps each run at 10 items with 5–15 s human-like delays, and stops at the first quota-style refusal per property.
• A backlog of 30–40 articles typically drains in 3–4 days on a 24-hour Auto-run schedule. That’s normal.
• Request Indexing is a supplement, not the main channel. Keep your sitemap submitted and fresh in GSC — that’s how the bulk of your URLs get discovered. (Bing/Yandex indexing is handled separately by BlogShoot via IndexNow.)

Troubleshooting

Every submission fails with “Something went wrong” — including manual ones Account-level trust refusal. Switch to an aged Google account with Owner permission (see above).

“‘Request Indexing’ button not found” The signed-in account doesn’t have access to that property, the property selection is wrong, or GSC didn’t finish loading. Run Check GSC connection to see per-site status.

A run reports “N deferred (quota)” The property hit Google’s daily cap mid-run. Deferred articles stay in the queue and are retried automatically next cycle — nothing to do.

“GSC not connected” badge on a workspace That badge reflects the optional GSC OAuth connection inside the BlogShoot dashboard (used to read the exact property name). The extension works without it — what matters is the browser-side GSC login.

Popup shows “Offline · cached” The extension couldn’t reach api.blogshoot.com. Check the network on the machine running the extension.

Privacy

The extension stores your API key locally, injects scripts only on https://search.google.com/search-console/*, and talks only to api.blogshoot.com and GSC. No analytics, no telemetry, and it never reads your Search Console data beyond the indexing flow it drives.

Changelog

v0.1.1 — 2026-06-11

• Recognize GSC’s “Oops! Something went wrong” and “Indexing request rejected” dialogs immediately instead of timing out (90 s per URL) and mislabeling the failure.
• Quota-style refusals are now treated as transient: the article keeps its retry budget, stays in the queue, and the rest of that property’s items are deferred to the next cycle (“N deferred (quota)” in the run summary).
• Failure logs include the exact text of the GSC dialog for diagnosis.
• Cancel now takes effect immediately, even mid-submission.

v0.1.0 — 2026-06-07

• Initial release: manual + scheduled runs, queue pulled from BlogShoot, per-article status reporting.