Disclosure: I build MyAIRap.video, a photo-to-Rap tool. This is a development case study from that project, written with AI assistance and checked against our local release records. It is not a claim that server rendering alone produces rankings.
The first useful SEO question for a React product is surprisingly practical: what does a reader get before JavaScript runs?
Our redesigned interface looked complete in a browser. It had examples, pricing and a clear path to the creator. A raw HTML check told a different story: the initial response was a small shell. The words people could see after rendering were missing from the first response.
For an AI rap video generator, that is a product problem as much as a search problem. A visitor needs to understand the input, the resulting video and the purchase model before signing in. We reused the same React marketing components for pre-rendered public HTML. The homepage, pricing, tutorial and articles now have meaningful headings, paragraphs and links in the first response. Their client-side counterparts use the same route metadata rather than inventing a second title after navigation.
The account and checkout are different. We did not turn private balances or orders into indexable pages. Public explanation and authenticated actions share a design, but they do not share an indexing policy.
This distinction is easy to lose when every URL looks like “just another React route.”
For a public route, we check: A response-size threshold helped detect the old empty shell, but size alone is not the goal. A large response with duplicated filler would still be a bad page. We check for actual useful content and correct links.
Our creator has Mini and Standard, two durations and two resolutions. Existing showcase videos were made with Standard. A marketing page that implies the least expensive option always matches the showcase would create the wrong expectation, however well it rendered.
The same applies to a template button. Today it records interest in an unreleased format; it should not look like a working purchase for exact recreation.
That is why we keep pricing, availability and model caveats in the same acceptance review as headings and metadata. The page is an explanation of the application, not a separate brochure allowed to drift away from it.
Raw HTML and browser checks can show that content is available. They cannot show that Google has indexed the latest version, that a keyword will rank, or that an AI assistant will cite it. Those need separate observation windows and real search or referral evidence.
If you are building a similar tool, inspect the response before writing another SEO article. Then check a client-side navigation into pricing and back. The second step catches metadata regressions that a single homepage request misses. The MyAIRap tutorial shows the actual photo, lyric and video workflow behind this case. The main lesson is portable: make the public explanation readable, and keep the private transaction private.