DEV Community: XNOW PRO

I shipped 174 pages across 7 languages. Two were silently broken.

XNOW PRO — Sun, 08 Nov 2026 15:11:02 +0000

Started this as an SEO task. Turned into about six hours of debugging that I want to write down before I forget the details.

The setup

A SaaS site with a service catalog. Prices come from the database and change, so the pages have to be server-rendered. A crawler hitting an empty <div id="app"> sees nothing worth indexing.

Built one renderer, wired it to seven language configs:

zh, en, id, pt, vi, ar, ru

Chinese at the root. The rest get /en, /id, /pt, /vi, /ar, /ru. Each language: a homepage, a pricing page, and 15 platform pages. The sitemap came out around 174 URLs.

Felt good. Then I started actually checking things.

Failure 1: the hreflang cluster wasn't a cluster

I wrote hreflang tags per page, roughly:

<link rel="alternate" hreflang="zh-CN" href="https://example.com/" />
<link rel="alternate" hreflang="en" href="https://example.com/en" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

That was the Chinese page. English had the same three lines with different hrefs. Fine.

Then I added Indonesian, Portuguese, Vietnamese, Arabic, Russian. And I appended them... to the pages I was working on at the time.

Checked the Arabic page: all seven languages listed. Checked the English page: three. The old three, untouched.

Here's what I didn't understand. hreflang isn't seven independent declarations, it's one cluster. If /en says "my alternatives are zh, en, x-default" while /id says "my alternatives are all seven plus x-default", the cluster contradicts itself. Google's documented behavior in that situation is to ignore the conflicting set — not to trust whichever page looks more complete.

So probably none of my hreflang was doing anything.

The fix was boring. Generate from one array, use it everywhere, and include the current language in its own list:

const LANGS = ['zh', 'en', 'id', 'pt', 'vi', 'ar', 'ru'];

const hreflangsFor = (path) => LANGS
  .map(l => ({ lang: LANGS_META[l].code, href: `${BASE}${LANGS_META[l].prefix}${path}` }))
  .concat([{ lang: 'x-default', href: `${BASE}${path}` }]);

Every page calls it. Adding an eighth language later is one array entry, not six template edits.

(Yes, a page should list itself in its own hreflang set. That part confused me at first.)

Failure 2: the `dir="rtl"` that never made it to the page

Arabic needs RTL. I knew that going in and wrote code for it.

Then I curled the live page:

<html lang="ar">

No dir. Arabic rendering left-to-right.

What I'd done was two separate string replacements — one for the language, one to inject dir:

let out = html.replace(/<html lang="[^"]*"/i, `<html lang="${code}"`);

if (dir === 'rtl') {
  // assumes there are other attributes to match around lang
  out = out.replace(/<html ([^>]*lang="[^"]*")/i, '<html dir="rtl" $1');
}

The second pattern expected <html to carry attributes alongside lang. My template's opening tag was literally <html lang="zh-CN"> and nothing else. No match, replace returns the input unchanged, no error anywhere.

The output looked correct in every way I was checking — right title, right description, right canonical, right body. Just backwards text for anyone reading Arabic.

Fix: stop doing partial replacements on that tag.

const setHtmlLang = (html, code, dir = 'ltr') =>
  html.replace(/<html\b[^>]*>/i,
    () => `<html lang="${code}"${dir === 'rtl' ? ' dir="rtl"' : ''}>`);

I left a comment above it telling future-me not to try the clever version again. I give it six months.

The CSS side, which turned out easy

Arabic is not just text direction. Lists indent from the right, table columns flip, that sort of thing.

I was ready to write a second stylesheet. Didn't need to. Logical properties handle it:

/* was margin-left: 20px */
.seo-wrap ul { margin-inline-start: 20px; }

/* was text-align: left */
.seo-table td { text-align: start; }

These mirror themselves when dir="rtl" is set. I changed maybe five declarations and Arabic looked correct without a single [dir="rtl"] override anywhere.

Wish I'd started the project knowing that instead of learning it at 2am.

The check that actually mattered

None of the above would have surfaced from looking at the code. All of it surfaced from looking at what a crawler receives:

# what Googlebot gets back
curl -s -A "Googlebot/2.1" https://example.com/ar | grep -o '<html[^>]*>'
# <html lang="ar" dir="rtl">

# is there real text in there, or just a shell?
curl -s https://example.com/ar | sed 's/<[^>]*>/ /g' | tr -s ' ' | wc -c
# ~6100

That second command is the one I now run on every page before calling anything done.

Because my English page passed every SEO check I had and was still an empty shell. Body text: 599 bytes. <h1> count: 0. HTTP status: 200. Title, description, canonical, hreflang, two JSON-LD blocks — all present and correct, because a prerender step was filling in <head> and then stopping.

Google had been happily indexing it as a thin page for weeks.

A 200 tells you the server responded. It tells you nothing about whether there's a page there. Strip the tags, count the characters. Under a few hundred and you've shipped a shell with good metadata.

What I'd change next time

One source of truth for hreflang, from the very first language. The copy-paste approach holds up fine for two and quietly falls apart at three.

And verify the rendered output, not the code that produces it. Both of these bugs read fine as code. Neither showed up until I fetched the actual URLs and looked at the bytes.

I'm building this for XNOW PRO, a social media growth panel — the multilingual layer covers those seven languages now. The pricing page is where the server-rendering earns its keep: real catalog prices in the HTML, no JavaScript required to see them.

Zero-dependency Google Indexing API with Node.js crypto

XNOW PRO — Sun, 08 Nov 2026 14:51:57 +0000

I needed to submit 174 URLs to Google's Indexing API from a production server running Python 3.8 with system pip. The official quickstart uses google-auth, which meant either polluting system packages or spinning up a venv just to run one script.

So I did it with Node's built-in crypto instead. Zero dependencies, no install step.

What the API actually needs

Google's Indexing API takes an OAuth 2.0 access token from a service account. The flow is:

Sign a JWT with the service account's private key (RS256)
Exchange that JWT for an access token
Call the API with Authorization: Bearer <token>

Most tutorials stop at "use the library". Here's what's underneath.

Step 1: sign the JWT

import { createSign } from 'node:crypto';
import { readFileSync } from 'node:fs';

const b64url = (buf) => Buffer.from(buf).toString('base64')
  .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');

const key = JSON.parse(readFileSync('service-account.json', 'utf8'));
const now = Math.floor(Date.now() / 1000);

const signingInput = [
  b64url(JSON.stringify({ alg: 'RS256', typ: 'JWT' })),
  b64url(JSON.stringify({
    iss: key.client_email,
    scope: 'https://www.googleapis.com/auth/indexing',
    aud: 'https://oauth2.googleapis.com/token',
    iat: now,
    exp: now + 3600,
  })),
].join('.');

const signer = createSign('RSA-SHA256');
signer.update(signingInput);
const assertion = `${signingInput}.${b64url(signer.sign(key.private_key))}`;

Two details that bite people:

base64url, not base64. JWT uses the URL-safe alphabet with padding stripped. Standard base64 gives you a token that looks fine and validates as garbage.
createSign takes the PEM as-is. No need to strip the -----BEGIN PRIVATE KEY----- header — Node parses it.

Step 2: exchange for an access token

const res = await fetch('https://oauth2.googleapis.com/token', {
  method: 'POST',
  headers: { 'content-type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({
    grant_type: 'urn:ietf:params:oauth:grant-type:jwt-bearer',
    assertion,
  }).toString(),
});
const { access_token } = await res.json();

That grant_type value is a mouthful and easy to typo. It's jwt-bearer, not jwt or bearer.

Step 3: publish the URL

await fetch('https://indexing.googleapis.com/v3/urlNotifications:publish', {
  method: 'POST',
  headers: {
    authorization: `Bearer ${access_token}`,
    'content-type': 'application/json',
  },
  body: JSON.stringify({
    url: 'https://example.com/page',
    type: 'URL_UPDATED',
  }),
});

A 200 with {"urlNotificationMetadata":{"url":"..."}} means accepted. Not indexed — accepted. There's a difference and it will save you a support ticket.

The gotchas

The service account must be a Search Console owner

Creating the service account and downloading the key is the easy part. What the docs bury:

Go to Search Console → Settings → Users and permissions → Add user, paste the service account email (looks like name@project-id.iam.gserviceaccount.com), grant Owner.

Skip this and every request returns 403 with no useful detail about why.

Quota is 200 URLs per day

Hitting the limit returns HTTP 429. My sitemap had 174 URLs, so I got exactly one full pass per day. Submit more than once and the second run fails partway — log which URLs succeeded so tomorrow's run doesn't waste quota re-submitting them.

Bing's numbers are different

Bing's URL Submission API docs mention 10,000 URLs per day. The real limit, as of now:

{"ErrorCode":8,"Message":"ERROR!!! You have exceeded your daily url submission quota : 100"}

100 per site per day. Their batch endpoint (SubmitUrlbatch) exists but it's subject to the same 100. Plan for two days on a 174-URL site.

IndexNow and the Indexing API are not interchangeable

Google doesn't participate in IndexNow — it only accepts Search Console. Bing, Yandex, Seznam, and Naver do accept IndexNow and don't need an API key at all.

If you want both search ecosystems covered, you need both mechanisms:

Channel	Covers	Auth needed
IndexNow	Bing, Yandex, Seznam, Naver	Just a key file on your server
Indexing API	Google	Service account + Search Console owner

Why use the API at all if I have a sitemap?

A sitemap says "here's what I have". The crawler decides when to care. The Indexing API says "this page changed, come now". On a new site with no domain authority, that's the difference between weeks and hours.

Whether it moves rankings is another question — it doesn't. It just gets you into the queue faster, which is a prerequisite for everything else.

I built this while working on the SEO layer for XNOW PRO, a social media growth panel. The part that took the longest wasn't the indexing — it was rendering 174 pages across 7 languages with correct hreflang clusters and RTL support. The pricing page is a good example: it renders real-time catalog data server-side so crawlers see actual prices instead of a loading spinner.