DEV Community: WEBVOGUE Technologies

I checked 44 launch sites on Ahrefs' new DR4. Most of them drop to zero on 1 December.

WEBVOGUE Technologies — Mon, 09 Nov 2026 12:59:32 +0000

On 1 December 2026 Ahrefs makes DR4 its default Domain Rating. Its free API already returns both versions
(version=dr3 and version=dr4), so before submitting my own startup to "free launch sites for backlinks", I
measured them.

What changed: DR4 gives much more weight to links from sites that get organic search traffic, and subdomains now
get their own score. Ahrefs says DR4 tracks Google rankings about 2.5x better than DR3. The side effect: sites that
grew their DR with "add our badge to get a dofollow link" swaps lose most of it, because the sites linking to them
have no search traffic of their own.

The numbers (Ahrefs free API, 9 November 2026)

Site	DR3	DR4
fazier.com	85	69
pitchwall.co	75	67
uneed.best	77	62
launchigniter.com	75	55
tinylaunch.com	74	52
openhunts.com	74	42
launchingnext.com	56	40
codehype.ai	73	37
scrolllaunch.com	73	30
open-launch.com	71	29
kittylaunch.com	67	27
launchstag.com	72	25
noonlaunch.com	60	4.9
forg.to	47	3
letslaunch.today	52	1.4
bricklaun.ch	48	0.2
launchaf.com	57	0
rankcert.com	47	0
dodolaunch.com	40	0

For reference: producthunt.com 91 → 91, peerlist.io 78 → 72.

Full table of 44 sites, with the method: https://pingsold.com/ahrefs-dr4

What I took from it

A badge swap on a DR4-0 site is worth nothing for SEO after 1 December. Plenty of boards with a DR3 in the 40s–50s are at DR4 0.
The ones that held up have an audience — real visitors, newsletters, comment sections. That's also where launch traffic comes from, so the SEO and the launch-day value now point the same way.
Check DR4 before you put someone's badge on your homepage. I added a DR3 vs DR4 checker for this: https://pingsold.com/domain-rating-checker (free, no sign-up).
Long free queues are the real cost. Many of the high-DR4 boards have free queues of 2 weeks to 4 months.

I'm building Pingsold, a startup directory ranked by traffic read from founders' own analytics, so I care about
which numbers can be trusted — this was the same question for backlinks.

Domain Rating by Ahrefs. DR4 is Ahrefs' preview and may still change before 1 December.

I built a startup directory ranked by verified traffic. Almost nobody connects their analytics.

WEBVOGUE Technologies — Mon, 09 Nov 2026 11:55:32 +0000

Every week my feed has another "we just hit 10k visitors" post with a cropped screenshot. Maybe it's true. There's no way to tell. So I built Pingsold: a startup directory where the ranking comes from each startup's own analytics, read-only, synced daily. Nobody can type in a number, including me, and paying never changes a rank.

The idea still feels right to me. The numbers so far are humbling:

8 startups listed. 2 verified. Both of them are mine.

Six founders found Pingsold, filled in the form, got a listing page... and never connected their analytics. Which means they never appear on the leaderboard, which is the whole point of the site.

Why I think they don't connect
I went through 50+ startup launch sites this week (Product Hunt alternatives, launch boards, directories) to see what founders actually do there. Most of them ask for almost nothing: paste a URL, an AI fills the form, add a badge, done. Pingsold asks for something much bigger, and I think I was asking for it the wrong way.

Trust. "Connect your Google Analytics" to a site you found yesterday is a big ask, even read-only, even with Google's OAuth verification done.
Small numbers. Most early founders have 50–500 visitors a month. Publishing that next to a bigger startup feels bad.
No visible payoff. A rank on a board with two verified startups isn't worth much yet. Chicken and egg.
Timing. I asked after they'd submitted. By then they already had what they came for (a listing page and a link), and "I'll do it later" never comes.
Effort. Finding where your API key lives, or which GA4 property is the right one, is friction at exactly the wrong moment.
What I changed (shipped this week)
Verification moved inside the submit flow. It's now 3 steps: Details → Verify traffic → Review & submit. You can still skip, but the ask comes while you're in "launch mode".
We detect your analytics tool. After step 1, Pingsold checks your homepage for GA4, Plausible, Fathom, PostHog or DataFast and leads with it: "We found Plausible on yoursite.com — connect it in one click."
A "show as a range" switch, right there. "1K–5K" instead of "1,240". This was the objection I underestimated.
"Exactly what we'll read". A card showing what's public, what's only used to verify, and what we never read (individual visitors, IPs, page paths, revenue).
Instant payoff. The moment you connect, you see your verified number and where you'd rank: "You'd be #3 of 9".
Something worth showing off. A live badge for your own site that says "Verified on Pingsold" with your real visitors for yesterday, the last 7 days or the last 30 days, updated daily. The plain "Listed on Pingsold" badge has no number, so the badge itself is the reason to verify.
A bit of ceremony. Confetti when you verify, when you submit, and when you go live. Silly, but launches should feel like launches.
On the review step, skipped listings now show the muted "Not verified" label right in the preview, so you see the difference before you submit.

What I'd love your take on
Would you connect your analytics to a directory? If not, what would change your mind?
Exact numbers or ranges: which would you pick, honestly?
Is a verified traffic badge something you'd actually put on your site?
If you run a startup and want to try the new flow, it's free: pingsold.com/submit. I read every reply, and I'll post the numbers in a month — whether this moved the 2 out of 8 or not.

How I verify a startup's traffic without trusting the founder

WEBVOGUE Technologies — Tue, 03 Nov 2026 10:50:56 +0000

Every week my timeline has a "we just hit 10k visitors 🚀" post with a cropped screenshot. Maybe it's true. There's no way to tell.

So I built Pingsold: a startup directory ranked by traffic read straight from each startup's own analytics. Nobody types in a number, including me. Here's how the verification works, and the edge cases that made it harder than "just call the GA API".

1. Read-only, or nothing

Founders connect Google Analytics, Plausible, Fathom, PostHog or DataFast.

Google Analytics uses OAuth with only the analytics.readonly scope (or the founder adds a service account as a Viewer). Getting Google to verify that sensitive scope took two review rounds: a data-protection section in the privacy policy and a demo video showing the scope on the consent screen.
The other tools use API keys. Some of those tools let you create keys that can also write or manage the account, so the connector checks what the key can do and refuses anything that can do more than read analytics. A leaked read-only key can't hurt anyone; a leaked admin key can.

We only read aggregates: visitors, pageviews, hostnames and referrer domains. Nothing about individual visitors.

2. The traffic has to be on your domain

The obvious way to cheat a traffic leaderboard: list a tiny product, but connect the analytics property of a big site you also run. So every sync pulls pageviews by hostname and checks that at least 80% of them are on the listed domain.

The details matter more than the threshold:

export const DOMAIN_MATCH_THRESHOLD = 0.8;
const PREVIEW_SUFFIXES = [".vercel.app", ".netlify.app", ".pages.dev"];

function ignorable(host: string, listingDomain: string): boolean {
  const h = host.toLowerCase().replace(/:\d+$/, "");
  // localhost, raw IPs and GA's "(not set)" aren't real traffic, so they don't count either way
  if (!h || h === "(not set)" || h === "localhost" || /^\d{1,3}(\.\d{1,3}){3}$/.test(h)) return true;
  // preview deploys aren't the product, but they aren't a different site either
  return PREVIEW_SUFFIXES.some((s) => h.endsWith(s)) && registrableDomain(h) !== listingDomain;
}

export function checkDomainMatch(listingDomain: string, hosts: { host: string; pageviews: number }[]) {
  let total = 0;
  let matched = 0;
  for (const { host, pageviews } of hosts) {
    if (!Number.isFinite(pageviews) || pageviews <= 0 || ignorable(host, listingDomain)) continue;
    total += pageviews;
    // app.example.com and blog.example.com both belong to example.com
    if (registrableDomain(host.toLowerCase().replace(/:\d+$/, "")) === listingDomain) matched += pageviews;
  }
  if (total === 0) return { ok: false, reason: "no_traffic" };
  return matched / total >= DOMAIN_MATCH_THRESHOLD ? { ok: true } : { ok: false, reason: "domain_mismatch" };
}

Things I got wrong at first:

Comparing hostnames exactly. app.example.com and www.example.com are the same startup. Comparing registrable domains (eTLD+1, via the Public Suffix List) fixes that, and also handles example.co.uk correctly.
Counting localhost and preview deploys. A founder testing on localhost:3000 or a *.vercel.app preview would fail the check for no good reason. Those are now neutral: they count toward neither side.
Checking once. The check runs on every daily sync, not just at connect time, so you can't pass it once and then swap properties.

3. Credentials are encrypted, with key rotation

Stored keys and refresh tokens are encrypted with AES-256-GCM. The encryption key lives in a key ring, so it can be rotated without re-encrypting everything at once. Disconnecting deletes the credentials immediately, and for Google it also revokes the token at Google.

4. Ranking

Once a day, a scheduled job (Cloud Scheduler hitting a protected cron route) syncs every connection and stores a snapshot. Startups are ranked on two boards: top traffic (30-day visitors) and fastest growing (month over month), overall and per category. Paid options exist (faster review, a Featured slot) but they never touch the rank.

What it can't do

We're only as accurate as the analytics tool. If GA counts bot traffic, so do we. Admins can exclude a startup that's clearly gaming it, but the honest answer is that verified means "this is what your analytics says", not "every visitor was a human".

Stack

Next.js, TypeScript, Tailwind + shadcn/ui, Postgres (Neon) with Drizzle, Better Auth, Firebase App Hosting, Cloud Storage and Cloud Scheduler.

It's live at pingsold.com, free to list, and the board is tiny right now (two startups, both mine). If you run something with GA4, Plausible, Fathom, PostHog or DataFast, I'd love for you to try it, and I'd really like to hear how you'd try to break the verification.

I asked ChatGPT and Gemini 50 questions my buyers ask. My SaaS showed up once.

WEBVOGUE Technologies — Fri, 23 Oct 2026 11:58:12 +0000

My product was named in 1 of 50 AI answers. Its biggest competitor was named in 19.

These weren't vanity searches. They were 25 questions a real buyer types before they've heard of any brand, each asked on ChatGPT and on Gemini. Search Console doesn't show what ChatGPT or Gemini say about you, and a rank tracker can't either. So I measured it myself.

Here's what came back, what surprised me, and the code I use to turn a pile of AI answers into numbers you can track.

Disclosure: the product is DropPerch, a domain-expiry monitor I run, and I measured it with CiteGaps, which I also build. All the numbers below are from that one workspace, week of 12 October 2026.

The setup

25 buyer questions, written the way people search before they know any brand. For example: "What is the best domain expiry monitoring software for small businesses?"
No brand names in the questions. "Is DropPerch good?" tells you how an AI describes you, not whether it recommends you.
Two engines: ChatGPT and Gemini. Collected live, the way a buyer sees them, sources included. I didn't use the bare model API, because without web search it doesn't show what buyers see or which pages it cites.
One week, 50 answers. For each answer I kept the full text, every brand named, its position, and every cited URL.

The result

Brand	Share of the 50 answers that named it
DropCatch	38%
ExpiredDomains.net	36%
DomCop	32%
UptimeRobot	24%
Watchman Tower	20%
DropPerch (mine)	2%

One ChatGPT answer to that small-business question listed HetrixTools, UptimeRobot and DomainMOD. DropPerch wasn't in it.

Three things I didn't expect

1. I was cited more often than I was named

DropPerch was named in 2% of answers but linked as a source in 4%. So in at least one answer, the engine used my site as a source and still recommended someone else.

A mention (your brand in the text) and a citation (your URL in the sources) are different signals, and they move separately. Track both.

2. The most-cited source was a competitor's own website

The single most-cited source across the week was domcop.com: 102 citations in 50 answers. DomCop is also on the competitor list, named in 32% of answers.

That changed how I think about the problem. The engines get their shortlist from a handful of pages, and one of those pages is a competitor explaining the category in its own words. If my site and the pages around it don't answer the same questions as clearly, I'm not on the shortlist.

3. A forum thread was doing my competitors' marketing

One answer that named DropCatch, ExpiredDomains.net and DomCop, and not DropPerch, cited a discussion thread recommending DropCatch and ExpiredDomains.net. A thread an AI engine quotes is free marketing for whoever it names. A genuine, disclosed reply there can be worth more than another blog post on my own domain.

The code: turning answers into three numbers

Once you have the answers, you only need three numbers. Here's the scoring logic, simplified from what I run in production:

type Answer = {
  brands: { name: string; position: number }[]; // in the order the answer named them
  citedDomains: string[];                        // e.g. ["domcop.com", "reddit.com"]
};

function score(answers: Answer[], brand: string, domain: string) {
  const key = brand.toLowerCase();
  // Your position in each answer, or null when you weren't named.
  const positions = answers
    .map((a) => a.brands.find((b) => b.name.toLowerCase() === key)?.position ?? null)
    .filter((p): p is number => p !== null);

  const cites = (d: string) => d === domain || d.endsWith(`.${domain}`); // count subdomains too

  return {
    // How often you make the shortlist at all.
    visibilityShare: positions.length / answers.length,
    // How often the engine uses your own site as a source.
    citationShare: answers.filter((a) => a.citedDomains.some(cites)).length / answers.length,
    // Where you appear when you DO appear. Never average in the misses.
    avgPosition: positions.length ? positions.reduce((s, p) => s + p, 0) / positions.length : null,
  };
}

Run the same function for each competitor and you get the table above.

Getting brands out of free text is the fiddly part. I give each answer to an LLM with a strict JSON shape, {"brands":[{"name": string, "sentiment": "positive"|"neutral"|"negative"|"mixed"}]}, and take each brand's position from the order it returns. Sentiment comes for free, and it matters: being named often but described badly is its own problem.

Rules that keep the numbers honest

Keep the question set fixed week to week. Change the questions and you've changed the measurement.
Exclude failed answers instead of counting them as "not named".
Mind the sample size. With 50 answers, one answer is 2 percentage points. A 3-point jump can be noise.
Read the trend, not the week. AI answers change from one session to the next. One week is a sample, not a verdict.

Bonus: see ChatGPT's clicks in your analytics

When ChatGPT links to a page, it adds utm_source=chatgpt.com to the URL. That's from OpenAI's publisher FAQ. In GA4, look under Reports → Acquisition → Traffic acquisition for chatgpt.com as a source. If your visibility share rises but those visits don't, the answers mention you without linking to you.

What I'm doing about it

Nothing clever. Just the list the data gave me:

Get onto the third-party pages the engines already cite: the directories, comparison lists and threads in the sources, before any new content of my own.
Answer the exact questions I'm missing. A page per lost question, with the specifics a buyer needs, not a generic "features" page.
A comparison page against the brand at 38%, because a buyer comparing tools asks exactly that question.
Reply, with disclosure, in the threads that get cited.
Re-run the same 50 answers every week and watch the trend.

I'll post the follow-up when there's a trend worth showing, good or bad.

Try it on your own product

You can do all of this by hand with a spreadsheet: write 25 buyer questions, ask each one in a fresh chat, and log who's named and what's cited. Reading 50 answers a week gets old fast, which is why I automated it.

If you want a quick look first, there's a free check: one question, live answers from ChatGPT and Gemini, no sign-up. I also wrote up what each of these metrics means and how to read them together.

Have you checked what ChatGPT says when someone asks for a tool like yours? I'm curious whether anyone else is getting cited without being named. Tell me in the comments.

What I learned checking 65 client domains with RDAP instead of WHOIS

WEBVOGUE Technologies — Sat, 12 Sep 2026 15:17:20 +0000

I built a domain expiry monitor, and to test it against something other than my own domains I pointed it at the "our work" pages of 30 US web design agencies — the client sites they link to publicly — and checked every domain against its registry.

The results were mildly alarming, but the interesting part was everything that went wrong on the way there.

The results first

65 client domains across 14 agencies:

1 had already expired, 60 days earlier
3 were inside 45 days, the nearest with 3 days left
the rest ran from 46 days to several years out, clustering at 3–6 months

I'm not naming the agencies or the domains. Telling someone privately that their client's domain is about to lapse is useful; publishing it is exposing somebody's client.

Why RDAP and not WHOIS

WHOIS returns free text in roughly as many formats as there are registrars. RDAP (RFC 7482/9083) returns JSON, over HTTPS, with a documented shape.

The single nicest property: a 404 is an answer. In RDAP it means "this domain is not registered", which is precisely the event worth alerting on. No string matching on "No match for domain".

const res = await fetch(`${base}domain/${name}`, {
  headers: { Accept: 'application/rdap+json' },
})
if (res.status === 404) return { registered: false }

Three things that will bite you

1. The registrar's name is hidden in a jCard

There's no registrar field. The registrar is an entity with the registrar role, and its human-readable name lives inside a vCard-in-JSON structure:

const entity = (body.entities || []).find((e) => (e.roles || []).includes('registrar'))
const card = entity?.vcardArray?.[1] || []
const fn = card.find((f) => Array.isArray(f) && f[0] === 'fn')
const name = fn?.[3] ?? null   // "GoDaddy.com, LLC"

vcardArray[1] is an array of ["fn", {}, "text", "GoDaddy.com, LLC"] triples. That awkwardness is why so many tools show you IANA registrar ID 146 instead of a name — and "where do I renew this" is the actual operational question for anyone holding domains across several registrars.

2. IANA's bootstrap does not cover every TLD

The bootstrap file maps TLDs to RDAP servers, and .de, .co and .gg simply aren't in it. There's no authoritative endpoint to ask.

The right response is to say so. "The registry publishes no expiry date" is a fact about the registry, not about the domain, and it's more useful to a user than a number you inferred from somewhere else. Any tool that confidently shows an expiry date for a .de is guessing.

3. Public suffixes

cartwright.co.uk naively reduces to co.uk. Query that and you get the registry's own record, then cheerfully report the registry's expiry date as your user's domain expiry. The full Public Suffix List is thousands of entries; even a small hardcoded set of co.uk, com.au, co.nz and friends prevents the embarrassing version of this bug.

The bug that nearly discredited the whole thing

My first extractor took every href on the page. For one agency it confidently reported licdn.com, hotjar.com, addtoany.com and gmpg.org as their clients.

All four came from the <head>: <link rel="preconnect"> hints and the XFN profile link WordPress writes into every page.

I started adding them to a blocklist, then stopped — every new analytics vendor adds another entry, and the blocklist can never be finished. The structural rule can:

// Only anchors. A person clicks anchors, and only anchors point at clients.
const re = /<a\b[^>]*?\bhref\s*=\s*("([^"]*)"|'([^']*)'|([^\s">]+))/gi

One line, and the entire category of failure disappears.

A related one: an agency's second domain isn't the agency's client. One firm's site was at atendesigngroup.com and they also owned aten.io; another at openmediafoundation.org owned open.media. Matching only the exact domain you crawled isn't enough — comparing the leading label catches both.

About a third of sites hard-block automated requests

This one changed the architecture. I wrote the fetcher with fetch, and got 403 on every single site, including with a complete set of genuine browser headers. Not a Cloudflare JS challenge you can wait out — a flat 403, identical in headless Chrome and in a real headed one. It's blocking by IP reputation.

I switched to driving a real browser, which fixed it for about two thirds of sites. That turned out to matter for a second reason I hadn't considered: most agency portfolios render their client grid client-side, in Webflow or React. Even a successful fetch would have returned markup with no client links in it, and I'd have spent a day blaming my extractor.

The unglamorous finding

Only 14 of 30 agency sites linked three or more client domains at all. The rest show client work as screenshots with no anchor.

That's a lot of backlinks being left on the floor.

If you want to look at what I built with this, it's at dropperch.com — free tier monitors domains. But the RDAP notes above are the genuinely reusable part, and they're yours whether or not you ever look at it.