How to tell if a template's code is clean: a real three-template audit

“Clean code” is often used as a sales adjective. A more useful question is: can a buyer understand the structure, change common design decisions safely, and extend the site without fighting hidden dependencies? That requires evidence from the actual files, not a screenshot or a minified file-size claim.

Our audit scope

On 12 July 2026 we performed a read-only inspection of the Cloudflare R2 object inventory and the public preview sources for Orbiq, Lucent and Oasa. We inspected seven primary HTML pages for Orbiq, seven for Lucent and the single Oasa page, plus their linked CSS and JavaScript. We counted headings, landmarks, IDs, image alternatives, inline style attributes, CSS custom properties and a few risky JavaScript patterns. We also submitted each homepage URL to the W3C Nu HTML Checker.

What clean means in practice

• •Structure: headings and landmarks describe the document instead of merely producing a visual size.
• •Change surface: recurring colors, spacing and typography have predictable tokens or central rules.
• •Behavior: interactions use understandable event handling and avoid unnecessary dynamic HTML injection.
• •Accessibility: controls have names, forms have labels, images have intentional alternatives and keyboard use is testable.
• •Portability: the template documents external fonts, images, APIs and any hosting assumptions.
• •Consistency: the same navigation, footer, naming conventions and component rules survive across pages.

Template Market example

Orbiq

The inspected Orbiq source contained seven primary HTML pages, a dedicated tokens.css file, a shared stylesheet and a shared JavaScript file.

• ✓Each of the seven inspected pages had one H1 plus header, main and footer landmarks; no duplicate IDs were found.
• ✓Every inspected image had an alt attribute. The homepage used 32 empty alt values among 42 images, which requires a manual decorative-versus-informative review rather than an automatic pass or fail.
• ✓The tokens file defined 61 CSS custom-property declarations. The 4.8 KB JavaScript file contained event listeners but no eval call or innerHTML assignment in our static scan.
• ✓The W3C homepage check reported one heading-level error and three warnings.

Inspect the Orbiq preview

Template Market example

Lucent

The inspected Lucent source also separated design tokens, shared styles and behavior across a multipage architecture site.

• ✓Each of the seven inspected primary pages had one H1 plus header, nav, main and footer landmarks; no duplicate IDs or missing image alt attributes were found.
• ✓The tokens file defined 53 CSS custom-property declarations. The 4.0 KB JavaScript file contained no eval call or innerHTML assignment in our static scan.
• ✓The homepage used 34 inline style attributes, largely for reveal timing and local presentation values. That is maintainable only if the convention is documented and used consistently.
• ✓The W3C homepage check reported two heading-level errors.

Inspect the Lucent preview

Template Market example

Oasa

Oasa used a compact one-page source set: index.html, one shared stylesheet and one shared JavaScript file in the R2 inventory.

• ✓The page had one H1, header, nav and footer, with no duplicate IDs and no missing image alt attributes.
• ✓The page did not use a main landmark and contained 46 inline style attributes. Most visible examples controlled reveal timing or local spacing, but moving recurring presentation into classes would reduce the editing surface.
• ✓The 10.8 KB stylesheet contained 15 CSS custom-property declarations. The 2.1 KB JavaScript file contained no eval call or innerHTML assignment in our static scan.
• ✓The W3C homepage check reported one heading-level error.

Inspect the Oasa preview

How to read the findings without turning them into a score

A larger token set is not automatically cleaner, and a smaller JavaScript file is not automatically safer. Orbiq and Lucent expose more centralized design decisions because they support more pages and components. Oasa has less code to navigate, but more presentation is attached directly to elements. The right judgment depends on what you plan to change and whether the conventions remain predictable.

The W3C results are similarly specific. A skipped heading level is worth fixing because headings help people understand relationships between sections. It is not evidence that the entire template is broken. Google also cautions against treating perfect semantic validity as a prerequisite for Search; the stronger reason to fix the outline is accessibility and maintainability.

An illustrative semantic pattern

<header>
  <nav aria-label="Primary">...</nav>
</header>
<main id="main-content">
  <section aria-labelledby="hero-title">
    <p class="eyebrow">Architecture studio</p>
    <h1 id="hero-title">Spaces designed around the way you live</h1>
    <p>Selected residential and hospitality projects.</p>
    <a href="projects.html">View projects</a>
  </section>
</main>
<footer>...</footer>

A ten-minute pre-purchase inspection

• •Open view-source, not only the Elements panel, and check whether the meaningful page copy is present in the delivered HTML.
• •Look for one descriptive page title and a heading outline that represents sections rather than font sizes.
• •Check for header, navigation, main content and footer landmarks; repeated nav regions should have distinguishable labels.
• •Inspect several images. Empty alt is correct for decoration, but informative images need alternatives that communicate purpose.
• •Open the shared stylesheet and search for recurring color and spacing values. Tokens are helpful when they reduce duplication rather than add another abstraction layer.
• •Open the JavaScript and identify every external library, network request and content-injection path. Ask why each is necessary.
• •Resize the preview, use the keyboard, open and close menus, submit validation errors and check the browser console.
• •Follow several internal links and confirm that the files use a consistent relative-path convention.
• •Run the homepage and at least one detail page through an HTML checker, then interpret each message in context.
• •Ask for the actual source package and license terms before purchase; a live preview alone cannot prove what the buyer receives.

Red flags that need a closer look

• •The preview works only after a large undocumented build process or requires an account that is not included.
• •Navigation is made from clickable div elements without link or button semantics.
• •The same ID appears more than once, form controls have no programmatic labels, or keyboard focus disappears.
• •Large blocks of content are constructed with innerHTML from untrusted values or the code uses eval without a defensible reason.
• •Design values are scattered across hundreds of one-off inline declarations with no naming convention.
• •Removing one widget or analytics script breaks unrelated layout or interaction code.
• •The vendor calls the code clean but will not provide an inspectable preview, source tree or documented dependency list.

Code cleanliness is only one purchasing dimension. Use the technical performance guide for a separate measurement plan, the light versus heavy customization guide to estimate change scope, and the template evaluation checklist for the full decision.

Our verdict on the three inspected sources

All three sources were understandable enough to audit directly and avoided several obvious static-code hazards in the inspected files. Orbiq and Lucent offered the clearer multipage token structure. Oasa offered the smallest source surface but would benefit from a main landmark and less repeated inline presentation. Each homepage had a heading-outline issue reported by the checker, so none should be presented as a perfect reference implementation. That is a more useful conclusion than a single clean or dirty badge.