Built on web fundamentals

Root.js renders every page to complete HTML, either on the server when it is requested or ahead of time as static files. Search engine crawlers, social media previews, and AI assistants that read web pages all receive the full text and links right away, with nothing to run first.

That matters because many crawlers, including many AI crawlers, do not run JavaScript. On sites that build their pages in the browser, those crawlers can see an empty page. On a Root.js site, what visitors read is what crawlers read.

Root.js sends no JavaScript to the browser unless a page needs it. When a page does need interactivity, like a carousel or a signup form, only the code for that piece is loaded, and only on the pages that use it. Page speed depends less on how large the site grows.

• Each page loads only the styles and scripts it uses.

• Files are minified and named by their content, so browsers and CDNs can cache them safely.

• Responses are compressed before they are sent.

• Published CMS pages can be cached by a CDN for a few seconds, so traffic spikes are served quickly and new content still appears within a minute.

Images are often the largest part of a page. The CMS records the size of every uploaded image, so pages can reserve space for it and avoid content jumping around as it loads. With the image service turned on, developers can also serve each image at the size and format that each screen needs.

Editors manage page titles, descriptions, and social sharing images in the CMS, alongside the content itself. Developers decide how those fields appear in each page’s HTML, so every template follows your SEO guidelines.

• Clear URLs: every page and every language gets its own address.

• Sitemap: developers can turn on a sitemap that lists every page and tells search engines about its translated versions.

• Redirects: moved pages can redirect permanently, so links and rankings carry over.

• One URL per page: URLs can be normalized with or without a trailing slash, so search engines do not see duplicates.

• Real error pages: missing pages return a proper “not found” status, so they drop out of search results instead of being indexed.

Structured data is a short, machine-readable summary of what a page is, written in the standard schema.org vocabulary. It tells search engines and AI tools that a page is an article with an author and a publish date, a product with a price and availability, an event with a date and a location, or where the page sits in the site’s navigation.

Search engines use it to show rich results, such as product details, event dates, and breadcrumbs, right in the search listing. AI assistants can use it to understand and describe a page accurately, instead of inferring everything from the layout.

Developers add structured data to page templates as JSON-LD, the format Google recommends, in each page’s HTML. Because Root.js renders pages on the server, it is part of the HTML every crawler receives. The values usually come from fields editors already fill in, like the title, publish date, author, and images, so the structured data stays in sync with the page without extra work for editors.

To check it, Google’s Rich Results Test shows which rich results a page is eligible for. Developers can also add a publishing check that flags missing details, such as an article without an author, before the page goes live.

Accessibility starts with the HTML itself. Root.js templates are plain HTML components with no hidden framework markup, so developers have full control over headings, landmarks, and labels, and accessibility reviews look at the same HTML that visitors get.

In the CMS, every image upload has an alt text field for describing the image to people who use screen readers. When AI is turned on, Root AI can write a first draft of the alt text for an editor to review.

Developers can add publishing checks that turn your standards into a step in the publishing flow: a missing meta description, an image without alt text, a broken link, or a title that is too long for search results. Each check can block publishing or show a warning, and results are shown to the editor before the page goes live.

Checks are a guardrail rather than a hard lock: Admins can publish anyway when needed, and the decision is recorded. See Publishing, scheduling, and releases.

Every response from a Root.js server includes the standard security headers browsers look for: requiring secure HTTPS connections, stopping other sites from framing your pages, and preventing browsers from guessing file types. A Content Security Policy is included too. It starts in report-only mode, so developers can see what it would block before they enforce it.

Lighthouse, built into Chrome, scores any page for performance, accessibility, best practices, and SEO, and explains what to fix. It is the quickest way to see how a page is doing.

Root.js takes care of the foundations, but the final score also depends on choices each site makes: the size and format of images, web fonts, color contrast, and third-party scripts like analytics and tag managers. We recommend running Lighthouse on your main page templates, on mobile, before launch and after major changes.