SEO in the Age of JavaScript: Making SPAs Search-Friendly (Athens SEO 2025)

Modern SPAs offer incredible UX—but often break SEO. In this session from Athens SEO 2025, Panos Kondylis shares how to make JavaScript-heavy sites discoverable and indexable by search engines.

What you’ll learn:

Why SPAs hurt SEO by default
- No content in initial HTML
- Broken internal linking via client-side routing
- Delayed rendering = delayed indexing

The cost of getting it wrong
- Lost rankings and visibility
- Soft 404s and wrong canonical URLs
- Disrupted PPC performance

Real-world examples of SEO disasters—and recoveries
- Case studies showing 40%+ ranking loss (and how it was fixed)

How to fix it properly
- SSR, SSG, prerendering, and hybrid rendering explained
- When and how to use each for SEO
- Tips for choosing the right rendering model

Common pitfalls to avoid
- Stale snapshots, bot/user mismatches, re-caching issues

Who it’s for:
- SEOs, developers, performance marketers, and product teams who work with JS-based sites and care about organic growth

Take away practical solutions to ensure your SPAs are both user-friendly and search-friendly.

Transcript

1. SEO in the Age of JavaScript: Making SPAs Search-Friendly PANOS KONDYLIS, Co-Founder, Fussion 24 MAY 2025 speakerdeck.com/pkondylis linkedin.com/in/kondilis/ panosko
2. About Me Panos Kondylis Co-Founder of Fussion 22+ years of experience in DM & SEO Married, father of 🧑👩 Love for 🎶,🏀 & SEO “The Wire” is the best TV ever made
3. About Fussion We Engineer Growth. Not Just Marketing. Fussion is your performance partner, scaling your brand with data, UX, and relentless CRO. Built for Performance-Driven Brands 📢 Born from Digital Growth Veterans 💪 Clients from eCommerce, SaaS, Media & Marketplaces worldwide $24M+ in Ad Spend Managed Across Channels 🚀 Average 80% ROAS Increase in 12 Months
4. What we’ll Discuss Today Why SPAs break SEO How to fix it (properly) Real-world results 01 02 03
5. The Modern Web ≠ SEO-Friendly by Default
6. ⚡ Great for users smooth transitions, fast interactions, app-like feel 🕷 Bad for search engines no HTML content, no real links, no metadata SPAs: Fast UX, Poor Crawlability
7. Why SPAs are SEO nightmare No content in the initial HTML. Googlebot lands on an empty shell — nothing to index What bots see What users see
8. Rendering & Indexing Takes More Time Google doesn’t “see” JavaScript content instantly. The reality of JS SEO: • Crawl: Googlebot sees only the raw HTML • Render: Happens later — when resources allow • Index: JS content joins the index in a second wave “The idea of ‘second wave of indexing’ isn’t a theory. It’s how it works.”
9. Google acknowledges it too “Google processes JavaScript web apps in three main phases: Crawling, Rendering, Indexing.” (Source: Google Search Central – JavaScript SEO Basics)
10. LET’S DIG FURTHER INTO THE ACTUAL PROBLEMS What does this mean for SEO?
11. Metadata loads too late (or never) Meta titles & descriptions are injected via JavaScript after crawl. But reality shows, this might not happen! Yes, a generic non-sense meta title can appear in the Google’s index No easy to rank on “Laptops for Gamers”, right?
12. This is disappointing, right? • Irrelevant or outdated titles in SERPs • No control over how your brand is presented • Lost clicks, even if you’re ranking
13. Canonical Tags are not always respected This is a category url (PLP) but, Google selected a totally different taxonomy (!!). A product page, from a totally different category. This PLP will never get indexed
14. No real internal links Client-side routing = broken crawl paths
15. Discovery of new links is difficult Googlebot will take too much time to discover or revisit our urls
16. Indexation is a disaster • Only ~10% of pages indexed. • The rest? Lost visibility. • "Crawled – not indexed" = thin content or rendering issues
17. PPCs will suffer Imagine user searches for laptops → lands on PDP for a refrigerator 🤦
18. SPAs Often Fail at HTTP Status Codes Many SPAs show a “Not Found” page in the browser, but still return an HTTP 200 status code — which confuses search engines and leads to soft 404s. 🤦 (Proper implementation) (Wrong implementation)
19. REAL WORLD EXAMPLES What does it mean for our KPIs?
20. 40% loss in top 20 rankings new Angular website launched no prerender, no SSR
21. 14% loss in top 20 rankings too big to fail? → things can recover (not fully & it will take months) no prerender, no SSR
22. there are more routes to SEO disasters Are SPAs the only “danger”?
23. JavaScript-Heavy Pages Hurt SEO Large eCommerce site where Product & Category pages relied on client-side JS ✅ 35% growth after moving critical content to initial HTML — no JS used to deliver content. (until You Fix Rendering)
24. what can we do? Available Solutions
25. Rendering Options for SEO Rendering Model Description SEO Friendliness Best Use Case CSR (Client-Side Rendering) Content loads via JavaScript after the initial page load ❌ Weak Web apps prioritizing interactivity SSR (Server-Side Rendering) Content is rendered on the server and sent as full HTML ✅ Strong Dynamic websites needing real-time updates Prerendering Static HTML snapshots generated for bots ✅ Strong SPAs with stable content SSG (Static Site Generation) HTML is built at build time and served instantly ✅ Strong Blogs, docs, marketing sites Hybrid / Edge Rendering Combines SSR, SSG, and edge caching for optimized delivery ✅ Strong Complex apps needing flexibility & speed
26. SSR: Real-Time HTML That Bots Love SSR renders the full HTML on the server before it's sent to the user. Googlebot receives a complete, indexable page — instantly. • HTML generated per request on the server. • Crawlers see everything immediately. • Ideal for dynamic content (i.e, eCommerce, SaaS). • Needs Node.js or similar environment (e.g., Next.js, Nuxt). Generates HTML at request time SSR Server Rendered HTML Request page
27. Server Side Rendering (SSR) ✅ Pros ❌ Cons Content available in initial HTML Slower time to first byte (TTFB) Ideal for dynamic content (e.g., eCommerce) Requires server infrastructure Compatible with metadata & schema More complex dev setup Googlebot sees full content immediately Can strain servers under high traffic
28. Static Site Generation (SSG) With SSG, every page is rendered at build time, producing ultra-fast, crawlable HTML — with near-zero server load. • Pages are rendered during deployment — not on request. • Content is served from CDN (extremely fast). • Ideal for content-heavy or blog-style sites. • Clean source HTML, instant rendering.
29. Static Site Generation (SSG) ✅ Pros ❌ Cons Super fast page loads Rebuilds needed for content updates Fully crawlable HTML Not ideal for real-time data or user auth No server required (CDN friendly) More dev overhead for content-heavy sites Great for blogs, docs, landing pages Can’t personalize easily per user
30. SSG vs SSR — Key Differences Feature SSG (Static Site Generation) SSR (Server-Side Rendering) When HTML is generated At build time (before request) At request time (on demand) Where it's generated Once, during deployment On the server, per request Performance 🔥 Blazing fast (CDN-served static files) ⚡ Fast, but slower TTFB (server computes HTML) SEO friendliness ✅ Excellent (fully rendered HTML) ✅ Excellent (if fast enough) Content freshness 🟡 Needs rebuild for updates ✅ Always up to date Ideal use cases Blogs, docs, marketing sites Dynamic content, user-specific pages, eCommerce Scalability ✅ Highly scalable (served from CDN) 🟡 Scales with infra effort (server load)
31. Hybrid / Edge Rendering Hybrid frameworks allow you to mix SSG, SSR, and edge caching — optimizing both SEO and user experience at scale. • Per-route or per-component rendering control. • SSG for stable pages, SSR for dynamic ones, edge caching for global delivery. • Personalization & SEO in one framework.
32. Hybrid / Edge Rendering ✅ Pros ❌ Cons Best of SSR + SSG + CDN Can increase build & infra complexity Smart caching at edge improves speed Requires modern frameworks (e.g., Next.js, Nuxt) Dynamic rendering without SEO loss DevOps complexity Works great for multi-region delivery Higher technical barrier
33. Prerendering Serves pre-built (cached) HTML snapshots to bots • A bot detection layer identifies Googlebot and sends a static snapshot. • The snapshot is generated in advance (pages are re-cached every X days i.e). • Great for small-to-medium SPAs where content doesn’t change often.
34. Prerendering ✅ Pros ❌ Cons Full HTML delivered to crawlers Not suited for highly dynamic pages Easy to implement with tools (e.g., Rendertron, Prerender.io) May miss real-time content needs Solves indexing delays in SPAs (canonical, metadata etc are within the initial html) Separate rendering path for bots vs users Lightweight on server Can be tricky to scale Cache HITs < 100 ms Cost might be an issue, to re-render often
35. Use SSR whenever possible. It sends fully rendered HTML to search engines and users — perfect for SEO, speed, and personalization. If you're using frameworks like Next.js or Next, enable SSR for all SEO-critical pages. Use prerendering only when: • SSR isn’t feasible yet • You're adding SEO to a legacy SPA • Content is static and user-agnostic Bottom line: SSR scales better for both SEO and user experience.
36. the tools are not enough Potential Pitfalls
37. ▪ Delayed Re-caching = Outdated Content Prerendered pages may become stale if not refreshed frequently — causing Google to index old or incorrect information. ▪ Bots and Users See Different Content If your prerendered snapshot differs from the live user experience, Google may flag the site for cloaking or inconsistency. ▪ Failed Prerenders can harm us If tags like <title>, <meta name="description">, or <link rel="canonical"> are injected late via JavaScript, they may not appear in the snapshot — or be missed by Googlebot. What can go wrong? ▪ Routing or Link State Bugs SPAs using client-side routers may fail to prerender internal navigation paths correctly — breaking crawl paths. ▪ Missed JavaScript Errors If your prerendering tool crashes due to broken scripts or async content, you may silently ship blank or broken HTML pages. ▪ Recaching Limitations Can Hurt SEO If DevOps can’t refresh pages fast enough, titles, descriptions, and product info can go outdated — costing visibility.
38. Having your devs by your side is a great strategy Troubleshooting your SPA configuration is a ongoing job. Anything can break, so beware, to fix it fast & smoothly
39. real world results So what?
40. x2.5 top-20 queries using a custom prerendering solution
41. +50% top 20 keywords using a known prerendering solution
42. Thank you! PANOS KONDYLIS COO & Co-Founder, FUSSION panos@fussion.agency https://fussion.agency LET’S CONNECT @LINKEDIN!