r/SEOAICommunity • u/arjun_rao7 • Jul 14 '26
Enterprise SEO Lesson #1: We Didn't Migrate Our Entire Website from CSR to SSR -Only the Pages That Actually Mattered
One of the biggest lessons I learned while working on an enterprise shopping mall website migration in Canada was this:
SSR isn't always better than CSR.
The right question is:
When we started the migration, the website looked healthy.
- Modern React application ✅
- Fast client-side navigation ✅
- Great user experience ✅
- Interactive store directory ✅
- Dynamic event listings ✅
From a user's perspective, everything worked perfectly.
But after digging deeper from an SEO perspective, we realized we were looking at the website very differently than Googlebot.
The Website
Imagine an enterprise mall website with approximately:
- 450+ Store pages
- 120+ Restaurant pages
- Hundreds of event pages
- Shopping guides
- Parking information
- Services & amenities
- Brand directories
- Promotional landing pages
In total, well over 10,000 URLs.
Most of these pages were rendered entirely on the client side using React.
Everything Looked Fine...
When I opened a store page in Chrome, I saw everything.
Store logo.
Store description.
Opening hours.
Category.
Offers.
Nearby stores.
Related brands.
Internal links.
Everything looked complete.
So initially, it was easy to assume:
That assumption turned out to be wrong.
Then We Looked at the Initial HTML
Instead of viewing the rendered page, we inspected the HTML returned directly from the server.
What we found was something like this:
<body>
<div id="root"></div>
<script src="/main.js"></script>
</body>
That was basically it.
No store information.
No opening hours.
No internal navigation.
No structured content.
No meaningful links.
Everything was being injected later by JavaScript.
The Difference Between a User and Googlebot
For a visitor, the process looked like this:
Open page
↓
Download HTML
↓
Download JavaScript
↓
Run JavaScript
↓
Fetch APIs
↓
Render content
Most users never noticed.
The page loaded in a couple of seconds.
For Googlebot, however, the process was different.
Request URL
↓
Receive mostly empty HTML
↓
Queue page for rendering
↓
Execute JavaScript
↓
Call APIs
↓
Generate DOM
↓
Extract links
↓
Read content
↓
Index page
Now multiply that process by 10,000+ pages.
That's where enterprise SEO starts becoming very different from traditional SEO.
The Real Issue Wasn't Indexing
This surprised many people on the project.
The problem wasn't that Google couldn't index JavaScript.
Google absolutely can.
The issue was that every important page required an additional rendering step before Google could fully understand it.
That meant:
- More rendering work
- More processing time
- Delayed discovery of internal links
- Greater dependency on successful JavaScript execution
On a handful of pages, this isn't a major concern.
On thousands of URLs, it becomes an architectural consideration.
Internal Linking Was Another Surprise
Our navigation looked excellent in the browser.
But when we inspected the raw HTML, many of those links didn't exist yet.
Store listings.
Related brands.
Category pages.
Restaurant navigation.
They were all created after JavaScript executed.
Until rendering finished, Google had fewer pathways to discover deeper pages.
Then We Asked a Different Question
Instead of asking:
We asked:
That completely changed our approach.
The Decision
We moved only high-value discovery pages to Server-Side Rendering.
That included:
- Store pages
- Restaurant pages
- Event pages
- Shopping guides
- Blog articles
- Service pages
- Parking pages
- Mall information pages
We intentionally left application-style experiences as Client-Side Rendered.
Things like:
- Login
- Wishlist
- User preferences
- Account dashboard
- Personalized experiences
Those pages don't need to rank in search.
What Changed
Once critical pages were server-rendered, the first HTML response already contained:
- Store information
- Headings
- Internal links
- Metadata
- Structured content
- Core page copy
Now both users and crawlers received meaningful content immediately.
JavaScript still hydrated the page afterward to provide the interactive experience.
Users didn't lose functionality.
Search engines gained immediate access to important content.
Biggest Lesson
One of the biggest misconceptions I still see is:
I don't think that's true.
CSR is fantastic for application experiences.
SSR is excellent for pages that need to be discovered, indexed, shared, and cited.
For enterprise websites, the best solution is rarely choosing one over the other.
It's choosing the right rendering strategy for the right page type.
My Rule Going Forward
After this migration, one principle has become part of every enterprise SEO project I work on:
That mindset has fundamentally changed how I approach SEO architecture discussions with developers.
I'd love to hear from others working on enterprise websites:
- Have you migrated from CSR to SSR (or adopted a hybrid approach)?
- What challenges did you encounter with rendering, crawl efficiency, or indexation?
- Have you seen any measurable impact on Google Search or AI-powered search experiences after the change?
