DEV Community: ricco020

I changed a Play Store title in 4 languages: brand rank went up, generic rank did not move

ricco020 — Fri, 13 Nov 2026 21:12:45 +0000

We changed the Google Play title of a small Android app (a reverse chord finder for guitar) in four languages at once: Danish, Italian, Russian and Swedish. Two days later we had to decide: keep the new titles or roll them back.

The tempting reading was "the app now shows up in all four countries, it worked". That reading was wrong, or at least it answered a different question. This post shows the raw numbers from that verdict (measured 3 November 2026) plus a second one on short descriptions (measured 4 November 2026), and the method we now use so that a rank change is not mistaken for demand.

The change

New titles, one per locale, all built as <local generic term>: Chord Finder:

Country	Locale	New title
DK	da	Guitar Akkorder: Chord Finder
IT	it	Accordi Chitarra: Chord Finder
RU	ru	Аккорды на гитаре Chord Finder
SE	sv	Gitarr Ackord: Chord Finder

The idea: keep the brand-ish part ("Chord Finder"), add the generic phrase people type in their language.

Three things that are NOT the same measurement

Before reading any number, separate three questions:

Brand rank: when someone types a name close to ours ("Reverse Chord Finder"), are we in the results, and where? This mostly measures indexing and title matching. It says little about demand: nobody types a name they have never seen.
Generic rank: when someone types the phrase they actually need ("accordi chitarra", "gitarr ackord"), where are we? This is the one that can bring new users.
Installs: did more people install? This is the only one that pays, and it is the noisiest.

A title change can move (1) a lot, (2) not at all, and (3) by an amount you cannot read in two days. That is exactly what happened.

The J+2 numbers (3 November 2026)

Measured on the public Play search, one request per query and country, top 30 results (Sweden returned only 9 results on the exact title query, Denmark 50).

Exact new title as a query: absent in 4 of 4 countries.

Generic query (the local phrase alone):

Country	Query	Our rank (top 30)	Top result
DK	guitar akkorder	absent	com.ultimateguitar.tabs
IT	accordi chitarra	absent	com.ovelin.guitartuna
RU	аккорды на гитаре	absent	com.amdm.amdm
SE	gitarr ackord	absent	com.ultimateguitar.tabs

Brand query "Reverse Chord Finder":

Country	Rank before the change	Rank at J+2
DK	absent	7
IT	absent	7
RU	absent	6
SE	absent	8

So: 0 of 4 generic wins, 4 of 4 brand wins. The verdict was "keep the titles" (they did no harm and fixed brand findability in four countries where we were invisible even on our own name), but the honest summary is: this change made us findable, it did not make us discoverable. The generic phrases are held by large, established apps (Ultimate Guitar, GuitarTuna, Chordify). A title alone does not move a small app past them.

A second verdict, same method (4 November 2026)

We also rewrote the short description in five locales to carry the generic term. At J+2, generic queries: 0 of 10 in the top 30 (ES, RO, FR, DE, BR, two phrases each). Brand query:

Country	Brand rank before	Brand rank at J+2	Decision
ES	9	15	rolled back
DE	9	13	rolled back
FR	not in this snapshot	12	kept
RO	not in this snapshot	5	kept
BR	not in this snapshot	3	kept

Two locales lost brand rank with zero generic gain, so they were restored to the previous text. Without the separation above, an average "brand rank across 5 countries" would have hidden that two of them got worse.

Why installs were not part of the verdict

We deliberately did not call the change on installs:

The same week, a new app version with a different paywall went out (3 November). Any install or revenue movement in those four countries mixes both changes.
Per-country daily installs for a small app are tiny. Two days of tiny numbers cannot separate a real effect from noise.
Play Console install reports lag. A J+2 verdict on installs reads data that is not complete yet.

So the J+2 verdict uses ranks only, and installs get their own check at J+14 with a written threshold. If you only have one change running, you can be bolder. If you have two, say so in the verdict.

The method, reproducible

Write the verdict rule before publishing. Ours: keep if the generic rank enters the top 30 in at least one country, or if the brand rank improves without any generic loss. Roll back a locale if the brand rank drops by 3+ positions with no generic gain.
Snapshot "before" for three query types per locale: exact new title, generic phrase(s), brand name. Store raw JSON: {country, locale, query, rank, n_results, top3}. n_results matters: "absent" from 9 results is not "absent" from 50.
Publish, then check that the store serves the new text before starting the clock. A title saved in the console is not a title in search.
Measure at J+2 with the same script, same countries, same depth. Compare per locale, never as an average.
Report the three axes separately: brand, generic, installs. A row with "brand up, generic absent" is a findability fix, not a growth result.
Installs at J+14, with any other change of the period listed next to the number.

A minimal record per query looks like this:

{"c": "IT", "l": "it", "q": "accordi chitarra", "rang": null, "n": 30,
 "top3": ["com.ovelin.guitartuna", "net.chordify.chordify", "com.myproj.chordchartgenerator"],
 "etat": "ABSENT"}

Keeping top3 turned out to be useful: it tells you whether a generic query is even winnable (three apps with huge review counts at the top usually means no).

What we would do differently

Spend the title on a query the app can actually win (long-tail, with weak incumbents) rather than on the head term of each language. In Korean, the same app ranks 1st on a narrow "reverse chord search" phrase. That is where a title earns installs.

Disclosure: I work on the app above and on ZAX, which sells store listing rewrites. The linked page is our longer case study with dated ranks for other apps, same method.

DoH costs one TLS handshake, then almost nothing: 45 timed queries to Cloudflare, Google and Quad9

ricco020 — Sun, 01 Nov 2026 22:07:29 +0000

Most DNS-over-HTTPS guides say the overhead is "negligible after warmup" and stop there. I wanted the number, so tonight I timed it.

Setup

Vantage point: one VPS in a datacenter (Contabo, AS51167, Lauterbourg, France), 1 Nov 2026, 22:0x UTC. A datacenter sits much closer to these resolvers than a home connection, so read the absolute values as a floor, not as what you will see on Wi-Fi.
Resolvers: Cloudflare (cloudflare-dns.com/dns-query), Google (dns.google/dns-query), Quad9 (dns.quad9.net/dns-query).
Query: example.com A, RFC 8484 wire format over HTTP/2, curl 8.5.0.
3 runs per resolver. Each run opens one connection and sends 5 queries on it, so query 1 pays for TCP + TLS and queries 2 to 5 reuse the connection. 45 queries in total.

Q="AAABAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE"   # example.com A, base64url
u="https://cloudflare-dns.com/dns-query?dns=$Q"
curl -s --http2 -H 'accept: application/dns-message' \
  -w "total=%{time_total} connect=%{time_connect} tls=%{time_appconnect}\n" \
  "$u" -o /dev/null "$u" -o /dev/null "$u" -o /dev/null "$u" -o /dev/null "$u" -o /dev/null

Results

Resolver	1st query (3 runs)	TLS done at	Queries 2 to 5, median (12 values)	Plain UDP, `dig` (5 values)
Cloudflare	47.6 / 28.3 / 28.9 ms	40.0 / 23.8 / 24.1 ms	4.8 ms	2, 3, 3, 3, 4 ms
Google	36.1 / 39.0 / 49.9 ms	26.9 / 26.7 / 41.2 ms	5.6 ms	4, 5, 7, 8, 18 ms
Quad9	39.8 / 38.0 / 52.4 ms	32.2 / 30.4 / 37.5 ms	7.7 ms	2, 2, 2, 12, 13 ms

What the numbers say:

The first query costs 28 to 52 ms, and almost all of it is the handshake. TCP connect is 4 to 16 ms; the TLS handshake finishes 24 to 41 ms after the start. The DNS answer itself is the small remainder.
Once the connection is open, a DoH query costs 4 to 15 ms, a few milliseconds above plain UDP to the same provider. The "negligible after warmup" claim holds, on this path.
Quad9's third run settled at 15 ms per warm query instead of 7.7. Same connection, same query: most likely a different anycast node or a longer route for that connection. One run is not enough to rank resolvers on speed; three already show the spread.
dig query time and curl time_total do not measure exactly the same thing (curl also counts HTTP framing and its own processing). Compare inside a column, not across columns.

The practical consequence

The cost of DoH is per connection, not per query. A browser keeps its DoH connection open, so you pay the 30 to 50 ms once and then a few ms per lookup. Anything that keeps tearing that connection down (aggressive power saving, a flaky network, a VPN client that resets sockets on reconnect) pays the handshake again each time.

One filtering check, while I was there

Quad9 publishes isitblocked.org as a canary for its blocklist. From the same VPS:

dig @9.9.9.9 isitblocked.org   -> NXDOMAIN (blocked)
dig @1.1.1.1 isitblocked.org   -> 74.208.236.124
dig @1.1.1.2 isitblocked.org   -> 74.208.236.124

So the filter is live on Quad9's plain resolver. That 1.1.1.2 (Cloudflare's malware-filtering resolver) does not block it says nothing about which blocklist is better: it is Quad9's own test domain, not malware.

Limits

One vantage point, one domain already cached at every resolver, one evening. No home ISP path, no mobile network, no HTTP/3. If you rerun the snippet from home, I would expect the handshake to grow far more than the warm queries.

If you are setting DoH up rather than benchmarking it, I keep a browser-by-browser guide on my own site (Chrome, Edge, Firefox, Safari, iOS, Android) that also covers the most common leak, browser DoH silently bypassing a VPN's resolver: DNS over HTTPS setup per browser.

Wrong key or wrong short ID? Xray REALITY gives the same error for both

ricco020 — Sun, 01 Nov 2026 21:50:33 +0000

I maintain VLESS + REALITY config templates for people running their own Xray server, and tonight I ran a small fault-injection test on Xray-core 26.10.31 to answer one question: when a REALITY client is misconfigured, what does each side actually tell you?

Short answer: the server tells you nothing, and two different mistakes produce the exact same client error.

The setup

Everything ran on one Linux box, loopback only:

Xray 26.10.31 (a4a3dff, go1.27.3), server inbound VLESS + REALITY + Vision, target www.microsoft.com, server log level warning (the usual production setting).
A client config with a local SOCKS5 inbound and an HTTP inbound, fingerprint: chrome.
Fresh keys from xray x25519, UUIDs from xray uuid, a short ID from openssl rand -hex 8.
Test request: curl --socks5-hostname 127.0.0.1:<port> https://www.cloudflare.com/cdn-cgi/trace.

Baseline first. Both files pass xray run -test ("Configuration OK."), the correct client returns HTTP 200 through SOCKS5 and through the HTTP inbound, and a plain TLS probe to the server port (openssl s_client -servername www.microsoft.com) gets the real Microsoft certificate (CN = www.microsoft.com). That last part is the whole point of REALITY: a prober who does not hold the key just sees the cover site.

Then I started three broken clients against the same server.

Results

Client mistake	curl result	Client log	Server log (warning)
Wrong public key (`password` from another keypair)	fails after ~2.1 s, `SSL_ERROR_SYSCALL`	`REALITY: received real certificate (potential MITM or redirection)`	nothing
`shortId` not in the server list	fails after ~2.1 s, `SSL_ERROR_SYSCALL`	`REALITY: received real certificate (potential MITM or redirection)`	nothing
`serverName` not in `serverNames` (`www.apple.com`)	fails after ~2.2 s, `SSL_ERROR_SYSCALL`	only `accepted tcp:www.cloudflare.com:443 [socks-in >> proxy]`	nothing

Three things I did not expect before running it:

1. A wrong key and a wrong short ID look identical. In both cases the server does not recognise the client as one of its own, so it behaves as a transparent relay to the target, the client receives Microsoft's genuine certificate, and Xray reports a possible MITM. The message is accurate from the client's point of view, but it sends you looking at your network when the problem is a copy-paste. If you see received real certificate, check the public key and the short ID first, in that order.

2. A wrong SNI is even quieter. No REALITY error at all on the client, just a connection accepted locally and a failed TLS session downstream. If your client logs show traffic being accepted and nothing coming back, compare serverName with the server's serverNames array character by character.

3. The server says nothing at warning. None of the three failures produced a single line on the server. That is by design (a REALITY server is supposed to look like it is not there), but it means "check the server logs" is useless advice for client-side mistakes unless you temporarily raise the log level.

Two warnings worth reading

Xray 26.10.31 now prints these at startup when you choose them:

REALITY: Choosing "www.microsoft.com" as the target will increase the likelihood of your server's IP being blocked by the GFW
REALITY: Listening on non-443 ports will increase the likelihood of your server's IP being blocked by the GFW

The first one is new to me in a release build and contradicts a lot of older tutorials that use www.microsoft.com as the default dest. Pick a target that is plausible for your server's network neighbourhood and supports TLS 1.3 and H2.

The field name changed

In the client realitySettings, current Xray uses password for what everyone still calls the public key. xray x25519 prints it as Password (PublicKey): .... Templates that still say publicKey keep working for now, but if you diff your config against a recent example and see password, it is the same value, not a new secret.

One client I could not make work

I also tried a sing-box 1.14.4 client against the same Xray 26.10.31 server, with chrome, firefox and safari fingerprints. All three failed with reality verification failed, while the Xray client with the same values worked. I have not dug into the cause, so treat it as "test your exact client and server versions together", not as a verdict on sing-box.

A 3-line checklist

xray run -test -c config.json on both sides. It catches placeholders and malformed keys immediately (invalid "privateKey"), not logic errors.
Run the server and the client on one machine on a spare port before touching the VPS firewall. If loopback works, the remaining problem is network, not config.
If it fails with received real certificate, the key or the short ID is wrong. If it fails silently, the SNI is wrong.

I keep a longer walkthrough of VMess vs VLESS, REALITY and the transport options, with the full server and client JSON, here: V2Ray, VMess and VLESS setup guide. If you just want the keys, short ID and share link generated in the browser, there is a free VLESS REALITY config generator on the same site.

I checked what 16 web hosts serve on their own homepage: HSTS, HTTP/3, IPv6, TLS 1.3

ricco020 — Sat, 31 Oct 2026 18:23:41 +0000

I write hosting comparisons, and most of them repeat what the hosts say about themselves: free SSL, HTTP/3, "modern stack". So I checked what the hosts actually serve on their own homepage. One curl -sL per site, from one VPS in Germany, on 31 October 2026 at 18:22 UTC.

What I measured

For the final response after redirects:

Strict-Transport-Security header present (HSTS)
Content-Security-Policy header present (not its quality, only its presence)
Alt-Svc advertising h3 (HTTP/3)
an AAAA record on the final hostname (IPv6)
a TLS 1.3 handshake accepted (openssl s_client -tls1_3)

curl -sL -o /dev/null -D hdr.txt -A "Mozilla/5.0 ..." \
  -w "%{http_code} %{url_effective} %{time_starttransfer}" https://$host/
dig +short AAAA $final_host
echo | openssl s_client -connect $final_host:443 -servername $final_host -tls1_3

Results: 16 hosts, 11 measurable

Five answered 403 to my request (LWS, Contabo, HostPapa, Bluehost, Scaleway). A 403 page from a bot filter tells you nothing about the real headers, so I count them as not measured, not as "no".

Host (final hostname)	HSTS	CSP	HTTP/3	IPv6	TLS 1.3
hetzner.com	yes	yes	yes	yes	yes
dreamhost.com	yes	yes	yes	yes	yes
ultahost.com	yes	yes	yes	yes	yes
infomaniak.com	yes	yes	no	yes	yes
hosting.com (from a2hosting.com)	yes	yes	no	yes	yes
siteground.com	yes	no	yes	no	yes
planethoster.com	yes	yes	no	no	yes
hostinger.com (from hostinger.fr)	no	no	yes	yes	yes
ionos.fr	yes	yes	no	no	no
ovhcloud.com	no	no	no	no	yes
o2switch.fr	no	no	no	no	yes

Counts on the 11: HSTS 8, CSP 7, HTTP/3 5, IPv6 6, TLS 1.3 10.

Three things I did not expect

ionos.fr refuses TLS 1.3. The handshake ends with tlsv1 alert protocol version; without the flag it negotiates TLS 1.2 (ECDHE-RSA-AES256-GCM-SHA384). That is still a secure protocol, but it is the only one of the 11 stuck there.
Two large French hosts send no HSTS on their homepage: o2switch and OVHcloud. o2switch also has no IPv6 record, no HTTP/3 and no CSP: it scored zero on four of five checks while being one of the most recommended shared hosts in France.
"HTTP/3" in a feature list and HTTP/3 on the vendor's own site are different things. Six of the 11 do not advertise it on their homepage.

What this does NOT tell you

This is the marketing site, not the servers you rent. A host can run a dated homepage and give customers HTTP/3, IPv6 and TLS 1.3 by default, or the reverse. The homepage is often behind a CDN the customer plan never touches. So do not pick a host from this table. Use it as a question to ask: if the plan page says "HTTP/3 included", test a customer site on that plan, the same way, before you trust the claim.

I compare two of these hosts (o2switch and PlanetHoster, which differ on two of the five checks here, HSTS and CSP) on the things that do matter for customers, price over 24 months, renewal and limits, in this o2switch vs PlanetHoster comparison.

Reproduce it

One request per host, and stop on a 403: hammering a bot filter will not make it answer. Results move: a host can enable HSTS tomorrow. This table is dated 31 October 2026, 18:22 UTC, and it is a snapshot, not a ranking.

I checked 40 sites for /.well-known/passkey-endpoints. 11 of the 34 I could measure publish it

ricco020 — Sat, 31 Oct 2026 16:53:05 +0000

Passkeys have a small discovery problem. A password manager that wants to say "this site supports passkeys, create one now" has to guess where the enrollment page lives. The W3C WebAppSec draft "A Well-Known URL for Passkey Endpoints" fixes that: a site serves a JSON file at /.well-known/passkey-endpoints with an enroll URL and a manage URL.

I wanted to know how many large sites actually publish it, so I checked 40 of them today (31 October 2026, 17:50 UTC+1) with one curl per domain.

Method

curl -s -m 12 -L -A "<desktop Chrome UA>" \
  -o body -w "%{http_code} %{content_type}" \
  "https://$domain/.well-known/passkey-endpoints"
python3 -c "import json; print(sorted(json.load(open('body')).keys()))"

A domain counts as supporting the file only if the final response is 200 and the body parses as JSON with at least one of the two keys. A 200 that returns an HTML page is a soft 404, not support.

One caveat matters: the requests came from a datacenter server. Six domains answered with a bot wall (403) or a broken connection, so I count them as not measured, not as "no".

Result: 11 of 34 measurable domains

Domain	Status	Keys	Content-Type
amazon.com	200	enroll	application/json
paypal.com	200	enroll, manage	text/plain
ebay.com	200	enroll, manage	application/json
dropbox.com	200	enroll, manage	application/json
shopify.com	200	enroll, manage	application/json
adobe.com	200	enroll, manage	(none)
tiktok.com	200	enroll	application/octet-stream
kayak.com	200	enroll, manage	application/json
target.com	200	enroll, manage	application/json
uber.com	200	enroll, manage	application/json
coinbase.com	200	enroll, manage	text/plain

No file (404, or HTML on a 200): google.com, accounts.google.com, microsoft.com, login.microsoftonline.com, apple.com, github.com, facebook.com (400), x.com and linkedin.com (200 but HTML), nintendo.com, ubisoft.com, yahoo.com, proton.me, 1password.com, dashlane.com, cloudflare.com, stripe.com, walmart.com, hubspot.com, mercadolibre.com.ar, zoho.com, docusign.com, discord.com.

Not measured from a datacenter IP: gitlab.com, playstation.com, bitwarden.com, nordpass.com, reddit.com (403), bestbuy.com (HTTP/2 stream error after one redirect).

Three things I did not expect

The platforms that pushed passkeys hardest do not publish it on their main domains. Google, Apple and Microsoft all return 404 on the domains I tried. They ship passkeys everywhere, but this discovery file is not where they point password managers.
None of the password managers I could measure publish it for their own accounts. 1Password, Dashlane and Proton return 404. The tools that read this file do not serve it.
Four of the eleven are not served as application/json. PayPal and Coinbase send text/plain, TikTok sends application/octet-stream, Adobe sends no Content-Type at all. The JSON parses fine in all four, so a client that sniffs the body works; a strict one that checks the header first would skip them. PayPal also points enroll and manage to the same URL, and Amazon and TikTok only declare enroll.

Shopify is the only one that tags its URLs with UTM parameters (utm_source=credential_manager, utm_medium=passkey_endpoint). That is a nice idea: it means they can measure how many enrollments the file actually produces.

If you run a site with passkeys

The whole thing is a static JSON file:

{
  "enroll": "https://example.com/account/passkeys/new",
  "manage": "https://example.com/account/passkeys"
}

Serve it with Content-Type: application/json, make sure the URLs work for a logged-out user (they should go through login and land on the right page), and add UTM tags like Shopify if you want to know whether it does anything.

For background on how passkeys work and why the private key never leaves your device, I keep a plain-language explainer here: what a passkey is and how it works. It is the sibling of an earlier test on the other discovery file, /.well-known/change-password, where 11 of 40 sites also got it right. Same number, by coincidence.

The raw responses are easy to reproduce with the loop above; results will differ from a residential IP for the six blocked domains.

One Bing query was 62% of my impressions and never got a click

ricco020 — Sat, 31 Oct 2026 12:04:22 +0000

I run a small site about self-hosted WireGuard, and I compute my own CTR curve from the Bing Webmaster API instead of borrowing an industry one. Today the curve said something absurd: queries phrased as questions, at positions 6 to 8, convert at 0.037%. Non-question queries in the same band convert at 6.3%. That is a factor of 170.

It is not a behaviour of question searchers. It is one query.

The numbers

GetQueryStats for the whole property, 12 June to 30 October 2026:

85,371 impressions, 1,467 clicks, so a site CTR of 1.72%
one query, what is a vpn split tunneling, accounts for 52,680 impressions and 0 clicks
that is 61.7% of every impression the site received in Bing

Remove that single row and the site CTR becomes 4.49%. Same pages, same titles, same month.

The weekly rows show its shape:

week starting	impressions	avg position
2026-08-14	183	9
2026-08-21	2,481	8
2026-08-28	6,327	8
2026-09-04	10,333	8
2026-09-11	19,517	7
2026-09-18	7,562	6
2026-09-25	6,277	6

Then nothing. Seven weeks, a climb to almost 20,000 impressions a week, never one click, then gone.

Why this matters more than it looks

GetQueryPageStats says Bing showed one page for it, our split tunneling explainer, for 49,356 of those impressions. If you look at that page's report you see a page with a catastrophic CTR at position 7, and the obvious move is to rewrite its title.

Its title has been rewritten three times since June. None of that could move this row, because whatever produced those impressions was not a person choosing between ten blue links. I do not know what it was (a rank tracker, an answer box that satisfied the question, an automated surface), and I am not going to pretend I do. What I can say is that 52,680 impressions with zero clicks at position 6 is not a distribution humans produce.

The rule I took from it

Never build a CTR curve without looking at the top contributor of each cell. One row can own a band. Ours owned 97% of the "question, position 6-8" cell.
Report site CTR with and without the largest query. If the two numbers differ by more than 2x, the average describes one query, not your site.
A title rewrite is only a fix when the impressions are human. Check the weekly shape first: a smooth climb to five figures with zero clicks, then a cliff, is a signature, not an audience.
Bing rows are per query per date bucket, not per query. Summing them without grouping by query is how you miss that a "cell" is a single query repeated seven times.

The page may or may not need work; this row cannot tell me either way. The thing that was broken was my instrument.

A pruning rule put my renamed page in noindex: it measured the new URL, the history was on the old one

ricco020 — Fri, 30 Oct 2026 20:22:12 +0000

Two weeks ago I renamed 42 article URLs on a small VPN review site. An affiliate network's brand rules forbid using the partner's trademark in a URL, and several of our slugs did exactly that. So /en/blog/best-nordvpn-alternatives-2026 became /en/blog/best-vpn-alternatives-2026, with a permanent redirect from the old path, and every internal link was rewritten to the new one. Textbook migration.

Six days later, a separate cleanup job put the new URL in noindex. Nobody noticed for another six days. Here is how two correct jobs combined into one wrong result, and the check that would have caught it.

The pruning rule was reasonable

The site had too many thin pages. Google was crawling hundreds of URLs that never earned an impression. So the cleanup rule was simple: a page published before a cutoff date, with fewer than 12 impressions and zero clicks over 120 days in Search Console, goes to noindex, follow, leaves the sitemap, and is listed in a reversible JSON file.

293 URLs matched. Together they held 0.3 % of the site's impressions and 47 % of its sitemap. On paper, a clean cut.

The rule read the wrong key

Search Console reports performance by URL. The demand for "nordvpn alternatives" had been built over months on the old path. After the rename, Google kept showing the old URL in results, because it had not recrawled it yet and had never seen the redirect.

So when the pruning job asked "how many impressions did /en/blog/best-vpn-alternatives-2026 get in 120 days?", the honest answer was: almost none. The page was six days old in Google's eyes. The history lived on another key.

The page it removed had 7,836 impressions over 130 days at an average position of 10.8, all recorded on the old URL.

What the damage looked like

From Search Console, for the query "nordvpn alternatives":

Window	Impressions	Avg. position
Last 28 days	1,054	10.5
Last 14 days	12	35.2

And the URL Inspection API, on 30 October:

Old URL: "Submitted and indexed", last crawl 1 October. Google still had not seen the redirect.
New URL: "Discovered, currently not indexed", never crawled. It had spent its first days in noindex.

The redirect was correct, the canonical was correct, the page was in the sitemap and linked from 11 articles. None of that mattered while the page told crawlers not to index it.

The fix, and what it cannot undo

The 7 renamed URLs caught by the rule were taken out of the noindex list, the sitemap was resubmitted, and the URLs were pushed through IndexNow and the Bing Webmaster URL submission API. That restores eligibility. It does not restore the position: the new URL now has to be crawled, then earn back what the old one had.

The check I should have had

Any rule that judges a page by its own history needs to know that page's previous names. In practice:

Keep the redirect map as data, not only as server config. We had 53 redirects in a config file the pruning job never read.
Sum metrics over the URL and every path that redirects to it before applying a threshold.
Exclude any URL younger than one full measurement window from automatic pruning. A 120-day rule should not judge a 6-day-old URL at all.

The third point is the cheapest and would have been enough on its own.

The general pattern

Two jobs, each correct against its own spec: the migration preserved users and links, the pruning removed dead weight. The failure was in the join: one job created a new identity for an asset, the other measured the asset by identity. If your tooling has a "rename" step and a "measure" step, check that the measure step knows about renames.

If you want to see the page this happened to, it is the VPN alternatives comparison on the site. I will post the recovery numbers once Google has recrawled it.

Leaving Vercel with a static site: the redirects you lose without noticing

ricco020 — Wed, 07 Oct 2026 11:48:32 +0000

This week I moved four static Astro sites off Vercel and onto a plain container host. The builds were the easy part: npm run build, copy dist/ into a web server image, done. What almost went wrong is everything Vercel had been doing around the build without my thinking about it.

The failure that does not show up

A static site on Vercel is not only a folder of HTML. vercel.json holds redirects, headers, cleanUrls and trailingSlash, and the platform applies them at the edge. Copy the same dist/ behind a default file server and:

the home page answers 200,
the build is green,
the deployment is marked healthy,
and every inherited 301, every /go/... short link and every extensionless URL returns 404.

Nothing reports it. No build step knows those rules existed. You find out weeks later in Search Console, or you never do. Between them the four sites carry 64 redirects, most inherited from older URL structures, plus header rules. Retyping them by hand is how one gets dropped.

What had to be rebuilt in the web server

I went with Caddy, and ended up translating five things:

Redirects, in file order. Vercel evaluates them top to bottom, so the Caddyfile wraps them in a route block to keep that order. Patterns like /old/:slug and /docs/:path* become path_regexp matchers, and :slug or $1 in the destination become capture group placeholders.
Host conditions. has: [{ "type": "host", "value": "www.example.com" }] becomes a host matcher on the same rule.
Headers. The catch-all /(.*) block becomes one global header directive, path-specific ones get a named matcher.
cleanUrls and trailingSlash: false. A redirect from /page.html to /page, a redirect away from the trailing slash, then try_files {path} {path}/index.html {path}.html.
Language negotiation on /. One site had a small middleware.ts sending visitors to /fr or /es from Accept-Language. In Caddy that is a header_regexp matcher and a 302, with Vary: Accept-Language and Cache-Control: no-store so no cache pins one visitor's language for everyone. Crawlers send no Accept-Language, so they keep the default root.

One detail I would not have guessed: short links. A rule on /go/docs does not match /go/docs/, and links copied around the web come in both forms. The generated matcher lists both.

Refuse, do not skip

The part I care most about is what the script does with a rule it cannot translate. rewrites, routes, missing, and has conditions other than host stop it with an error naming the rule. A warning would scroll past, and a skipped redirect is exactly the silent 404 the whole exercise is meant to avoid.

Two things that bit me anyway

npm ci failed in the container on one site because the lockfile had drifted from package.json. Vercel had been tolerating it. Decide whether you want to fix the lockfile or use npm install in the build stage, but find out before the cutover.
Verify on the served site, not the config. After each deploy I requested a sample of old URLs against the container's public address and checked the status code and the Location header. A Caddyfile that parses says nothing about whether your patterns mean what you think.

The script

It is one Python file, standard library only: it reads vercel.json and writes a Caddyfile, a two-stage Dockerfile (Node build, then caddy:2-alpine) and a .dockerignore.

python3 vercel-to-caddy.py <repo> --lang-root fr,es --out dist

Source, a worked example and the list of what is and is not handled: gitlab.com/ler.eric/vercel-to-caddy. It only covers static output; anything that needs functions or server rendering is out of scope.

I do this kind of migration and site work for clients at Z-AX. If you have a vercel.json pattern the script refuses, open an issue with the rule: the refusal list is where it should grow next.

80,000 Search Console impressions, zero clicks: three checks before you call it an opportunity

ricco020 — Wed, 07 Oct 2026 08:20:18 +0000

One of my sites went from about 850 Search Console impressions a day to 16,000 in a week. Before rewriting anything to "capture the opportunity", I spent ten minutes on the numbers. I am glad I did.

The numbers

Over 28 days the site showed 133,505 impressions. One page carried 88,640 of them: an article about what NordVPN really costs over 24 months. One query carried most of that page:

Query	Impressions	Clicks	Avg. position
nordvpn cost	80,721	0	9.0
nord vpn preis	6,729	0	2.6

Zero clicks at position 9 on eighty thousand impressions is unusual. Zero clicks at position 2.6 on nearly seven thousand is not something a human audience produces.

Three checks that took the "opportunity" apart

1. Compare with the site's own pages at the same rank. On the same property, in the same period, a French article at position 7.3 got 18 clicks from 985 impressions, and a Spanish one at 6.7 got 9 from 986. So the site does get clicks at these positions. This one query does not.

2. Look at who is supposedly searching. The property's top countries by impressions were Austria (18,895, 0 clicks), Denmark, the United States, Norway and the Netherlands. For an English page about a price in euros, Austria and Norway leading with no clicks at all is not a reader profile. 83% of impressions were on desktop, while clicks were split almost evenly between desktop and mobile.

3. Look at the shape over time. Daily impressions sat around 800, jumped to 4,953 on 24 September, stayed between 9,000 and 16,700 for six days, then dropped to 2,579 on 1 October. Demand for a product price does not behave like that. A scheduled job does.

I cannot prove what generated those impressions. Rank trackers and scrapers querying Google at scale are the obvious candidates, and Search Console counts an impression whenever the result is rendered in a results page, whoever asked.

What I changed

Nothing on the page. Its title already answers the query, and rewriting a title to chase readers who are not there risks losing the ones who are.

What I changed is the rule I work by: an impressions number is not a demand number until the clicks at that position look like the rest of the site. The check is cheap:

Take the page's query with the most impressions.
Find two other pages on the same property at a similar average position.
Compare click-through rates. An order of magnitude apart, with zero clicks, means the impressions are not people.
Split by country and device. If the split looks nothing like the pages that do get clicks, stop.

The dashboard total had told me this site was sitting on its biggest opening of the year. Excluding that single query, its impressions for the period were about 52,800, with the same 180 clicks. That is the number I plan with now.

Three of the eight sites that support /.well-known/change-password do not support it

ricco020 — Sun, 23 Aug 2026 22:31:06 +0000

There is a small W3C standard called A Well-Known URL for Changing Passwords. A site serves /.well-known/change-password, redirects it to its real change-password page, and password managers can send a user straight there instead of making them hunt through account settings.

I checked 24 well known sites for it tonight. The interesting part is not how many support it. It is that three of the eight apparent supporters do not support it at all, and the specification predicted exactly that.

The trap is written into the spec

A naive check is "does /.well-known/change-password return 200". That check is wrong, because plenty of servers return 200 for everything. A SPA with a catch-all route will happily serve its shell for any path you invent.

So the spec includes a countermeasure. Section 5 tells clients to also request a URL that should never exist:

/.well-known/resource-that-should-not-exist-whatever-forty-two

If that returns 200 too, the server is not answering your question. It is just saying 200 at everything. The support signal is void.

That is a rare thing to find in a standard: the authors anticipated the false positive and shipped the control with the feature.

What I measured

Two requests per host, one for the standard path and one for the control path, real HTTP, browser User-Agent, 24 hosts.

supports it for real   5 / 24     change-password 200, control 404
false positive         3 / 24     change-password 200, control 200
no support            16 / 24     404 (13), 403 (2), 400 (1)

Real support:

github.com        200 / 404
reddit.com        200 / 404
wordpress.com     200 / 404
apple.com         200 / 404
1password.com     200 / 404

False positives, which a 200-only check would have counted as wins:

twitter.com       200 / 200
netflix.com       200 / 200
linkedin.com      200 / 200

Without the control request I would have reported 8 supporters instead of 5. That is a 60 % overcount, from a check that never threw an error and looked green all the way down.

The part I did not expect

I included six password managers, since this standard exists mainly for their benefit. They are the consumers of the signal.

1password.com     supports it
bitwarden.com     404
dashlane.com      404
proton.me         404
lastpass.com      404
nordpass.com      404

One out of six serves the standard that password managers rely on. I am not going to pretend that is a scandal, these are marketing domains and the account systems often live elsewhere. But if you are building anything that touches password and passkey hygiene, it is a useful reminder that ecosystem support is thinner than the existence of a spec suggests.

If you want to add it

It is genuinely a two line change on most stacks. Redirect /.well-known/change-password to your existing change-password page with a 302, and make sure your 404 handler actually returns 404 for unknown paths under /.well-known/. That second half is the part people get wrong, and it is the half that makes the first half detectable.

The general lesson

I have spent a lot of this week finding checks that returned a confident answer to a question slightly different from the one I meant to ask. This is the same shape, with one difference: here the spec authors saw it coming and gave you the control request for free.

Most of the time nobody hands you the control. You have to think of it yourself, which usually means asking "what would this check return if the thing I am testing were completely absent?" If the answer is "the same thing", the check is decorative.

Google said it had never heard of my URL. The URL was fine, my probe was not.

ricco020 — Sun, 23 Aug 2026 22:23:06 +0000

Last night I ran Google's URL Inspection API against a site I run and got this back:

coverageState : 'Google ne reconnait pas cette URL'
lastCrawl     : JAMAIS

"Google has never heard of this URL." On a page that had been in the sitemap for weeks.

I was about to open a very large investigation. The page was fine. My probe was not. Here are the three ways that API lied to me in one sitting, and the one number that finally told me something true.

Trap 1: www and non-www are different URLs to this API

I passed https://save-my-disk.com/fr/blog/carte-sd-non-detectee. The sitemap declares https://www.save-my-disk.com/.... Same site to a human. Two different URLs to the API.

The result is not an error. It is not a 404. It is a confident, well-formed answer to a question I did not mean to ask:

without www :  'Google ne reconnait pas cette URL'   lastCrawl JAMAIS
with www    :  'Envoyee et indexee'                  lastCrawl 2026-07-18

The same page. Indexed the whole time.

The rule I now follow: never compose the URL you inspect. Read it out of the sitemap you actually serve. I fetch sitemap.xml, grep the slug, and inspect that exact string.

Trap 2: the `indexed` field on sitemaps is zero for everyone

The Sitemaps endpoint returns a contents block that looks like it answers the only question you care about:

{"type": "web", "submitted": 3258, "indexed": 0}

That indexed: 0 is not a measurement. I have a site doing 1677 impressions a month reporting indexed: 0. Every property I own reports indexed: 0. If you build a dashboard on that field you will build an alarm that fires forever.

Use errors and warnings from the same block. Those are real. Ignore indexed and inspect URLs individually if you want indexing state.

Trap 3: two states that read alike and mean opposite things

This is the one that matters, and it is the reason the whole exercise was worth it.

"Discovered - currently not indexed" means Googlebot knows the URL exists and has never fetched it. lastCrawl is empty.
"Crawled - currently not indexed" means Googlebot fetched the page, read it, and declined to index it. lastCrawl has a date.

They sit next to each other in the same report. They call for opposite work. The first is a crawl budget and discovery problem: more internal links, sitemap pings, authority. The second is a quality or duplication judgment: the page was seen and found wanting, and adding more pages like it makes things worse.

The number

I sampled 14 article URLs at random from a 590-page corpus on a data recovery site I run, and inspected each one. I validated the probe on a known-healthy control page first, which came back "Submitted and indexed" as expected.

 4/14   Submitted and indexed                      29 %
 4/14   Google does not recognise this URL     |
 4/14   Discovered - currently not indexed     |   8/14 with lastCrawl = never
 2/14   Crawled - currently not indexed            fetched, then declined

Eight of fourteen pages had never been fetched at all. Only two had been read and rejected.

I had spent the previous hour preparing to write another article for that site. The measurement says that would have produced a 657th URL that Googlebot has never visited. The bottleneck is not the writing. It is that two thirds of what already exists has never been looked at.

That reframes the work entirely: internal linking, sitemap hygiene and off-site authority, instead of publishing volume. Not a conclusion I wanted, which is usually a sign it is the real one.

What I would tell past me

Read the URL out of the artifact you serve. Do not build it from a folder name or a slug you remember.
Run any new probe against a page you already know is healthy, before you trust it on the page you are worried about.
When a check returns zero on everything it looks at, suspect the check first.

The API is not wrong in any of these cases. It answers precisely the question you asked. The gap between that question and the one you meant is where the hour goes.

Eight checks lied to me in one day, and none of them threw an error

ricco020 — Fri, 21 Aug 2026 15:11:19 +0000

In one working day I wrote or relied on eight checks that were wrong. Not one of them threw an
error. Every single one returned a plausible answer, which is exactly why each cost me time.

Here they are, with what they actually returned.

The four ways a check can lie

1. It never runs

I wrote assertions that validate prices against the strings shown to users, then deliberately
corrupted one to confirm the build would fail.

sabotaged price string
BUILD EXIT=0     <- the guard saw nothing

The assertions run on import. Nothing imported the module yet. After wiring it into a page that
is actually built, the same sabotage gave EXIT=1.

A check nothing calls protects nothing, and it is worse than no check, because you believe you
are covered.

2. It caches a stale verdict

A crawler wrote sitemap_absent: true on the first pass. I fixed the fetch, the data came back
correctly, and the report still printed "SITEMAP NOT SERVED" — because the flag was never
cleared.

The JSON on disk said 445 URLs. The screen said absent. I only caught it by opening the artefact
instead of reading the summary.

3. It asks for the wrong shape

Counting rendered questions on a page returned 0. I nearly reported that a paid feature shipped
nothing.

My selectors looked for DOM classes. The items were props of a client component, serialised into
the framework payload as {"q": …}. The page was 16,908 bytes in both measurements. The content
was always there; only my way of counting was wrong.

The fix was not a better guess. It was reading the type definition and counting what the code
actually emits.

4. It includes itself in its own sample

Two on the same day, and this is my favourite.

pgrep -af "next start"
# returns only the bash -c wrapper that contains the pattern

The old server was still holding the port under a different process name. I found it with
ss -ltnp — searching for who holds the port always works; searching for a name you assume it has
does not.

Then, checking whether a new slug collided with existing ones, I globbed the directory — including
the file I had just written. It saw itself and answered "already taken."

A probe that includes itself in its own sample always confirms what it is looking for.

The two failure modes, and why calibration is the whole job

A check can fail in exactly two directions, and I hit both:

too weak   counting accented characters       -> a text with a few accents passes while being wrong
too strong requiring a fixed list of words    -> cries on correct text that had no reason to use them

The German page was correct. My check demanded words the article never needed, and shouted anyway.

A false alarm that repeats gets ignored, and an ignored check protects nothing. That is the
quietest way to lose a safeguard: it stays in the code, it goes green in the reader's head, and it
stops saying anything.

The calibrated version turned out to be: a non-zero count of language-specific characters AND a
few witness words present — not all of them.

What I do now, and it costs three minutes

Test the guard by making it fail on purpose. Not once written, but every time it is written.
Sabotage the input, confirm it screams, restore. Two of my checks passed that test only on the second
attempt, and I would never have known otherwise.

Two other habits that came out of the same day:

Read the artefact, not the summary. The JSON, the manifest, the served HTML.
Prove identity, not just presence. "The server responds" is not "my version responds." A deployment I thought I was testing had never started; the old process answered 200 all along.

That last one is the same shape as a thing I ended up writing about elsewhere: a VPN kill switch
toggle being on tells you what the app intends, not what the operating system will do when the tunnel
dies at an awkward moment. I wrote up the four tests that actually settle it
here.

Eight wrong checks, zero errors raised. A check that crashes gets fixed. A check that answers
slightly the wrong question gets believed.

DEV Community: ricco020

I changed a Play Store title in 4 languages: brand rank went up, generic rank did not move

The change

Three things that are NOT the same measurement

The J+2 numbers (3 November 2026)

A second verdict, same method (4 November 2026)

Why installs were not part of the verdict

The method, reproducible

What we would do differently

DoH costs one TLS handshake, then almost nothing: 45 timed queries to Cloudflare, Google and Quad9

Setup

Results

The practical consequence

One filtering check, while I was there

Limits

Wrong key or wrong short ID? Xray REALITY gives the same error for both

The setup

Results

Two warnings worth reading

The field name changed

One client I could not make work

A 3-line checklist

I checked what 16 web hosts serve on their own homepage: HSTS, HTTP/3, IPv6, TLS 1.3

What I measured

Results: 16 hosts, 11 measurable

Three things I did not expect

What this does NOT tell you

Reproduce it

I checked 40 sites for /.well-known/passkey-endpoints. 11 of the 34 I could measure publish it

Method

Result: 11 of 34 measurable domains

Three things I did not expect

If you run a site with passkeys

One Bing query was 62% of my impressions and never got a click

The numbers

Why this matters more than it looks

The rule I took from it

A pruning rule put my renamed page in noindex: it measured the new URL, the history was on the old one

The pruning rule was reasonable

The rule read the wrong key

What the damage looked like

The fix, and what it cannot undo

The check I should have had

The general pattern

Leaving Vercel with a static site: the redirects you lose without noticing

The failure that does not show up

What had to be rebuilt in the web server

Refuse, do not skip

Two things that bit me anyway

The script

80,000 Search Console impressions, zero clicks: three checks before you call it an opportunity

The numbers

Three checks that took the "opportunity" apart

What I changed

Three of the eight sites that support /.well-known/change-password do not support it

The trap is written into the spec

What I measured

The part I did not expect

If you want to add it

The general lesson

Google said it had never heard of my URL. The URL was fine, my probe was not.

Trap 1: www and non-www are different URLs to this API

Trap 2: the indexed field on sitemaps is zero for everyone

Trap 3: two states that read alike and mean opposite things

The number

What I would tell past me

Eight checks lied to me in one day, and none of them threw an error

The four ways a check can lie

1. It never runs

2. It caches a stale verdict

3. It asks for the wrong shape

4. It includes itself in its own sample

The two failure modes, and why calibration is the whole job

What I do now, and it costs three minutes

Trap 2: the `indexed` field on sitemaps is zero for everyone