The primary indicator of failure was a Google AdSense policy violation: "Valuable Inventory: No Content." This occurred because the vybecoding.ai architecture deferred all content rendering to the browser. While the generateMetadata API correctly populated

The Convex backend was healthy. Verification via npx convex status --url https://modest-lobster-37.convex.cloud confirmed that the getBySlug query was performing at sub-15ms latency. The issue was architectural: the frontend was blocking its own component tree until the browser environment was detected.

Crucially, the React Server Component (RSC) stream did contain the article data. Inspecting the raw network response showed the Next.js streaming data chunks:

4:I["(app-pages-browser)/./app/(main)/news/[slug]/NewsArticle.tsx",["app-main-news-slug-page","static/chunks/app/(main)/news/[slug]/page.js"],""]
5:{"id":"news_article_123","title":"Building a Custom Video Player","content":"
Technical walkthrough...
"}
...
self.__next_f.push([1,"5: ..."])

Next.js was correctly executing the data fetch in the Server Component and streaming it to the client via self.__next_f.push. However, the visible HTML body was suppressed by a provider-level guard.

A common misconception in modern web development is that all crawlers execute JavaScript. While Googlebot's Web Rendering Service (WRS) can process JavaScript, it often defers rendering to a "second pass" that can take days. More importantly, the AdSense Mediapartners-Google crawler and many social media scrapers (OpenGraph) prioritize the initial synchronous HTML snapshot.

If the first response body is a loading skeleton, the crawler perceives an empty page. For ad-relevance scrapers, this results in a failure to categorize the page, triggering "No Content" flags. Our logs showed that the AdSense crawler was strictly parsing the 286-byte skeleton and ignoring the streaming RSC data. The JavaScript required to "bootstrap" the Convex client and render the article content was never executed by these specialized scrapers.

---

The root cause was a standard "isClient" guard in app/ConvexClientProviderSimple.tsx. This pattern is frequently recommended to avoid hydration mismatches, but it is fatal for SSR visibility.

// app/ConvexClientProviderSimple.tsx — THE BUG
const [isClient, setIsClient] = useState(false)
useIsomorphicLayoutEffect(() => { setIsClient(true) }, [])

if (!isClient) return 
Loading...
return {children}

useIsomorphicLayoutEffect (or a standard useEffect) does not execute during server-side rendering. On the server, isClient remains false. The component returns the loading div and terminates the render pass for that branch. Consequently, children — which contains the entire page content — is never rendered in the Node.js environment.

The guard was implemented to prevent a ReferenceError: WebSocket is not defined. The ConvexReactClient constructor defaults to using the global WebSocket object. Since Node.js does not provide a global WebSocket, initializing the client during SSR without protection crashes the process.

Developers often reach for the isClient guard because it is the simplest way to ensure the client-only constructor never runs on the server. However, this fix blocks the entire React context provider, preventing any children from rendering. The correct approach is to allow the provider to render but prevent the client from attempting a network connection on the server.

---

The fix, deployed in commit fdf0c6d11e, removes the isClient guard entirely. We now allow ConvexProviderWithClerk to render children on the server while safely handling the WebSocket dependency.

// app/ConvexClientProvider.tsx — THE FIX
'use client'

import { ConvexReactClient } from 'convex/react'
import { ConvexProviderWithClerk } from 'convex/react-clerk'
import { useAuth } from '@clerk/nextjs'
import { ReactNode, useMemo } from 'react'

export function ConvexClientProvider({ children }: { children: ReactNode }) {
  const convex = useMemo(() => {
    return new ConvexReactClient(process.env.NEXT_PUBLIC_CONVEX_URL!, {
      // Defers WebSocket init in Node.js instead of throwing ReferenceError
      webSocketConstructor: typeof WebSocket !== 'undefined' ? WebSocket : undefined,
    })
  }, [])

  return (
    
      {children}
    
  )
}

By passing webSocketConstructor: undefined in the Node.js environment, we satisfy the ConvexReactClient requirements without a global polyfill. As documented in the Convex client source, passing an undefined constructor instructs the client to enter a dormant "Connecting" state. It will not attempt to open a socket until the browser environment provides a valid constructor. This allows the provider to render its children during SSR without crashing.

Verification for commit fdf0c6d11e:

• May 1 (Before): curl https://vybecoding.ai/ | grep -c 'Loading...' -> 1
• May 2 (After): curl https://vybecoding.ai/ | grep -c 'Loading...' -> 0

While the provider now renders children, we must address the Clerk authentication gap. ConvexProviderWithClerk requires an active auth state to execute authenticated queries. During SSR, Clerk's useAuth() hook does not provide a token to the Convex client. This means that while the component tree now renders, any useQuery hooks requiring authentication will still return undefined on the server. For public content like news and guides, this is solved by using unauthenticated queries in the RSC pass.

---

The provider fix ensures the component tree renders, but useQuery is a client-side hook. On the server, it always returns undefined because there is no WebSocket subscription active. If a component relies solely on useQuery, it will still render a loading skeleton on the server.

To deliver actual text to crawlers, we must fetch data in the Server Component and "hydrate" the Client Component via props.

Before passing content to the client, we ensure security via our ingestion pipeline. article.content is sanitized using DOMPurify (configured for JSDOM in Node.js) before storage in the news table.

// scripts/ingest.ts — internal logic
import DOMPurify from 'dompurify'
import { JSDOM } from 'jsdom'

const window = new JSDOM('').window
const purify = DOMPurify(window)

export const sanitize = (content: string) => purify.sanitize(content, {
  ALLOWED_TAGS: ['p', 'h1', 'h2', 'h3', 'code', 'pre', 'img', 'ul', 'li'],
  ALLOWED_ATTR: ['src', 'alt', 'class', 'href']
})

This ensures that the dangerouslySetInnerHTML call in the frontend is safe. We do not apply secondary sanitization at render time to minimize CPU overhead in the Vercel Edge Runtime.

The ConvexHttpClient is used in the Server Component to perform a stateless HTTPS POST.

// app/(main)/news/[slug]/page.tsx — Server Component
import { ConvexHttpClient } from 'convex/browser'
import { api } from '@/convex/_generated/api'
import NewsArticle from './NewsArticle'

// Module-level client (unauthenticated for public SSR pass)
const convex = new ConvexHttpClient(process.env.NEXT_PUBLIC_CONVEX_URL!)

export default async function NewsPage({ params }: { params: { slug: string } }) {
  const { slug } = await params
  const article = await convex.query(api.news.getBySlug, { slug })
  
  if (!article) return 
404

  return 
}

The Client Component uses a ternary check to bridge the gap between the initial server-side value and the live subscription.

// app/(main)/news/[slug]/NewsArticle.tsx — Client Component
'use client'

import { useQuery } from 'convex/react'
import { api } from '@/convex/_generated/api'
import { Doc } from '@/convex/_generated/dataModel'

export default function NewsArticle({ 
  slug, 
  initialArticle 
}: { 
  slug: string, 
  initialArticle: Doc<'news'> 
}) {
  const liveArticle = useQuery(api.news.getBySlug, { slug })

  // Use live data if available; otherwise fall back to SSR prop
  const article = liveArticle !== undefined ? liveArticle : initialArticle

  if (!article) return 
Article not found

  return (
    

      
{article.title}
      

    
  )
}

We use liveArticle !== undefined rather than the nullish coalescing operator (??). In Convex, undefined signifies the subscription is still loading, while null signifies the record does not exist. Using ?? would cause the component to fall back to the stale initialArticle if the record were deleted from the database (becoming null), which is undesirable. The ternary ensures we only fall back during the "loading" phase.

This pattern is hydration-safe because the first render in the browser will see liveArticle === undefined (as the WebSocket hasn't connected yet). It will resolve to initialArticle, matching the HTML generated by the server. Once the WebSocket connects and the first result arrives, React treats it as a standard state update.

This satisfies React 19's hydration requirements: the server-rendered HTML and the initial client-side render result are identical. We have verified this across /news, /guides, and /apps verticals.

---

The SSR fix was deployed on May 2, 2026. Following the deployment, we submitted a re-evaluation request via the URL Inspection tool in Google Search Console for the affected routes. While AdSense policy re-crawls can span several days, the immediate technical win is the visibility of content in the synchronous HTML body.

The 286-byte skeleton has been replaced by full article content. This ensures that every bot visiting vybecoding.ai now sees the same high-quality technical content our users do. We did not measure LCP in milliseconds as the primary metric for this fix; the success criterion is the binary presence of content in the curl response.

Tested on May 3, 2026, against modest-lobster-37. Verified commit: fdf0c6d11e.