Frequently Asked Questions

Server-side rendering means your React components are executed on a server and converted to HTML before reaching the browser. Unlike client-side React that requires JavaScript to display content, SSR delivers fully-rendered HTML that search engines can immediately crawl and index - just like traditional WordPress content.

Yes. WP Render Blocks supports both SSR and CSR. CSR is great for logged-in areas, dashboards, internal tools, and pages where SEO isn’t required.

Compared to SSR, CSR generally has lower SEO value because the initial HTML is minimal and the content is generated in the browser. If you care about indexable HTML in page source, choose a plan that includes SSR.

Choose a plan that includes SSR (Indie, Pro, or Agency). SSR delivers crawlable HTML in your page source, which is what search engines and SEO plugins expect.

Traditional methods (iframes, client-side React) require JavaScript to render content, causing SEO problems: search engines may see empty divs, Core Web Vitals suffer, and content may not be indexed. WP Render Blocks renders your components server-side as static HTML that lives directly in your WordPress page source - fully crawlable, fast-loading, and SEO-safe.

No. WP Render Blocks works with your existing WordPress installation. Install our WordPress plugin (2 minutes), connect your site with an API key, and start adding server-rendered React components to any page or post. No theme changes, no database migrations, no downtime.

Yes. Since components render as static HTML in your page source, they are compatible with every WordPress SEO plugin including Yoast, Rank Math, All in One SEO, and SEOPress. The plugins analyze your rendered HTML just like any other WordPress content.

Absolutely. WP Render Blocks is designed specifically for AI-generated components. Export your component from Lovable, V0, Cursor, Claude Artifacts, or any React tool as a ZIP file, upload it to our dashboard, and we handle bundling, rendering, and WordPress integration automatically.

Each component is identified by the name in your package.json. Projects exported from v0 or similar tools often use the same default name for different projects. If you're uploading the same component with changes, upload a new version from that component's page (Upload new version). If it's a different component, change the "name" in package.json to something unique (e.g. my-component-2) and upload again.

WP Render Blocks is designed to be fast and SEO-friendly. The WordPress plugin can cache rendered HTML (so repeat page views don’t re-render every time), and components can be hydrated for interactivity. As with any React UI, very heavy components or large props payloads can still impact performance.

Every upload creates a new version. One version can be marked as “active”. In WordPress you can either pin a specific version (for stability) or follow the active version (to automatically get the latest active release). You can switch active versions at any time to roll forward or back.

Yes. You can activate a previous version in the dashboard. If your WordPress blocks are set to use the active version, they’ll render the rollback immediately; if they’re pinned, update the pinned version in WordPress.

WP Render Blocks provides a native Gutenberg block. If your page builder supports Gutenberg blocks, you can typically use it. Dedicated widgets/integrations for specific builders depend on your stack and are not required for Gutenberg-based workflows.

For security, WP Render Blocks validates production dependencies during upload. Unknown packages may require admin approval (optionally AI-assisted), and packages that enable server-side access (filesystem, shell execution, network requests, etc.) can be blocked. This protects the rendering environment from unsafe code.

Standard functional React components and props work well. The key SSR rule is: don’t access browser-only APIs during render (like window/document) unless you guard them. Interactivity comes from hydration via the client bundle after the page loads.

No. API keys should be sent via headers (e.g. X-API-Key or Authorization Bearer). URLs can be logged by servers and analytics tooling, so keys in query parameters are easier to leak.