The Massive Iceberg of Infrastructure Hiding Beneath zero-config SEO

You hit deploy on Rocket. Your site goes live. You run a Lighthouse audit and score 95+ across the board. You didn't configure anything. You didn't install a plugin. You didn't read a doc about meta tags.

That's the surface. Here's the iceberg underneath.

Every build that leaves rocket.new carries over a hundred discrete SEO, accessibility, compliance, and performance decisions, all made automatically, all invisible to you. This post is the full manifest. Every tag. Every attribute. Every optimization. No hand-waving.

It's Live. Here's the Full Toolkit.

Everything described in this post is shipping today. The full SEO and discoverability toolkit is documented at docs.rocket.new/build/polish/seo, where you can see every feature, command, and optimization available in the platform.

Beyond the automatic defaults, you can ask Rocket directly in chat to add optimized meta tags, JSON-LD structured data, sitemaps, robots.txt files, and internal linking. Two slash commands, /Generate SEO Report and /Improve SEO, let you audit and auto-fix SEO issues across your codebase without leaving the editor.

There's also a dedicated GEO (Generative Engine Optimization) layer for AI search engines like Perplexity, ChatGPT, and Claude. /Generate GEO And AEO Report audits your AI search readiness; /Improve GEO And AEO restructures content for higher citation rates in AI-generated answers.

Now, here's what all of that actually does under the hood.

The Full Manifest: What "By Default" Actually Means

The phrase "SEO-ready by default" is doing a lot of work. Here's what it unpacks to, organized by the four compliance layers every build passes through.

Layer 1: Semantic HTML Structure

The foundation. Search engines parse structure before content. A div soup site and a semantically correct site can have identical text and rank differently. Every rocket.new build enforces:

The heading hierarchy rule is strict. If your content jumps from h2 to h4, the build pipeline inserts the missing level or warns during generation. A broken heading tree is one of the most common SEO mistakes on the web, and we eliminate it at build time.

Layer 2: Meta Tags & Structured Data

Every page gets a complete meta tag set. Not a partial one. Not a "we set the basics and you fill in the rest" one. Complete.

Standard meta tags:

• <meta charset="utf-8"> for character encoding
• <meta name="viewport" content="width=device-width, initial-scale=1"> for responsive viewport
• <meta name="robots" content="index, follow"> as crawl directive (configurable per page)
• <link rel="canonical" href="..."> for canonical URL, auto-generated from route
• <meta name="description"> for page description, derived from content if not explicitly set
• <meta name="theme-color"> matching the site's primary brand color

Open Graph tags (Facebook, LinkedIn, iMessage previews):

• og:title, og:description, og:image, og:url, og:type, og:site_name, og:locale

Twitter Card tags:

• twitter:card, twitter:title, twitter:description, twitter:image, twitter:site

JSON-LD Structured Data:

Every page embeds a JSON-LD block appropriate to its content type. A blog post gets Article schema. A product page gets Product schema. A landing page gets WebPage with Organization.

Copy

1<script type="application/ld+json"> 2 { 3 "@context": "https://schema.org", 4 "@type": "Article", 5 "headline": "When We Say 'SEO-Ready by Default'...", 6 "author": { 7 "@type": "Organization", 8 "name": "rocket.new Engineering" 9 }, 10 "datePublished": "2026-04-07", 11 "image": "/blog/seo-ready-by-default/hero.png", 12 "publisher": { 13 "@type": "Organization", 14 "name": "rocket.new" 15 } 16 } 17</script>

This isn't a static template pasted into every page. The structured data is generated from each page's actual content (title, dates, images, author) at build time. When search engines parse it, it's accurate.

Additional link tags:

• <link rel="sitemap" href="/sitemap.xml"> for the auto-generated sitemap
• <link rel="icon"> and <link rel="apple-touch-icon"> for the favicon set
• <link rel="manifest"> for PWA manifest when applicable

Layer 3: Accessibility, WCAG 2.1 AA Compliance

Accessibility isn't a checkbox. It's a legal requirement in many jurisdictions, and it directly impacts SEO because search engines increasingly factor accessibility signals into ranking. Here's what ships:

Image accessibility:

• Every <img> gets an alt attribute. If the user provides one, it's used. If not, the build pipeline generates a descriptive fallback and flags it for review.
• Decorative images get alt="" and role="presentation" to be correctly ignored by screen readers.

ARIA attributes:

• aria-label on navigation, search, and interactive elements
• aria-current="page" on the active nav link
• aria-expanded and aria-controls on collapsible sections
• aria-live regions for dynamic content updates
• role="banner", role="contentinfo", role="navigation", role="main" on landmark elements

Keyboard navigation:

• Skip-to-content link as the first focusable element
• Logical tab order following visual layout
• Focus indicators on all interactive elements (no outline: none without a visible replacement)
• Escape key closes modals, dropdowns, and overlays

Color and contrast:

• Text meets WCAG AA minimum contrast ratio (4.5:1 for normal text, 3:1 for large text)
• Interactive elements have distinct focus and hover states
• Information is never conveyed by color alone

Form accessibility:

• Every input has an associated <label> with matching for/id
• Error messages are linked to inputs via aria-describedby
• Required fields are marked with aria-required="true"

Layer 4: Privacy and GDPR Patterns

Sites that serve EU users need GDPR compliance. Rather than leaving this as an afterthought or a third-party plugin, rocket.new builds generate the consent infrastructure:

• Cookie consent banner rendered on first visit, blocks non-essential scripts until consent is given
• Granular consent categories covering analytics, marketing, functional, necessary
• Consent persistence stored locally, no tracking before consent
• Privacy policy link auto-included in footer and consent banner
• Data handling patterns where forms include consent checkboxes where required, with clear language about data usage

Performance by Default: Core Web Vitals Without the Effort

Google's Core Web Vitals are the performance metrics that directly affect search ranking. There are three, and every rocket.new build is tuned for all of them.

Image Handling in Detail

Images are the single largest contributor to slow pages. Here's the pipeline every image passes through at build time:

1. Format conversion where source images are converted to WebP (broad support) and AVIF (best compression) with the original format as fallback
2. Responsive variants where each image is generated at multiple widths (640, 768, 1024, 1280, 1536px) and served via srcset
3. Dimension extraction where width and height are read from the source and written to the HTML, preventing cumulative layout shift
4. Lazy-loading classification where the build determines which images are above the fold (based on component position in the layout tree) and only lazy-loads the rest
5. Priority hints where the hero/LCP image gets fetchpriority="high" to tell the browser it's critical

Copy

1<picture> 2 <source 3 type="image/avif" 4 srcset=" 5 /img/hero-640.avif 640w, 6 /img/hero-1024.avif 1024w, 7 /img/hero-1536.avif 1536w 8 " 9 sizes="(max-width: 768px) 100vw, 50vw" 10 /> 11 <source 12 type="image/webp" 13 srcset=" 14 /img/hero-640.webp 640w, 15 /img/hero-1024.webp 1024w, 16 /img/hero-1536.webp 1536w 17 " 18 sizes="(max-width: 768px) 100vw, 50vw" 19 /> 20 <img 21 src="/img/hero-1024.jpg" 22 alt="Dashboard showing real-time analytics" 23 width="1536" 24 height="864" 25 fetchpriority="high" 26 decoding="async" 27 /> 28</picture>

You write <img src="hero.jpg" />. The build outputs the full <picture> element above. No configuration.

The Invisible Compliance Layer: How It Works

The key design constraint was invisibility. The user should never have to think about SEO, accessibility, or compliance. They write content; the build handles the rest.

Here's how the pipeline works:

Three design decisions make this work:

1. Build-Time Injection, Not Runtime

Every optimization happens at build time. There's no client-side JavaScript patching meta tags after the page loads. There's no runtime accessibility polyfill. The HTML that arrives at the browser is already correct, complete, and optimized.

This matters because search engine crawlers don't always execute JavaScript. A runtime-injected meta tag might never get indexed. Build-time injection guarantees the crawler sees exactly what the user sees.

2. Validation With Fallbacks

The build pipeline validates content against compliance rules, but it doesn't fail the build on every violation. Instead, it follows a hierarchy:

1. Auto-fix what's safe like missing lang attribute, absent viewport meta, image dimensions not specified
2. Generate and flag so missing alt text gets a generated placeholder with a build warning
3. Warn loudly on broken heading hierarchy, contrast violations, missing form labels
4. Block on critical such as missing canonical URL on duplicate pages, no robots directive

The philosophy: ship a compliant site, but tell the developer what needs human attention.

3. Content-Aware Defaults

The system doesn't apply a static template. It analyzes the actual content:

• A page with a publication date gets Article schema; one without gets WebPage
• A page with product information gets Product schema with price and availability
• A page with a contact form gets ContactPage type
• Navigation depth determines breadcrumb structured data generation
• The primary heading becomes the og:title if no explicit one is set

Before and After: What the Audits Show

Here's what a typical Lighthouse audit looks like for a rocket.new build compared to an unconfigured equivalent:

Lighthouse Scores

Core Web Vitals

The performance gains come primarily from image optimization (LCP), script deferral (INP), and explicit image dimensions (CLS). The SEO gains come from complete meta coverage and structured data. The accessibility gains come from semantic HTML and ARIA attributes.

The "Boring" Infrastructure That Matters

None of this is glamorous. There's no AI here. No breakthrough algorithm. It's a hundred small, well-known best practices executed consistently on every single build.

That's the point.

The difference between a demo and a product isn't the feature that makes the demo impressive. It's the infrastructure that makes the product reliable. SEO-ready structure, accessibility compliance, privacy patterns, performance optimization: these are the things users never see and never ask for, but they notice immediately when they're missing.

A Lighthouse score of 40 feels like a broken site. A Lighthouse score of 98 feels like a professional one. The user doesn't know why. They just know.

We built rocket.new so that every site that ships from it passes the bar. Not because the developer configured it. Not because they installed the right plugins. Because the platform decided this was the default, and the default should be production-grade.

When we say "SEO-ready by default," we mean all of it. Every tag. Every attribute. Every optimization. Shipped automatically. Invisible by design.

This is live now. Explore the full documentation and try /Generate SEO Report in your next build.