ELENA: Check one thing before anything else, what the crawler gets on its first look. The real-estate platform loads listings via JavaScript after the page arrives, so the initial HTML is nearly empty and the script injects the listings, prices, descriptions in the browser. The content’s genuinely there when a person looks. The question is whether it’s there when the crawler first looks, because rendering JavaScript is a second, deferred pass, not the first thing that happens.
HANNAH: Let me keep that honest in both directions, because “JavaScript means invisible” is too strong and someone will quote it. Search engines do execute JavaScript and can index client-rendered content.
ELENA: I didn’t say invisible, I said deferred and not guaranteed.
HANNAH: Then we agree, I’m just nailing the wording. Rendering happens on a delay and isn’t guaranteed to catch everything, especially content needing interaction, lazy-loading on scroll, or calls that can time out. Client-only rendering adds risk and delay that server-delivered content doesn’t carry. For a listings site where coverage and freshness matter, that risk is the likely culprit. But it’s risk, not a guaranteed blackout.
SOFIA: And it’s diagnosable from outside in about a minute, which makes this concrete instead of theoretical. Look at the raw HTML the crawler first receives, before scripts run, and ask if the listings are in there. If it’s an empty shell and everything appears only after the script executes, that’s the problem in plain sight. The user experience hides it, because by the time a person perceives the page the script has run. The crawler’s first reliable view is that empty shell.
MARCUS: Hold on, before anyone re-architects a rendering pipeline, which is an expensive swing, are we even sure the problem is indexing? The title says “isn’t ranking it.” Indexed-but-not-ranking and not-indexed are different diseases.
ELENA: Fair, those need different fixes.
MARCUS: Completely different. If the raw HTML’s empty and the listings genuinely aren’t in the index, fine, it’s a rendering problem, fix it at delivery. But if they’re indexed and just not ranking, JavaScript is a red herring and the real issue is competitiveness, thin descriptions, or near-identical listings duplicating each other. So step one is confirming whether these pages are indexed at all, because the fix for “not indexed” and “indexed but weak” share nothing.
NOAH: The pattern, if it is the rendering case, is building for the user’s final view and forgetting the machine’s first view. Modern frameworks make you think of the page as the fully-rendered thing a person eventually sees, so the empty initial HTML goes invisible to the team, they never look at it. The tell is “but the content is right there,” true for humans, not reliably true for the crawler’s first pass.
THEO: So the rule, if Marcus’s diagnosis points at rendering, is to get the critical content into the response the crawler first receives. For a listings platform, that’s server-side rendering or pre-rendering, which most modern frameworks support as a built-in mode rather than a rewrite, so the HTML arriving already has the listings, prices, descriptions, with JavaScript enhancing rather than creating the core content. The test is repeatable and free, view-source on the page shows the raw HTML before scripts run, and Search Console’s URL Inspection shows the rendered HTML Google actually built, so comparing the two tells you exactly what the crawler got versus what the user sees.
AIKO: And make that a standing check, Theo, not a one-time migration, because this failure mode regrows. Every new feature or page type raises the same question, is the content in the initial HTML or injected later, and without a check, new client-only pages keep appearing. So raw-HTML verification belongs in how pages ship, plus monitoring whether key page types stay indexed. Otherwise they re-architect once, declare victory, and quietly reintroduce the gap with next quarter’s listing template.
ELENA: So the likely reason it’s not ranking is the crawler’s first reliable view is an empty shell, and the listings hang on a deferred render. Close the gap, core content in the initial HTML, JavaScript enhancing from there. But Marcus is right that we confirm indexing first, because if they’re indexed, re-architecting solves nothing.
DANA: So this lands as a delivery question gated by Marcus’s diagnosis. First, confirm whether these pages are indexed at all, that’s a separate check, an index-status lookup, not the raw HTML, because indexed-but-not-ranking means JavaScript’s a red herring and the cause is content strength or duplication. Then look at the raw HTML the crawler first receives, and if it’s an empty shell and the content genuinely isn’t getting in, we fix it at delivery, render the core listings, prices, descriptions server-side or pre-rendered so they’re present on first load, JavaScript enhancing not creating them. And we make raw-HTML verification a standing check on every new page type, per Aiko, so the gap doesn’t quietly return. The content being visible to users is real, but the crawler’s first view decides indexing, and betting that view on a deferred render is what put this content at risk.
MARCUS: That way we re-architect only if the diagnosis calls for it, instead of rebuilding the rendering for a ranking problem that was never about rendering.
DANA: Content a user can see isn’t the same as content a crawler reliably gets first. Put the listings in the initial response, but confirm that’s the actual problem before you rebuild anything.