shouldivibecodeit

Should I vibe codeWooRank?

Website reviews, crawling, keyword tracking, competitive analysis, and reporting

A box where strangers type a URL and your server fetches it isn't a lead magnet. It's SSRF with a marketing page.

?

Their verdict, the Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.

Can you build it?asked by canivibecodeit.com ↗KINDAweekend project · multi-day
?

Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.

Should you ship it?asked by usDEMO ONLYvibe the v0, throw it away.

The honest answer

why the verdict is what it is

Split WooRank the way its own navigation does and the halves have different answers. The marketing half — crawl a site, tabulate titles, canonicals, status codes and Core Web Vitals, print a score — is Lighthouse behind a queue, and an agent will have something credible running by Sunday evening. The sales half is where it stops being a script. WooRank's lead-gen tool is a box you put on your own website into which a stranger types a URL and gets an instant audit, and building that means operating a public endpoint whose entire purpose is to make your server fetch an address somebody else chose. That is the canonical shape of SSRF, and the second thing anyone types into it will be a cloud metadata address. Everything downstream is an unsolicited crawl of a third party's site, from your IP, at whatever rate your worker pool allows. Then there is the output: a number out of a hundred, on a white-label PDF, under a client's logo. That is advice, and people act on advice. None of this is beyond an agent — it just isn't a weekend, and it is emphatically not a thing you leave running unattended while you go on holiday.

What actually breaks

not "if". the specific failures.

  • The audit-anything endpoint, which gets handed 169.254.169.254 and localhost within days of being linked anywhere, and which fetches them because nobody wrote the allowlist
  • Your server's IP reputation, after the queue works through a few thousand pages of a site whose owner never asked to be crawled and whose WAF has a long memory
  • The crawl budget, on the first site with faceted navigation, where a 2,500-page cap meets 250,000 filter permutations and the job simply never ends
  • Rank tracking, which needs actual SERP positions and has no free source — the arithmetic is on the Seobility page and it has not improved since
  • The score, which is your weights over real signals, so a page dropping eight points has no explanation you can give a client with a straight face
  • Core Web Vitals thresholds and Google's structured-data requirements, both of which change on Google's schedule and are yours to chase
  • The Google Analytics and Search Console connections, which mean your database is now holding live refresh tokens for properties you do not own
  • White-label PDFs, which freeze whatever your checker believed on the Sunday you wrote it and then go out under somebody else's branding

Is that you?

the verdict is a default, not a law

ship it if
  • It crawls sites you own, from a machine you control, on a schedule you set
  • There is no box on the public internet into which a stranger can type a URL
  • The output is a diff against last week rather than a score out of a hundred
  • You have accepted that rank tracking is bought data, and either bought it or dropped it
  • Nobody downstream is making a billing decision from a number your code invented
don’t ship it if
  • It is the lead magnet on an agency site, because that is precisely the version with the unauthenticated fetch
  • Reports go to paying clients under your logo without a human reading them first
  • You are connecting client Google accounts and have not decided where the refresh tokens live or how they get revoked
  • Nobody has written down what the crawler may fetch, how fast, and for how long

If you build it anyway

the checklist, then the prompt that enforces it

  1. Write the URL guard before you write a single check. Resolve the hostname yourself, reject private, loopback and link-local ranges, re-validate after every redirect, and cap the chain — a 302 to 127.0.0.1 defeats a naive allowlist.
  2. Keep 'crawl a site I own' and 'audit a URL a stranger gave me' as two different systems: separate queues, separate rate limits, separate network egress. They only look like the same feature.
  3. Obey robots.txt, send a user agent with a contact URL in it, and back off on 429s. An anonymous crawler with no identity is how you land on a blocklist with nobody to appeal to.
  4. Bound the crawl four ways at once — pages, depth, wall-clock and total bytes. Faceted navigation will find whichever one you left out.
  5. Store the raw fetch: status, headers, body, timestamp. Every finding is derived from stored evidence, so 'why did you say that' has an answer other than 'the tool said so'.
  6. Do not ship a composite score until the individual checks have been stable for a month. A number that moves for reasons you cannot explain destroys more trust than a plain list of findings ever built.
  7. Encrypt OAuth tokens at rest, scope them per client, and test the revoke path before the first client connects rather than after the first one leaves.
  8. Put the run date and the rule version on every report. A PDF with no provenance is a PDF you will be arguing about in eight months.
the guardrail prompt
I am building an SEO auditing tool: crawl a site, run checks, produce a report.
The part I care about is that it will eventually accept a URL from someone who
is not me. Order the work so that is safe before it is useful, and argue with
me when I try to skip ahead.

1. Start with the fetcher, not the checks. One function fetches a URL, and it
   resolves DNS itself, rejects private, loopback, link-local and metadata
   addresses, and re-runs that check after every redirect. Cap redirects at 3.
2. Write the tests for that function first, including a redirect to
   169.254.169.254 and a hostname that resolves to 127.0.0.1. Those tests are
   the foundation; nothing else lands until they are green.
3. Phase one crawls only hostnames listed in my config. If I ask for a public
   "audit any site" box, stop and tell me that is a different system with its
   own queue, egress and rate limits, and make me confirm before building it.
4. The crawler obeys robots.txt, identifies itself with a contact URL, honours
   Retry-After, and is bounded by pages, depth, elapsed time and total bytes
   at once. Default every cap low.
5. Persist the raw response — status, headers, body, fetched-at — before
   analysing anything. Checks read from storage, never from the network.
6. Each check is a pure function over a stored response with an id, a version
   and a one-line rationale. No check reaches for the network itself.
7. No composite score in v1. Output findings with severity and the evidence
   each was derived from. Push back if I ask for a number out of 100.
8. Rank tracking is out of scope. If I ask for it, tell me plainly that SERP
   position data is bought rather than scraped, and price the API before
   writing any code.
9. If I connect Google Analytics or Search Console: tokens encrypted at rest,
   scoped per property, with a revoke command I can run today.
10. Reports render from a stored run id and carry the run date and rule
    versions on the page. No report can be generated from live data.
11. Deliberately out of scope until I ask twice: the public lead-gen widget,
    competitor tracking, and anything that emails a stranger their own audit.
12. Finish by listing which parts of this a hosted tool would have handled, so
    I can decide whether the crawler was the bit I actually wanted.
paste this before you build — not after something breaks34 lines · 2324 chars

That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.

their build prompt ↗

Or don’t build it

the boring option, and the way back out

just pay for it

This is one of the entries where 'just pay for it' is a weaker argument than usual. WooRank's Pro tier sits around a hundred dollars a month, which is real money for a solo consultant and roughly twelve hundred a year against a crawler you could genuinely finish. Buy it when you need the parts that are bought rather than built — tracked keyword positions, competitor data, an index of other people's sites — or when white-label client reporting is the actual product and you would rather someone else be answerable for what the report says. Build it when you own the sites, the report is for you, and the value is the diff between this week and last.

your exit plan, if you already built it

Own the crawl history, not the app. One stored response per URL per run — status, headers, body — in flat files or object storage, with findings computed on top as a derived layer you can throw away and recompute. Do that and moving to WooRank, Sitebulb, Screaming Frog or nothing at all is an afternoon, because the thing that took months to accumulate is the archive rather than the checker. Two things do not migrate: the report URLs you have handed to clients, and any Google connections you brokered on their behalf. Keep report paths stable, and hand OAuth grants back explicitly instead of letting them expire into a support conversation.

prior art · someone already did this
Lighthouse

Open-source automated auditing for performance, accessibility and SEO, and the engine most of these products are wrapping.

Unlighthouse

Site-wide Lighthouse crawler with a dashboard, which is most of the marketing half of this product already built.

Questions

Why is this harder than Screaming Frog, which you rated ship it?

Because Screaming Frog runs on your laptop against sites you chose, and this does not. A desktop crawler has no public endpoint, no queue to starve, no third-party sites in its path and no client waiting on a PDF. Once the same checks run on a server, on a schedule, on somebody else's behalf, every one of those becomes yours to operate. The checks are the easy half in both cases.

Is SSRF really the first thing that goes wrong here?

It is the first thing that goes wrong badly. A public 'analyse any URL' box is a request-forgery primitive with a friendly interface, and cloud metadata endpoints are the standard target because they hand credentials to anything that asks from inside the network. The fix is boring — resolve the host yourself, reject private ranges, re-check after redirects — and it belongs in the fetcher before the fetcher has callers, because retrofitting it means auditing every path that already fetches.

Can I skip keyword tracking and still have something useful?

Yes, and that is the honest version of this build. Crawl, technical findings and a weekly diff cover most of what an audit tool tells you, and none of it requires buying data. What you lose is the ranking chart, which is the part clients look at first and the part with no free source. Decide that at the start rather than discovering it once the crawler finally works.

did you build it?

Every week, someone ships something they shouldn’t have.

New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.

also on the regret index
Rank Math PRODEMO ONLY

Your wp_options table now holds a live Google refresh token, next to a 404 log nobody put a ceiling on.

Yoast SEO PremiumDEMO ONLY

You will edit sentences a human wrote until a threshold you invented last night turns green.

SeobilityDEMO ONLY

The open-source rank tracker everyone points at last shipped in 2022. That is the whole feasibility study.

last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice