2
7 Comments

I launched RefreshQueue — a Monday decaying-page queue from Google Search Console

Every Monday I wanted a ranked list of the URLs that actually lost the most Google clicks — not a percent drop, not an Ahrefs estimate, not a dashboard I'd forget to open.

SEO agencies already export Search Console. The weekly ritual is still: spreadsheet, gut-sort, Slack a writer a paragraph. The pages that quietly leaked a few hundred clicks don't get a ticket.

RefreshQueue connects read-only GSC. Each Monday it emails the URLs that lost the most clicks, tags the failure mode (CTR-only / collapsed / held), and includes a half-page refresh brief a writer can start from. We never publish to the live site.

https://refreshqueue.com — $49/mo one property, $278/mo ten.

Would love feedback from anyone who assigns weekly refresh work.

on August 30, 2026
  1. 1

    The “ranked list + refresh brief” feels more valuable than another SEO dashboard.

    Curious whether buyers are mainly paying to find the pages faster, or because it removes the manual step of turning that finding into a writer-ready task.

    1. 1

      Mostly the second. Finding the pages is the easy half — Search Console already has that data. What people are paying for is that Monday morning they get a ranked list where each URL already has a failure mode tagged and a half-page brief a writer can start from, so nobody has to sit and turn a CSV into a task. Happy to have you try it on a real property: https://refreshqueue.com/app

      1. 1

        That distinction makes sense. If the real value is turning Search Console data into a prioritized, writer-ready queue, the workflow itself becomes the product rather than the reporting.

        Curious what you’re seeing so far: are users actually acting on the briefs, or are you still validating that part?

        1. 1

          Still validating that part. I have a real property connected and the queue+brief generates, but nobody's paying yet so I don't have writers in the wild acting on these briefs. That's the next proof. If you want to try it on a property: https://refreshqueue.com/app

          1. 1

            That makes sense. I’ll be interested to see what happens once real writers are actually using the briefs.

  2. 1

    Disclosure, I build an SEO tool, so take this as a peer note rather than a customer one.
    The failure mode tagging is the right idea, and I think there is a fourth worth splitting out: cannibalisation. The clicks did not disappear, they moved to another URL on your own property for the same query. That page does not need a refresh brief, it needs a consolidation decision, and sending a writer at it is actively the wrong action.
    It matters commercially because it is the case most likely to waste a customer's money early, which is when they are deciding whether to trust the output at all.
    You can detect it from data you already pull. If URL A lost clicks on query Q and URL B on the same property gained them in the same window, that is a redistribution, not decay.
    Does the current tagging separate a real loss from a move?

    1. 1

      Fair point, and no — right now the tagging is CTR-only / collapsed / held, so a redistribution to another URL on the same property shows up as a loss when it isn't one. That's exactly the case where the brief is the wrong action. The detection you describe is doable with the query+page data I already pull, so I'm adding a cannibalisation/moved tag that routes to a consolidation decision instead of a writer. Thanks for spelling out why it matters commercially early on.