Technical SEO Audit for JavaScript Apps: The Fix That Took Formula Dream From 64 to 36,758 Weekly Impressions

Technical SEO audit for JavaScript apps is not glamorous work, but it can be the highest-leverage growth channel a small product team has. A candid r/SaaS post from Formula Dream, a free Formula 1 companion app, illustrates why: after nearly a year of limited discovery efforts, making existing content crawlable helped move the site from a median 64 Google impressions per week to 36,758.

The important lesson is not that every startup should mass-produce thousands of SEO pages. It is that distribution is often diagnosed as a marketing problem when the underlying issue is technical discoverability: search engines cannot rank content they cannot reliably see, understand, index, and connect to a relevant query.

Formula Dream’s founder shared unusually specific numbers about the company’s app growth, channel experiments, rendering failures, and Search Console results in the original r/SaaS post. The account is valuable precisely because it does not present a polished overnight-success narrative. It documents modest traffic, labor-intensive social promotion, failed deployments, and a surge in impressions that still required careful interpretation.

The Formula Dream case: a visibility problem disguised as a marketing problem

Formula Dream had been available on iOS and Android for roughly a year and had accumulated 2,811 downloads across both stores, according to the founder’s post. The team believed the product itself was useful enough to retain people who found it. The bottleneck was awareness.

That distinction matters. Founders commonly use "growth" as a catch-all term for at least four separate challenges:

1. Product value: Does a new user get enough value to return?
2. Discoverability: Can potential users find the product at the moment they need it?
3. Conversion: Does the landing page, app-store listing, or signup flow turn interest into action?
4. Retention and referral: Do users keep using the product and tell other people about it?

The Formula Dream data pointed primarily to discoverability. Across the final 90 days reported in the post, the site recorded 3,494 sessions from all channels. Direct traffic led at 1,229 sessions, followed by Google organic search at 715, Facebook at 462, Instagram at 427, shared links at 133, Reddit at 128, AI assistants including ChatGPT and Gemini at 76, Bing at 39, app directories at 29, and Quora at 16.

These are not blockbuster numbers, and that is why they are useful. Most early-stage teams are operating at this scale or below it. At that level, a few hundred sessions can represent meaningful work, but it can also reveal whether a channel has a compounding mechanism or merely creates a short-lived spike.

The founder’s framing was clear: no channel should be evaluated in isolation from the labor required to sustain it. A tactic that sends traffic is not automatically a scalable acquisition system.

Manual distribution worked—but it did not compound

The case makes a useful distinction between traffic that arrives because someone is actively pushing it and traffic that continues because an asset remains discoverable.

Formula Dream’s Facebook activity generated 462 sessions. That result came from manually joining, reading, and tailoring posts for 25 groups, plus activity on its page. Reddit contributed 128 sessions after the team adjusted its behavior following an initial account shadowban caused by overly aggressive tool-link promotion. Across Facebook and Reddit, the founder reported 590 sessions—more than Google organic traffic over the same period.

On the surface, that could suggest social community posting was the winning strategy. But the effort had a structural weakness: when the posting stopped, the traffic stopped too.

The difference between a channel and an asset

A manual channel can still be worthwhile, especially when a team needs user conversations, early feedback, and real-world language from a niche audience. Formula 1 communities may tell a product team which race data, radio clips, driver comparisons, or alerts fans genuinely care about.

However, founders should not confuse that with durable distribution. A useful way to classify a tactic is to ask three questions:

• Does the work create an asset that remains useful after this week?
• Can a future user discover that asset without the founder repeating the same action?
• Does the asset improve as the company adds more data, content, users, or links?

A thoughtful answer on Quora, a genuinely useful Reddit comment, or a social post can sometimes become a durable asset. But it is not guaranteed. Platform rules, moderation, feed algorithms, link treatment, and community norms limit how predictably founders can turn participation into traffic.

That does not mean teams should abandon communities. It means they should use them for what they are good at: learning, relationship building, validation, and initial reach. They should not rely on them as the sole answer to long-term discoverability.

What the technical SEO audit for JavaScript apps uncovered

The breakthrough did not begin with a new content campaign or a viral post. Formula Dream stopped adding new things and audited what already existed.

The audit uncovered two central problems.

First, the product’s tool landing pages were not actually rendering their useful data in a crawler-visible way. The founder had assumed the pages were server-rendered, but they were not. A gap visualizer page reportedly exposed hard-coded example figures rather than live, descriptive data such as driver names.

Second, and more consequentially, the site’s best searchable asset was effectively empty to crawlers. Formula Dream had an archive of about 39,000 team-radio clips with transcripts. Yet the page data only contained a reference to the transcript file; the actual words were stored in separate files retrieved from a CDN after the initial page loaded.

For a human visitor using a modern browser, that architecture may appear functional. For search discovery, it created a major risk: the page shell might be available, while the meaningful text—the phrases fans actually search for—was absent, delayed, inaccessible, or unreliable in the crawl-and-render process.

Google does process JavaScript, but its own documentation cautions developers to account for the differences between crawling, rendering, and indexing JavaScript applications. Google specifically recommends server-side rendering, static rendering, or hydration as durable approaches instead of treating dynamic rendering as the long-term answer. That guidance does not mean every client-rendered page will fail, but it does mean a visual browser check is not proof that the page is search-ready.

Why this failure is so common

JavaScript apps often separate interface code from content data for reasonable engineering reasons: smaller initial payloads, CDN caching, dynamic filtering, personalization, or easier front-end iteration. The problem begins when a team fails to test the actual HTML and rendered output that search engines receive.

A page can pass a product QA check while failing a search QA check. Common warning signs include:

• A page source that contains navigation and loading placeholders but little substantive content.
• Content fetched only after client-side JavaScript runs.
• Important text loaded only after a user scrolls, clicks, chooses a filter, or starts audio.
• API calls that fail in production, even though the app shell renders successfully.
• Pages that return HTTP 200 while their essential data is missing.
• Sitemap URLs that resolve but have thin, repetitive, or incomplete content.

The Formula Dream incident also exposes a deployment lesson. The founder reported four failed deploys that all passed as green builds, including an artifact-size problem, a release with code but not data, stale configuration that created 404s for new pages, and an audio embed that appeared without functioning audio. Build success is not the same as content availability, crawlability, or end-user functionality.

The repair: make the valuable information part of the page

Formula Dream’s team spent about three weeks implementing a more crawlable architecture. According to the post, the work included server-rendering the tool data, aggregating 37,521 transcripts into per-session bundles, and publishing 877 radio pages containing the actual speech as text. The sitemap expanded from 286 URLs to 1,169.

This was not a pure URL-count play. The high-leverage change was the combination of three things:

1. The pages contained meaningful information. Search engines and readers could access actual driver-radio language rather than empty labels or references.
2. The content was organized into queryable units. Session-level radio pages gave the archive a structure that could match specific events, drivers, teams, and race moments.
3. The URLs were discoverable. The enlarged sitemap helped communicate which pages the site considered important and made URL discovery more systematic.

A sitemap is not a ranking switch. Google describes it as a way to provide information about the important pages and files on a site so search engines can crawl them more efficiently. In practical terms, the sitemap helps discovery; it does not compensate for thin content, broken rendering, duplicate pages, or lack of relevance.

That nuance is important for programmatic SEO. Creating 877 pages is useful if every page represents a meaningful, unique unit of information for a user. Generating 877 near-identical pages with a swapped keyword is much less likely to create durable search value.

Programmatic SEO is a publishing system, not a page generator

The Formula Dream archive is a strong example of a dataset with real editorial value. F1 radio transcripts can answer highly specific questions that ordinary editorial articles struggle to cover comprehensively: what a driver said in a particular session, which team messages occurred during a race, or how a moment unfolded through team communications.

A useful programmatic page should have all of the following:

• A distinct user intent.
• Source material that is genuinely useful on its own.
• Clear context: event, date, driver, team, session, or category.
• Internal links that help users and crawlers navigate adjacent content.
• A canonical strategy where pages are similar or filterable.
• A stable, indexable URL rather than a state hidden behind a client-side interface.

For SaaS companies, the equivalent may be template galleries, integration directories, benchmark pages, public status histories, documentation pages, calculators, examples, or searchable libraries. A transactional-email platform, for example, might create useful resources around deliverability diagnostics, provider migrations, API examples, or address-quality workflows—provided each page solves a concrete problem rather than merely existing for a keyword.

The results were dramatic, but impressions were not the finish line

Formula Dream’s Search Console data showed a striking change. After a median of 64 impressions per week for 37 weeks through late June, the site reported 2,855 impressions in the week beginning July 13, then 17,994, 29,846, and finally 36,758 weekly impressions in subsequent reported weeks. Clicks climbed from 69 to 547 over the same period.

The team’s immediate reaction was understandable: it looked like awareness had finally been solved. But the founder then noticed an uncomfortable signal in the average-position data, which fluctuated as impressions surged. The post cuts off while examining what the new impressions were actually made of, but the question is the right one.

An impression increase can mean more visibility, but it does not automatically mean more qualified demand. Search Console’s Performance report separates impressions, clicks, queries, pages, countries, and other dimensions precisely because an aggregate graph can conceal important changes in audience intent and ranking distribution.

How to interpret a sudden impressions spike

When a site goes from dozens to tens of thousands of weekly impressions, teams should investigate before declaring victory. Use this checklist:

1. Segment by page. Which specific URLs generated the new visibility? Is the growth concentrated in a useful content cluster or spread across low-value pages?
2. Segment by query. Are people searching for the topic your product can serve, or are they finding incidental phrases that do not lead to meaningful engagement?
3. Compare clicks and CTR. A larger impressions base often lowers average click-through rate because a site begins appearing for broader, lower-ranked queries. That can be healthy, but it needs context.
4. Inspect position distribution. Average position is an aggregate metric. A move from position 6 to 9 may reflect many new impressions at lower positions rather than a deterioration of the original rankings.
5. Check downstream behavior. Look at engaged sessions, app-store clicks, signups, feature use, retention, and conversion by landing page.
6. Review index quality. Confirm the new URLs are canonicalized correctly, return valid status codes, contain complete content, and are not near-duplicates.

The right north-star metric depends on the product. For a free companion app, organic impressions may be an early indication of awareness, but app installs and retained active users are closer to business value. For a B2B SaaS product, a more meaningful chain might be indexed pages, qualified organic sessions, product signups, activated accounts, and retained paid customers.

Why average position can mislead founders

Average position is a useful diagnostic, not a scorecard. It is especially easy to misread when a site begins ranking for a much broader set of long-tail searches.

Imagine a site that previously showed near the top of the results for 20 narrow queries. After publishing hundreds of useful pages, it may begin showing on page one or page two for thousands of adjacent terms. The average position can worsen even though the site is earning far more visibility, clicks, and future ranking opportunities.

Formula Dream’s results are consistent with that possibility, although only a query- and page-level breakdown could establish it. The lesson is to resist a single-metric narrative in either direction. Neither "impressions exploded, so we won" nor "average position fell, so the work failed" is adequate analysis.

Google’s own Search Console guidance encourages using the Performance report to investigate queries and pages, not merely to watch a top-line total. For larger sites with many long-tail terms, Google also provides a bubble-chart analysis framework for distinguishing high-opportunity queries from low-CTR or low-position clusters.

A better reporting model for small teams

A founder-friendly SEO dashboard should answer a sequence of questions, not display a collection of vanity metrics:

The practical advantage of this model is that it tells a team what to fix next. If index coverage is weak, improve technical foundations. If impressions rise but clicks lag, improve titles, snippets, and intent match. If clicks rise but conversions lag, improve the landing experience and product path.

A practical technical SEO audit for JavaScript apps

The Formula Dream story provides a strong starting point for a repeatable audit. The goal is not to turn every engineer into an SEO specialist. It is to establish a release process that treats crawlable content as a product requirement.

1. Inventory pages and classify their search value

Export all known URLs from your sitemap, CMS, app routes, analytics, and Search Console. Group them into categories such as marketing pages, docs, templates, tools, directories, user-generated content, and data pages.

For each category, answer: what exact information exists on this URL that a user could search for? If the answer is vague—"it is an interactive dashboard"—there may be no durable search surface yet. Consider whether an indexable summary, table, explanation, transcript, or static result can coexist with the interactive experience.

2. Inspect the raw HTML and rendered output

Do not rely solely on what appears in your browser. Compare:

• The initial HTML response.
• The rendered DOM after JavaScript execution.
• The text visible in URL Inspection or another crawler-oriented testing workflow.
• The network requests required to assemble the page.

Pay special attention to primary headings, descriptions, body copy, tables, product data, transcript text, internal links, canonical tags, and structured data. If the important information exists only after an API request succeeds in the browser, build a fallback or rendering strategy that makes it reliably available.

3. Test all important routes after deployment

Formula Dream’s green-build failures are a reminder that CI signals only validate what you explicitly test. Add post-deploy checks for representative URLs in every critical page type.

A lightweight smoke-test suite can verify that a page returns 200, contains an expected heading, includes a minimum amount of meaningful text, does not expose a loading-only state, and has no broken data request. For pages that include rich assets such as audio or video, verify the asset URL and playback behavior separately.

4. Build a sitemap that reflects real information architecture

Include canonical, indexable URLs that you want search engines to discover. Update the sitemap as significant content is added, removed, or reorganized, but do not treat it as a dumping ground for every filter permutation.

For large or segmented content libraries, use sitemap indexes and separate files by page type where useful. That structure makes it easier to monitor coverage and diagnose whether a particular page cluster is not being crawled or indexed.

5. Make internal links intentional

Crawlers and users need pathways through a data library. Link related pages by meaningful entities and tasks: a session to a driver page, a transcript to the relevant event, an integration page to setup documentation, or a template to adjacent templates.

Use descriptive anchor text, keep links accessible without required user interaction, and ensure pagination or "load more" experiences expose crawlable URLs where content spans multiple pages. Google’s documentation specifically notes that crawlers do not perform interactions such as scrolling and clicking to load content, which makes user-triggered loading risky for essential content.

6. Validate outcomes in Search Console, analytics, and the product

Submit updated sitemaps, inspect representative URLs, and then allow time for crawling and indexing. Track leading indicators, but avoid reacting to every daily change.

Finally, connect organic landing pages to business behavior. The SEO report should identify not only which pages receive impressions, but whether people who land there explore the app, install it, sign up, or return.

Server-side rendering is not a magic ranking tactic

It would be easy to reduce the Formula Dream story to a slogan: "Use server-side rendering and win at SEO." That is too simplistic.

Server-side rendering can make important content easier to deliver in the initial response, reduce dependence on client-side fetches, and create a more reliable path for crawlers. But rendering alone does not generate demand, earn links, satisfy user intent, establish topical authority, or make an undifferentiated page useful.

The durable principle is more fundamental: the information that answers the searcher’s question must be accessible, specific, complete, and reliably delivered. Static generation, server-side rendering, hydration, and carefully implemented client-side rendering can all support that objective depending on the product architecture.

For founders choosing a framework or rendering pattern, the practical questions are:

• Is the page’s primary content present when the server responds?
• What happens if a data request fails?
• Can the page still communicate its purpose without JavaScript?
• Does each URL have enough unique content to deserve indexing?
• Can a crawler discover the URLs and follow links between them?
• Do deployment tests verify actual content, not merely successful compilation?

That approach also protects user experience. If a mobile user on a slow connection sees useful text immediately while interactive charts, filters, or audio controls progressively enhance the page, both accessibility and discoverability improve.

The broader growth lesson: fix the constraint before buying more distribution

Formula Dream’s channel table is a useful warning against premature marketing escalation. The team tried Facebook groups, Instagram, Reddit, Quora, directories, review-site pitches, Dev.to cross-posts, Twitter Spaces, and preparation for Product Hunt. Some tactics sent traffic; many did little that was measurable.

None of those experiments were necessarily irrational. But if the website’s strongest asset was invisible to Google, adding more promotion would have amplified a leaky system. The technical fix created a compounding surface: a searchable archive that could keep being discovered after the team stopped manually posting.

For founders and marketers, the order of operations should often be:

1. Confirm the product provides real value for the people who find it.
2. Identify the strongest existing asset or dataset.
3. Verify that the asset is technically accessible to search engines and users.
4. Organize it around clear, high-intent tasks and entities.
5. Measure query quality, conversion, and retention—not visibility alone.
6. Use community and paid distribution to accelerate learning and seed awareness, rather than mask technical gaps.

This is also where technical and marketing teams need a shared operating model. Marketers may see flat organic traffic and ask for more content. Engineers may see a fast, polished interface and assume the site is healthy. A joint audit can reveal that the company already has content worth ranking; it simply has not been published in a format the web can understand.

Conclusion: the best SEO opportunity may already be in your product

Formula Dream did not discover a secret social channel or suddenly outspend competitors. Its founder found that the company had built a valuable archive, then unintentionally hidden the archive’s substance behind client-side loading and disconnected files.

That is why a technical SEO audit for JavaScript apps should be a growth priority, not a cleanup task. Before commissioning another batch of blog posts, chasing a launch-platform spike, or spending weeks manually distributing links, inspect whether your most useful product content is present in the pages search engines can actually index.

The case also offers a final caution: an explosion in impressions is a signal to investigate, not a substitute for a business outcome. The winning teams will pair crawlable, useful content with disciplined measurement—following the trail from indexation to relevant queries, clicks, activation, and retained users.

FAQ

What is a technical SEO audit for JavaScript apps?

It is a review of whether search engines can discover, crawl, render, understand, and index the important content in a JavaScript-based website or web app. It covers rendering, page content, status codes, internal links, sitemaps, canonicalization, and post-deployment reliability.

Can Google index JavaScript-rendered content?

Yes, Google can process JavaScript, but JavaScript sites still need to account for separate crawling, rendering, and indexing stages. Important content should not depend on fragile client-side requests, user interaction, or loading behavior that a crawler may not reliably reproduce.

Does adding more URLs to a sitemap improve rankings?

Not by itself. A sitemap helps Google discover important URLs, but pages still need unique, useful, accessible content and a clear reason to rank. Adding low-value or duplicate URLs can create more index-quality problems rather than more organic traffic.

Why did Formula Dream’s impressions rise faster than clicks?

The new crawlable pages likely appeared for a wider range of searches, including many lower-ranked or long-tail queries. That can increase total impressions faster than clicks. The next step is to examine query intent, rankings, CTR, and downstream conversion at the page level.

What should founders test after deploying SEO changes?

Test representative pages for valid HTTP responses, complete rendered text, working data requests, canonical tags, sitemap inclusion, internal links, and functional media or interactive elements. Then use Search Console and analytics to verify crawlability, impressions, clicks, engagement, and conversion over time.