Technical SEO for Indie Developers: Diagnose First, Then Decide Whether to Change Code

The type of SEO advice that worries me most is the kind that gives you actions without diagnosis: "just switch to SSR if content isn't indexed," or "change the titles if traffic drops." After reading iCanvas's experiment and Vercel and MERJ's research, I'd rather ask first: which step actually went wrong? This article puts cases back into actual troubleshooting processes, compares HTML, rendering, and indexing evidence, then decides which code changes are worth making and which framework migrations aren't necessary.

Indie Developer SEO Playbook · First Article. Compiled from public cases, sources verified as of September 2026.

Two Seemingly Contradictory JavaScript SEO Studies

SearchPilot published iCanvas's category page experiment in 2017. Back then, some product content and links depended on JavaScript—they became invisible when scripts were disabled, but GSC's crawl and render checks displayed the page normally.

The team removed this dependency on only half the category pages, leaving the other half unchanged. The experiment reported a natural search improvement exceeding 6%. An often-overlooked detail: the actual changes were mainly in CSS, not migrating the entire site to another framework. iCanvas Experiment Source

I think this case is worth reading, not because it "proves SSR gives a 6% boost," but because it separates two problems:

A page showing up in one inspection doesn't mean the delivery method has no room for improvement; improving content visibility in one place doesn't mean you must重构整个应用.

But stopping there easily leads to using nine-year-old experiments to guide today's architecture.

Vercel and MERJ's 2024 research analyzed over a hundred thousand Googlebot crawls, with main samples from nextjs.org and supplementary data from two other sites. After excluding error states and non-indexable pages, they observed complete rendering of sample HTML and verified handling of async content and RSC streaming. Research Methods and Results

My interpretation: this sufficiently counters the blanket claim that "Google can't see JavaScript," but it can't guarantee any random website has no issues with API access, permissions, timeouts, or page states. It's also not a ranking comparison across all frameworks.

One study observes rendering capability; the other measures search effects from specific page changes. The eras, samples, and metrics differ—there's no need to pick either as dogma.

I'd Compare Three Page Snapshots First, Not Framework Config

If a public product page isn't indexed, I'd gather three pieces of evidence:

The first is the server-returned HTML. It shows what the initial request delivered.

The second is the browser's final page without login or history state. It shows what a regular visitor gets after script execution.

The third is the crawl or test result in GSC URL Inspection. It shows what Google saw at that point in time.

Google still categorizes JavaScript page handling into crawling, rendering, and indexing, noting that blocked resources won't participate in rendering normally, and server-side output or pre-rendering can help both users and crawlers that can't execute scripts. Google JavaScript SEO Documentation

Here's the basic command I'd use—domain and body keywords need replacing. It's a check method, not a client fault record:

curl --compressed -sS -L   -D /tmp/seo-page-headers.txt   -o /tmp/seo-page.html   https://example.com/features/export

rg -n 'HTTP/|[Ll]ocation:|[Xx]-[Rr]obots-[Tt]ag:' /tmp/sep-page-headers.txt
rg -n '<title|canonical|name="robots"|导出功能' /tmp/seo-page.html

I'd actually send GET requests, not just HEAD, because I need to check the body. When following redirects, I'd also check intermediate states, not just see the final 200 and stop.

Another detail: finding product copy in an HTML file doesn't mean it's necessarily visible body text. The copy might just be serialized data in a script. I'd check which element it's in and what the rendered DOM looks like.

Only when these three pieces of evidence disagree does the troubleshooting direction become clear.

The point of this table is to reduce trial and error. In the last case, adding keywords page by page wouldn't even touch the problem.

"Crawled But Not Indexed" Doesn't Directly Translate to Poor Content

I'd first find three same-template pages: one that indexes normally, one that's been unindexed for a long time, and one published recently. Comparing these is usually more effective than staring at total unindexed counts.

Assume a fictional template site has these URLs:

/templates/invoice
/templates/invoice?color=blue
/templates/invoice?sort=popular
/templates/invoice-for-freelancers

Color and sort parameters might just be views of the same content; the freelancer template likely has different fields, examples, and usage instructions. The two shouldn't mechanically use the same canonical rule.

Google treats redirects, canonicals, and sitemaps as normalization signals of varying strength—your site's signals should stay consistent; declaring canonical doesn't force search engines to accept it. Google Canonical URL Guide

My operation sequence would be:

First, check if GSC's user-declared canonical matches Google's selected canonical. If different, open the selected page and compare actual content.

Next, check if the sitemap and internal links both recommend the same version. If the site declares A as canonical on one hand but links to B everywhere, fix this conflict first.

Only then judge whether the page has independent value. If the freelancer page just replaces the title and is otherwise identical to the generic page, I wouldn't insist on keeping it just because it has a set of keywords. Conversely, if the fields, examples, and tasks genuinely differ, I shouldn't merge it back to the main page just to "concentrate权重."

As for noindex and robots.txt, I only remember one troubleshooting principle: after blocking crawl, you can't expect the crawler to read the page's noindex. Access restriction, indexing intent, and canonicalization are three separate things. Google Noindex Documentation

Fix Priority Depends on Damage Scope

If I only have a weekend for SEO, I wouldn't sort by audit tool error counts.

A whole-site public page mistakenly carrying noindex is just one rule but affects all entry points. Two hundred old article descriptions with duplicate content looks like a bigger number, but isn't necessarily more urgent.

I'd first fix blocking issues like important pages being inaccessible, incorrect canonicalization, or missing core body text. Then address discoverability issues—key pages being hard to find from navigation or body content. Finally, title expression, images, and performance details come last.

Same with performance. A page freezing so users can't complete registration is worth fixing immediately; simply bumping a lab score from 95 to 100 requires comparing engineering time against actual benefit first. Google also explicitly states that good Core Web Vitals don't guarantee higher rankings. Google Page Experience Documentation

This isn't to say details are useless—it's that small teams can't afford to "do all the recommendations at once."

I'd Write Fixes as Acceptance Criteria

"Optimize JavaScript SEO" is hard to accept. I'd rather write the task as:

Problem:
Product category page's core product links depend on a client-side request that's prone to failure.

This Change:
Make the current category's basic product list and detail links available in the initial HTML.
Retain client-side filtering; don't change URLs or titles simultaneously.

Engineering Acceptance:
Anonymous GET can retrieve body and real href.
Empty category and non-existent category status codes match design.
Browser interaction matches original.

Search Observation:
Record deployment time.
Check Google's re-crawled page version.
Monitor impressions, clicks, and subsequent product usage by category page.

Here I must distinguish between "fix deployed" and "search effect proven."

Server returning correct content is an immediately verifiable engineering result. Indexing and search performance require subsequent data; single-page growth before and after might also be affected by seasonality, competition, or other changes. When the latter hasn't arrived, don't package the former as a growth experiment.

What I'm genuinely willing to take away from these cases is this working method: first leave evidence that can explain the failure, then make modifications as localized as possible. Many technical SEO problems need an accurate patch, not a framework migration.

Next article: How to Choose Your First Keywords: Product SEO Breakdown from Plausible and Bannerbear