Mobile, Rendering & JavaScript SEO
Google uses mobile-first indexing, meaning the mobile version of your page is used for indexing and ranking. JavaScript-based rendering adds complexity because content must be rendered before Google can evaluate it.
After this lesson you can validate mobile-first indexing readiness, inspect rendered HTML, ensure content parity, choose the right rendering approach, and verify JavaScript link discoverability.
This lesson covers the nine mobile, rendering, and JavaScript SEO areas (leaves 3.6.1–3.6.9): mobile-first indexing readiness, responsive design validation, rendered HTML inspection, content parity checks, client-side rendering review, server-side rendering review, hydration issue detection, lazy-loaded content validation, and JavaScript link discoverability.
Why This Matters
- With mobile-first indexing, the mobile version of your site determines your rankings. If mobile has less content or slower performance, rankings suffer.
- JavaScript frameworks (React, Vue, Angular) create additional rendering complexity. Content that renders only on user interaction may not be visible to search engines.
- Poor JavaScript SEO can make entire sections of your site invisible to search.
Mobile-First Indexing Readiness
Mobile-first indexing means Google primarily uses the mobile version of a page for indexing and ranking. If your site is not mobile-ready, it will underperform in search.
Readiness checklist:
| Requirement | Verification |
|---|---|
| Mobile site is crawlable (no robots.txt blocking) | GSC URL Inspection (mobile crawl) |
| Mobile site has equivalent content to desktop | Content parity check (see 3.6.4) |
| Mobile site loads within reasonable time | GSC CWV report (mobile) |
| Mobile site uses responsive design or dynamic serving | Responsive design validation (see 3.6.2) |
| Mobile site has correct viewport meta tag | <meta name="viewport" content="width=device-width, initial-scale=1"> |
| Mobile site text is readable without zooming | GSC Mobile Usability report |
| Mobile site tap targets are adequately spaced | GSC Mobile Usability report |
How to check mobile-first indexing status:
- GSC URL Inspection: the page shows "Google uses mobile version for indexing" or "Google uses desktop version for indexing."
- If desktop is still used, your mobile version may be incomplete or blocked.
Responsive Design Validation
Responsive design (same HTML, different CSS for different viewports) is Google's recommended configuration.
Responsive design validation:
| Check | Method |
|---|---|
| Viewport meta tag present | <meta name="viewport" content="width=device-width, initial-scale=1"> |
| Content adjusts to viewport | Resize browser, check layout does not overflow or clip |
| Font sizes are readable | Minimum 16px for body text on mobile |
| Touch targets have adequate spacing | Minimum 48x48dp tap targets |
| No horizontal scrolling | Content should fit within viewport width |
| Images scale correctly | Images use max-width: 100% or equivalent |
Validation tools:
- Chrome DevTools device emulation.
- GSC Mobile Usability report (for errors).
- Lighthouse (mobile audit).
Rendered HTML Inspection
Google renders JavaScript before evaluating page content. The rendered HTML (after JS execution) is what Google uses for indexing and ranking.
How to inspect rendered HTML:
- GSC URL Inspection: Click "View Crawled Page" to see the rendered HTML that Googlebot received.
- Chrome DevTools: Use the Inspect tool after the page fully loads to see the rendered DOM.
- Fetch and Render in GSC: See a screenshot of what Googlebot rendered.
What to check in rendered HTML:
| Check | Why It Matters |
|---|---|
| All content text is present in rendered HTML | If content is not in the rendered HTML, it may not be indexed |
| All internal links are present | Links generated by JavaScript must appear in the rendered DOM |
| Meta tags and structured data are rendered | JS-generated meta tags must also appear in the rendered HTML |
| No JavaScript errors in console | Errors can prevent content from rendering |
If content is missing from rendered HTML:
- Check whether the content requires user interaction (click, scroll, hover) to load.
- Consider server-side rendering or static generation for critical content.
- Add the content to the initial HTML rather than injecting it via JavaScript.
Content Parity Checks
Content parity ensures the mobile and desktop versions of a page have the same substantive content.
What to check for parity:
| Element | Mobile | Desktop | Action if Different |
|---|---|---|---|
| Main content text | Same | Same | Must be identical |
| Headings | Same | Same | Must be identical |
| Images | May be different sizes | May be larger | Both versions should have equivalent imagery |
| Videos | May be different player | May be different player | Both should have the same video content |
| Internal links | Same | Same | Must be identical |
| Structured data | Same | Same | Must be identical |
| Meta tags | Same | Same | Must be identical |
Common parity problems:
| Problem | Example | Fix |
|---|---|---|
| Content hidden on mobile | Accordion or tab UI hides important text | Ensure text is accessible (use progressive disclosure, not hidden divs) |
| Content removed on mobile | Desktop has sidebar content that mobile removes | Include the content in a collapsible section or below the fold |
| Images removed on mobile | Desktop has infographic that mobile does not display | Include equivalent image or data |
Parity testing: Compare the rendered HTML from GSC for mobile and desktop user agents. All text content should be present in both.
Client-Side Rendering (CSR) Review
Client-side rendering loads a minimal HTML shell, then uses JavaScript to fetch and render content in the browser. SEO implications are significant.
CSR SEO challenges:
| Challenge | Impact | Mitigation |
|---|---|---|
| Content not available until JS executes | Googlebot may not wait for all JS to execute | Use SSR or SSG for critical content |
| Poor LCP on slow devices | All rendering happens on the client | Optimize bundle size, lazy load |
| Crawl budget consumption | Googlebot must render each page (CPU-intensive) | Use server-side rendering for indexable pages |
| Accessibility dependency on JS | Screen readers and some crawlers may not process JS | Ensure core content is in the initial HTML |
CSR SEO requirements:
- Googlebot must be able to render the page and see all content.
- Page rendering must complete within Googlebot's timeout (typically a few seconds).
- All critical content must be available in the initial HTML payload or rendered before Googlebot timeout.
- Consider using SSR, SSG, or hybrid rendering for indexable pages.
Server-Side Rendering (SSR) Review
Server-side rendering sends fully rendered HTML to the browser, which is then "hydrated" with JavaScript interactivity. SSR is the most SEO-friendly JavaScript rendering approach.
SSR SEO benefits:
| Benefit | Why |
|---|---|
| Content available immediately | HTML includes rendered content, no JS execution needed |
| Fast LCP | Content is in the initial HTML response |
| Crawler-friendly | No rendering dependency — content is visible to any crawler |
| Works without JavaScript | Falls back to static HTML if JS fails |
SSR considerations:
| Consideration | Impact |
|---|---|
| Server load | Server must generate HTML for every request (or use caching) |
| Time to First Byte (TTFB) | SSR can increase TTFB compared to static files |
| Caching complexity | Dynamic SSR responses may require careful caching strategy |
| Framework support | React (Next.js), Vue (Nuxt.js), Angular (Angular Universal) support SSR |
When to use SSR:
- Content-heavy pages that must be indexed (guides, product pages, articles).
- Sites with large amounts of dynamic content that cannot be pre-rendered statically.
- Pages where fast initial load is critical.
Hydration Issue Detection
Hydration is the process of attaching JavaScript event handlers to server-rendered HTML so the page becomes interactive. Hydration issues can cause content or interactivity problems.
Common hydration issues:
| Issue | Symptom | SEO Impact | Fix |
|---|---|---|---|
| Hydration mismatch | Rendered HTML differs between server and client (re-render causes flicker or content loss) | Content may disappear after hydration | Ensure server and client render identical content |
| Slow hydration | Page loads static HTML but takes time to become interactive (poor INP) | Indirect (poor UX, potentially poor engagement metrics) | Optimize JavaScript bundle, lazy hydrate non-critical sections |
| Partial hydration | Some parts of page remain non-interactive | May not affect SEO directly | Implement progressive hydration |
| Hydration failure | JavaScript error prevents interactivity | Content may disappear if re-rendered | Fix the hydration error, add fallback static content |
Hydration testing:
- Load the page with JavaScript disabled → does the content still appear?
- Load the page with a slow network → does hydration complete without error?
- Use Chrome DevTools Performance panel to record hydration time.
- Check console for hydration errors (React/Next.js show explicit hydration mismatch warnings).
Lazy-Loaded Content Validation
Lazy loading defers loading of below-fold content until the user scrolls near it. This improves initial page load but can cause SEO issues if not implemented correctly.
SEO risks of lazy loading:
| Risk | Impact | Mitigation |
|---|---|---|
| Googlebot may not scroll far enough to trigger lazy loading | Content below the fold may never be seen | Use standard loading="lazy" attribute (supported by modern browsers and Googlebot) |
| Googlebot may not trigger intersection observer events | JS-based lazy loading (intersection observers) may not fire | Ensure content is available in the HTML source, or use server-side rendered content |
| Infinite scroll with lazy-loaded items | Googlebot may not scroll infinitely | Implement pagination with crawlable links as fallback |
Lazy loading best practices:
| Practice | Implementation |
|---|---|
| Use native lazy loading | <img loading="lazy"> and <iframe loading="lazy"> |
| Include a fallback for deferred content | For JS-only lazy loading, ensure content is present in HTML source |
| Use progressive loading (skeleton screens) | Show a placeholder that is replaced by the actual content |
| Test with GSC URL Inspection | Verify lazy-loaded content appears in the rendered HTML |
JavaScript Link Discoverability
JavaScript-generated links must be discoverable by search engines. If links exist only in JavaScript, they may not be followed.
JavaScript link patterns and crawlability:
| Pattern | Crawlability | Recommendation |
|---|---|---|
Standard <a href="/url"> in rendered HTML | Crawlable | Best practice |
<a> with onclick but no href | Not crawlable unless href is present | Always include href |
| Programmatic navigation (React Router push) | Depends on rendering | Ensure links appear in rendered DOM |
| Links inside click-to-expand UI | Not crawlable if interaction is required | Add links to the initial rendered HTML or ensure crawler can access |
| Role="button" with JS navigation | Not crawlable | Use <a href> for navigation |
| SVG or canvas-based links | Not crawlable | Use HTML <a> tags |
Testing JS link discoverability:
- Render the page in GSC URL Inspection.
- Search the rendered HTML for your target URLs.
- If an internal link exists in your JavaScript source but not in the rendered HTML, it will not be followed by Google.
- Use Screaming Frog with JavaScript rendering enabled to discover JS-generated links.
Workflow
- Verify mobile-first indexing: Check GSC URL Inspection for indexing mode.
- Check mobile usability: Review GSC Mobile Usability report.
- Inspect rendered HTML: Use GSC URL Inspection to confirm content appears in rendered output.
- Audit content parity: Compare mobile and desktop rendered HTML.
- Review rendering approach: Determine if your site uses CSR, SSR, or SSG.
- Test critical pages: Run GSC URL Inspection on top 20 pages to confirm all content is crawlable.
- Test lazy-loaded content: Verify lazy-loaded below-fold content appears in rendered HTML.
- Audit JS links: Confirm all important internal links appear as
<a href>in rendered HTML.
Common Mistakes
Assuming content looks fine in a browser = it is crawlable: Googlebot may not render JavaScript the same way. Always check rendered HTML.
- Using client-side rendering for all pages: Consider SSR or SSG for content that needs to be indexed. CSR is acceptable for application pages that do not need organic traffic.
- Ignoring mobile usability errors: Mobile usability issues directly affect rankings under mobile-first indexing.
- Not testing lazy loading with Googlebot: Lazy loading works well for users but may hide content from crawlers. Test with GSC URL Inspection.
- Using JS-only links for important navigation: Navigation must be crawlable through HTML
<a>elements.
Checklist
- GSC confirms mobile-first indexing is enabled for the site.
- Mobile Usability report has no errors.
- Rendered HTML (from GSC URL Inspection) shows all content for critical pages.
- Mobile and desktop have equivalent content (content parity).
- Rendering approach (CSR/SSR/SSG) is documented for each page type.
- No hydration errors on critical pages.
- Lazy-loaded content is visible in rendered HTML.
- All important internal links use
<a href>in rendered HTML. - JavaScript errors are resolved for critical pages.