DEV Community: shibowen336

Google only saw question 1 of my 100-question quiz

shibowen336 — Sat, 03 Oct 2026 16:03:04 +0000

My quiz site shows one question at a time: a big card, Yes and No buttons, a progress bar. It's a nicer experience on a phone than a wall of 100 checkboxes. It also hid 99% of the page from search engines, and I only noticed because of a ranking that made no sense.

The symptom

Search Console showed two of my pages competing for the site's main keyword:

the homepage, which is the quiz, at an average position of about 45;
a plain "all questions" page, just a list with short notes, at about 28.

The list page has no quiz on it at all. So why was Google preferring it for a query where people clearly want to take the test?

Look at what the crawler gets

The first thing a crawler receives is the HTML your server sends. I fetched my homepage's HTML, stripped scripts and styles, and checked whether a handful of question texts were in what was left:

import html, re, urllib.request

def visible_text(url):
    req = urllib.request.Request(url, headers={"User-Agent": "Mozilla/5.0"})
    raw = urllib.request.urlopen(req).read().decode("utf-8", "ignore")
    raw = re.sub(r"(?is)<(script|style|noscript|svg)[^>]*>.*?</\1>", " ", raw)
    return html.unescape(re.sub(r"<[^>]+>", " ", raw))

probes = ["Held hands romantically", "Been on a date", "Kissed a non-family member",
          "Been convicted of a felony"]  # 8 in total, spread across the test
text = visible_text("https://example.com/")
print(sum(p in text for p in probes), "of", len(probes))

My homepage: 1 of 8. Then I ran the same check against the pages ranking in the top four for that keyword: 8 of 8, every one of them. My own list page: also 8 of 8.

Word count wasn't the difference. The #1 result had about 700 words of visible text, and my homepage had more. The difference was that every page Google ranked above mine put the whole test in its HTML, and mine put one question.

Why it happens

The quiz is a client component. Its state is "which question are you on", restored from localStorage so a refresh doesn't lose your place. At build time (this is a static export) there's no saved progress, so the prerendered HTML contains the initial state: question 1. The other 99 questions exist only as data inside the JavaScript bundle.

"But Google runs JavaScript." It does, but rendering the page doesn't change anything here. Googlebot doesn't click Yes or No, so the rendered DOM still shows one question. Any UI where content is revealed by interaction has the same problem: a step-by-step wizard, a carousel, tabs that mount their panels lazily.

The fix: render the state space as content

I didn't want to change how the quiz works. Instead, below the FAQ, the page now renders every question as a plain numbered list, in a server component:

// components/content/QuestionList.tsx — a server component, no 'use client'
export function QuestionList({ id, heading, intro, questions }: {
  id: string;
  heading: string;
  intro: React.ReactNode;
  questions: readonly string[];
}) {
  return (
    <section id={id} className="mt-12">
      <h2>{heading}</h2>
      <p>{intro}</p>
      <ol className="list-decimal pl-8 sm:columns-2 sm:gap-10">
        {questions.map((q, i) => (
          <li key={i} className="break-inside-avoid">{q}</li>
        ))}
      </ol>
    </section>
  );
}

// app/(en)/page.tsx
<Quiz />
{/* …about, scoring, FAQ… */}
<QuestionList
  id="all-questions"
  heading="All 100 questions"
  intro={<>The full list in the original order. The quiz above asks them one at a time.</>}
  questions={QUESTIONS}
/>

It's the same array the quiz uses, so the two can't drift apart. The list is useful for people too: some visitors want to see what's coming before they start. And it doesn't duplicate the dedicated questions page, because that page groups the questions by theme and explains the confusing ones; the homepage list links there.

Two columns on desktop keep the section from becoming a 100-line scroll. break-inside-avoid stops a long question from splitting across the columns.

Lock it in with a test

This kind of regression is invisible in the browser, because the page looks fine. So there's a test that renders the page and checks the list:

it('lists all 100 questions in their original order below the quiz', () => {
  const { container } = render(<HomePage />);
  const section = container.querySelector<HTMLElement>('#all-questions')!;
  const items = within(section).getAllByRole('listitem').map((li) => li.textContent);
  expect(items).toEqual([...QUESTIONS]);
});

After deploying, I re-ran the probe against the live page: 8 of 8, and visible text went from about 860 words to about 1,520. Then I requested reindexing in Search Console. I applied the same fix to the French version and to the two shorter variants, which had the identical problem.

I don't have ranking results yet, as it's been a few days. What I'm confident about is the diagnosis: for a query whose intent is "take this test", every competitor that outranked the page served the test's content in HTML, and the page didn't.

The takeaway

If your page's main content is state, the questions of a quiz or the steps of a wizard, prerender the whole state space somewhere on the page as ordinary HTML. Then check it the boring way: fetch the HTML, strip the scripts, and search for your content. It takes five minutes and it would have saved me two weeks.

The site is ricepuritytestup.com. (It's my site. The quiz asks personal yes/no questions; your answers are scored in your browser and stay there.)

Adding a second language to a static Next.js site without changing a single URL

shibowen336 — Wed, 30 Sep 2026 16:10:37 +0000

My small quiz site started English-only: a Next.js App Router project, output: 'export', deployed as static files. When I added a French version, I had three rules:

No English URL could change. They were already indexed.
Each page had to declare its real language in <html lang>.
No i18n middleware — a static export has no server to run it.

Here's the setup that satisfied all three, plus the one gotcha that cost me an afternoon.

Why a subdirectory, not a subdomain

/fr rather than fr.example.com or a separate domain. A subdirectory shares the domain's existing authority, so the French pages didn't start from zero in search. That turned out to matter: a few days after launch, the French pages were getting impressions faster than the English ones had.

Two route groups, two root layouts

The App Router lets a route group have its own root layout. Route groups (folders in parentheses) don't appear in the URL, so this moves nothing:

app/
  (en)/
    layout.tsx        ← <html lang="en">
    page.tsx          → /
    questions/page.tsx → /questions
  (fr)/
    layout.tsx        ← <html lang="fr">
    fr/page.tsx       → /fr
  not-found.tsx

Each root layout renders its own <html> and <body>, header and footer:

// app/(fr)/layout.tsx
export default function FrRootLayout({ children }: { children: ReactNode }) {
  return (
    <html lang="fr" className={`${fraunces.variable} ${sourceSerif.variable}`}>
      <body>
        <HeaderFr />
        <main>{children}</main>
        <FooterFr />
      </body>
    </html>
  );
}

Moving the existing English files into app/(en)/ was the whole migration. Every English URL stayed byte-for-byte the same.

The gotcha: your 404 page loses its layout

With a single root layout, app/not-found.tsx renders inside it and inherits your fonts, styles and header. With multiple root layouts, there is no single layout for the global 404 to sit in — Next renders it on its own. Mine silently fell back to an unstyled page with none of my CSS.

The fix is to make not-found.tsx a complete document itself:

// app/not-found.tsx
import './globals.css';

export default function NotFound() {
  return (
    <html lang="en" className={`${fraunces.variable} ${sourceSerif.variable}`}>
      <body>
        <main>
          <h1>Page not found</h1>
          <Link href="/">← Take the test</Link>
          <Link href="/fr">Version française →</Link>
        </main>
      </body>
    </html>
  );
}

It imports the stylesheet and sets up the fonts itself. On a static export this becomes 404.html, which the host serves for any unknown path in either language, so it links to both homepages.

A related trap caught me later: every page embeds the 404's React Server Components payload. When I verified deploys by grepping the HTML for a phrase like "Version française", every page "contained" it — it came from the 404 payload, not the page. Check something unique to the page, or the build status, instead.

hreflang only where a real twin exists

Only the two homepages are true translations of each other, so only they declare alternates, with a small helper:

export function alternateLanguages(paths: { en: string; fr: string }) {
  return {
    languages: { en: paths.en, fr: paths.fr, 'x-default': paths.en },
  };
}

// app/(en)/page.tsx and app/(fr)/fr/page.tsx
export const metadata = {
  alternates: { canonical: '/', ...alternateLanguages({ en: '/', fr: '/fr' }) },
};

The French-only pages (a teen version, a quick 30-question version) declare no hreflang at all. Pointing hreflang at an English page that isn't really the same content does more harm than good. The French metadata helper leaves languages out on purpose, and a test asserts it stays that way.

The language switch is just a plain <a href="/fr" hrefLang="fr"> in the header and footer. No JavaScript, no cookie, no redirect based on Accept-Language, so crawlers and users both see a stable page at every URL.

Ship only the language you need

The quiz is a client component. If it imported both question sets, every French visitor would download the English list too. Instead each server page passes a plain-data "variant" to it:

interface QuizVariant {        // trimmed to the relevant fields
  storageKey: string;          // 'rpt:progress:fr' — progress never collides across versions
  questions: readonly string[];
  bands: readonly ScoreBand[];
  ui: QuizUiStrings;           // every UI string, no functions (must serialise)
  sharePath: string;
}

// app/(fr)/fr/page.tsx (a server component)
<Quiz variant={FR_VARIANT} />

Because the variant crosses the server/client boundary as props, it has to be serialisable. That means no formatter functions, so strings use {score} placeholders filled on the client. The English variant lives in its own module so importing it never drags the French data into the English bundle.

French typography needs no-break spaces

French puts a space before ? ! : ;, and it must not wrap onto the next line. Source strings are written with ordinary spaces for readability, then converted once:

export const frenchSpacing = (text: string) => text.replace(/ ([?!:;])/g, '\u00a0$1');

One side effect showed up in tests. Testing Library's default text normalizer collapses whitespace, and \s includes the no-break space, so getByText(frenchString) failed even though the text was on the page. Passing { normalizer: (t) => t } for those assertions fixed it.

The site is ricepuritytestup.com, with the French version at /fr. (It's my site. The quiz asks personal yes/no questions, but your answers are scored in your browser and never sent anywhere.)

Sharing a canvas-generated image on iOS with the Web Share API

shibowen336 — Sat, 26 Sep 2026 16:25:46 +0000

I run a small quiz site (a Rice Purity Test), and people mostly share their result as a screenshot in an Instagram or Snapchat story. So I added a "certificate": after the quiz, the browser draws a 1080×1920 PNG with the score on it, and a Share button hands it to the phone's share sheet.

Drawing the image was the easy part. Getting the share sheet to behave on iOS took more care. Here's what mattered, in case you're building something similar.

1. Generate the image before the tap, not after

The tempting flow is: user taps Share → draw the canvas → toBlob() → navigator.share(). On iOS Safari that's a trap. navigator.share() only works while the tap's user activation is still valid, and awaiting a canvas render (plus web fonts, see below) can use that up.

So the image is rendered as soon as the result appears:

useEffect(() => {
  let cancelled = false;
  let url: string | null = null;
  renderCertificate(cert)
    .then((blob) => {
      if (cancelled) return;
      url = URL.createObjectURL(blob);
      setState({ status: 'ready', cert, blob, url });
    })
    .catch(() => {
      if (!cancelled) setState({ status: 'failed', cert });
    });
  return () => {
    cancelled = true;
    if (url) URL.revokeObjectURL(url);
  };
}, [cert]);

The File is built ahead of time too, so the click handler reaches navigator.share() without awaiting anything:

const file = useMemo(
  () => (blob ? new File([blob], fileName, { type: 'image/png' }) : null),
  [blob, fileName],
);

A side benefit: the object URL doubles as the src of a small thumbnail <img>, so iPhone users can also long-press it and save it without touching the button.

2. Share the file on its own

The obvious call is navigator.share({ files: [file], text, url }). On iOS, some share targets then take the link instead of the picture, and "Save Image" disappears from the sheet. Sharing only the file fixed it:

navigator.share({ files: [file] }).catch((error) => {
  if (!isHarmless(error)) downloadFile(url, fileName);
});

The site address is printed at the bottom of the certificate instead, so the image still points back to the site wherever it ends up.

3. Feature-detect with canShare, fall back to a download

Most desktop browsers can't share files. navigator.canShare({ files: [file] }) tells you up front, and the button label switches between "Share" and "Save image":

const canShareFiles =
  typeof navigator.share === 'function' &&
  typeof navigator.canShare === 'function' &&
  navigator.canShare({ files: [file] });

The download fallback is the classic temporary anchor:

function downloadFile(url: string, fileName: string) {
  const a = document.createElement('a');
  a.href = url;
  a.download = fileName;
  document.body.appendChild(a);
  a.click();
  a.remove();
}

4. Not every rejection is an error

navigator.share() rejects when the user simply closes the sheet (AbortError), and also when they tap Share again while the sheet is still open (InvalidStateError). Neither should trigger a download, so both are ignored:

function isHarmless(error: unknown): boolean {
  const name = (error as { name?: unknown } | null)?.name;
  return name === 'AbortError' || name === 'InvalidStateError';
}

Anything else falls back to downloading the image.

5. Canvas doesn't wait for your web fonts

Canvas draws with whatever font is available at that moment. If the web font hasn't loaded yet, you silently get the fallback. Two things made this work with Next.js:

next/font gives each font a hashed family name. The layout exposes it as a CSS variable on <html>, so the canvas code reads that variable instead of hard-coding a family name.
Before drawing, it waits for document.fonts.load() for each face, capped at 3 seconds. After that it draws anyway, because a certificate in Georgia is better than no certificate.

function siteFonts() {
  const style = getComputedStyle(document.documentElement);
  const family = (variable: string, fallback: string) => {
    const value = style.getPropertyValue(variable).trim();
    return value ? `${value}, ${fallback}` : fallback;
  };
  const display = family('--font-fraunces', 'Georgia, serif');
  // …the body and mono faces are read the same way
  return { display: (px: number) => `600 ${px}px ${display}` /* , body, mono */ };
}

async function waitForFonts(fonts) {
  if (typeof document.fonts?.load !== 'function') return;
  const loads = [fonts.display, fonts.body, fonts.mono].map((at) =>
    document.fonts.load(at(48)).catch(() => []),
  );
  await Promise.race([
    Promise.all(loads),
    new Promise((resolve) => setTimeout(resolve, 3000)),
  ]);
}

6. Fitting text without a loop

Some lines are long (the site also has a French version, and labels like "Très expérimenté" run wider), so each line shrinks to fit the frame. Text width grows linearly with font size, so there's no need to step the size down in a loop. One measurement is enough:

export function fitFontSize(measure, text, maxWidth, startPx, minPx) {
  const width = measure(text, startPx);
  if (width <= maxWidth) return startPx;
  return Math.max(minPx, Math.floor((startPx * maxWidth) / width));
}

measure is passed in instead of calling the canvas directly, so the layout maths can be unit-tested in jsdom, which has no canvas.

If drawing fails, nothing breaks

If there's no canvas, toBlob() returns null, or anything throws, the certificate block isn't rendered at all and the result card falls back to the old text-and-link share button. Nobody sees a broken image.

You can try it at ricepuritytestup.com: finish the quiz and the certificate appears under your score. (It's my site. The questions are personal yes/no ones, but everything is scored in your browser and nothing you answer is sent anywhere.)