One category of technical SEO advice worries me most: it tells you what to do but not how to diagnose the problem. If a page isn't indexed, switch to SSR; if traffic drops, rewrite the title. After reading the iCanvas experiment and the research from Vercel and MERJ, I'd rather start by asking: which step actually went wrong? This article puts those cases back into a hands-on troubleshooting process, compares the evidence for HTML, rendering, and indexing, and then decides which code is worth changing and which frameworks don't need replacing.
Indie Developer SEO in Practice · Part One. Compiled from public case studies; sources checked in September 2026.
Two seemingly contradictory pieces of evidence on JavaScript SEO
In 2017, SearchPilot published the iCanvas category-page experiment. At the time, some product content and links depended on JavaScript and were invisible when scripts were disabled, but GSC's crawl and render checks displayed the pages normally.
The team removed that dependency on only half of the category pages and left the other half unchanged. The experiment reported a gain of more than 6% in organic search performance. One easily overlooked detail: the changes were mainly to the CSS; the site was not migrated to a different framework. Original iCanvas experiment
I think this case is worth reading not because it proves that “SSR can boost organic performance by 6%,” but because it separates two problems:
The fact that a page renders in a single check doesn't mean there's no room to improve how it's delivered; making one piece of content visible doesn't mean the entire app needs to be refactored.
But if you stop there, it's easy to use a nine-year-old experiment to guide today's architecture.
In 2024, research from Vercel and MERJ analyzed more than 100,000 Googlebot crawls. The primary sample came from nextjs.org, with supplementary data from two other sites. After excluding error responses and non-indexable pages, the researchers observed complete rendering of the HTML in their sample and verified Google's ability to handle asynchronous content and streamed RSC content. Research methodology and results
My take is this: it's enough to refute the blanket claim that “Google can't see JavaScript,” but it doesn't guarantee that any site's APIs, permissions, timeouts, and page states are working. Nor is it a head-to-head ranking experiment across frameworks.
One study observes rendering capability, while one experiment measures the search effect of a change to specific pages. They span different periods and use different samples and metrics, so there's no reason to pick a side and treat it as gospel.
I'd compare three versions of the page before checking framework settings
If a public product page isn't indexed, I'd collect three pieces of evidence:
First, the HTML returned by the server. It shows what the initial request delivered.
Second, the final page in a browser with no login and no prior session state. It shows what a regular visitor can get after the scripts have run.
Third, the crawl or test result in GSC's URL Inspection tool. It shows what Google saw at that point in time.
Google's official documentation still divides the handling of JavaScript pages into crawling, rendering, and indexing. It also warns that blocked resources won't participate in rendering as normal, and that server-side output or prerendering can help users and crawlers that can't execute scripts. Google JavaScript SEO documentation
These are the basic commands I'd use; replace the domain and body keyword as needed. This is a diagnostic procedure, not an incident report for any particular customer:
I'd send an actual GET, not just a HEAD, because the final check needs to cover the body content. When following redirects, I'd inspect the intermediate responses too, rather than stopping once I see the final 200 response.
One more detail: finding product copy in the HTML file doesn't mean it's necessarily visible body content. The copy might only be serialized data within a script. I still need to check which element contains it and what the DOM looks like after rendering.
Only when these three sources disagree does the troubleshooting path become clear.
| Observation | What I'd suspect first | Next step |
|---|---|---|
| The raw HTML has no body content, but both the browser and Google do | It depends on scripts, but that doesn't yet tell us whether anything is broken | Check stability and the actual indexing status; don't rush to migrate |
| The browser has body content, but Google doesn't | Resource access, session state, interaction dependencies, or script execution failures | Compare network requests with server logs |
| All three have body content, but the page still isn't indexed | Canonicalization, duplicate content, or insufficient page value | Check the canonical URL Google selected |
| An entire directory suddenly fails while the others work | A shared template or deployment change | Spot-check pages that use the same template, then compare deployment times |
The point of this table is to narrow the scope of trial and error. In the last scenario, adding keywords one page at a time would basically miss the problem.
“Crawled but not indexed” doesn't automatically mean the content is bad
I'd start by finding three pages that use the same template: one that's indexed normally, one that has remained unindexed for a long time, and one that was published recently. Comparing them is usually more effective than watching the sitewide count of unindexed pages.
Suppose a fictional template site has these URLs:
/templates/invoice
/templates/invoice?color=blue
/templates/invoice?sort=popular
/templates/invoice-for-freelancers
The color and sorting parameters may simply be different views of the same content; the freelancer-focused template may have different fields, examples, and usage instructions. You shouldn't automatically apply the same canonical rule to both.
Google treats redirects, canonical URLs, and sitemaps as canonicalization signals of varying strength. A site's own signals should agree with one another, and declaring a canonical URL doesn't force search engines to accept it. Google canonical URL guide
My sequence would be:
First, I'd check whether the user-declared canonical URL in GSC matches the canonical URL Google selected. If not, I'd open the selected page and compare its actual content.
Next, I'd check whether the sitemap and internal links both point to the same version. If the site calls A the official version but links to B everywhere, I'd fix that conflict first.
Only then would I determine whether the page has standalone value. If the freelancer page merely swaps the title and is otherwise identical to the general page, I wouldn't insist on keeping it just because it targets a set of keywords. Conversely, if the fields, examples, and tasks really are different, it shouldn't be folded back into the homepage just to “concentrate authority.”
As for noindex and robots.txt, I keep just one troubleshooting principle in mind: once crawling has been blocked, you can no longer expect a crawler to read the noindex on the page. Access restrictions, indexing intent, and canonicalization are three separate things. Google noindex documentation
Prioritize fixes by the scope of impact
If I had only a weekend to tackle SEO, I wouldn't sort the issues by the number of errors an audit tool reports.
If every public page on a site accidentally has a noindex tag, that's just one misconfigured rule, but it affects every entry point. Duplicate descriptions across 200 old posts may look like a much bigger issue, but they aren't necessarily more urgent.
I'd start with blockers such as inaccessible key pages, incorrect canonicalization, and missing core body content. Next, I'd address key pages that are hard to discover via navigation or the main content. Only then would I turn to title wording, images, and performance details.
Performance is no different. If a page is so slow that users can't complete signup, it's worth fixing immediately. If the only goal is to move a lab score from 95 to 100, compare the engineering time with the real-world benefit first. Google has also stated explicitly that good Core Web Vitals don't guarantee good rankings. Google page experience documentation
This doesn't mean details don't matter; it means a small team can't afford to “do every recommendation at once.”
I'd write fixes as acceptance criteria
“Optimize JavaScript SEO” is hard to verify. I'd rather write the task like this:
Here, we have to distinguish “the fix has shipped” from “the search results prove it worked.”
Correct content returned by the server is an engineering result you can verify immediately. Indexing and search performance have to wait for subsequent data; a single page's growth before and after launch may also be affected by seasonality, competition, and other changes. Without the latter, you can't package the former as a growth experiment.
What I really take away from these cases is this way of working: first collect evidence that can explain the failure, then make the most narrowly scoped change possible. Many technical SEO problems need a precise patch, not a round of framework migration.
Next: How to Choose Your First Batch of Keywords: Breaking Down Product SEO with Plausible and Bannerbear