How to Evaluate a Website Template Before You Buy: 10 Checks

Judge a template on the things you cannot fix after buying: accessibility, mobile performance, page coverage, and whether it is still maintained. Colours, copy and spacing are an afternoon's work. A design that fails contrast on every button, or ships four of the nine pages the demo implies, is a rebuild.

Ten checks follow, in the order that eliminates candidates fastest. Most take under two minutes on the live demo, and the first three will disqualify more templates than the other seven combined.

1. Run Lighthouse on the demo yourself — on mobile

Every template that advertises a score advertises the desktop one. Desktop is the easy exam: no CPU throttle, no slow network, and a marketing page with a hero image will score 100 on a laptop almost regardless of how it is built.

Lighthouse's default preset simulates a 4× CPU throttle on slow 4G, and that is where templates separate. For calibration, here is our own site measured both ways across eight pages:

The honest reading of that table is the part vendors leave out: desktop 100 is not an achievement, it is a baseline, and a ten-point mobile spread on our own pages is normal for anything with real interactivity. What you are looking for is not a perfect mobile number. It is whether the gap has an explanation. Ours is React hydration — verified by blocking every image and prefetch on the home page, which moved LCP by 46 ms, from 3786 to 3740. The bytes were not the problem; the framework floor was.

A template whose mobile performance sits in the 50s has a different problem, usually an unoptimised hero image or a chart library on the critical path. Ask which.

2. Check accessibility on the inner pages, not the home page

This is the check that most reliably finds real defects, because home pages get the attention and everything added later does not.

Our own audit is the example. After a pass that took three pages to accessibility 100, we measured the pages added afterwards and found three genuine defects: the blog index had no <h1> at all, the docs page skipped from h1 straight to h3, and a tag component missed AA contrast by 0.01. None of those was visible. All three failed an automated audit instantly.

So: open the demo's blog, its docs, its pricing table, its dashboard sub-pages — and run the audit there. Then tab through one page with the keyboard. If you cannot reach the mobile menu, or focus disappears inside a modal, that is not a styling fix.

3. Count the pages that actually exist

A screenshot gallery showing eight screens does not mean eight routes exist. This is the single most common gap between what a listing implies and what the zip contains.

Click every link in the demo's navigation and footer. What you are looking for:

• Links to # that go nowhere.
• Nav items that 404 or bounce back to the home page.
• Screenshots in the listing with no corresponding live page.
• One product page that exists, where the listing implied a catalog.

Our own convention on this is a deploy gate that fails on any href="#" anywhere in the codebase, which exists because that is exactly the shortcut everyone takes under deadline. You can run the same check in two minutes with a browser.

4. Read the DOM for a minute

View source on the demo and look for four things:

• One <h1> per page, containing something meaningful.
• Real <img> with dimensions, not background-image divs holding content imagery.
• Structured data if it is a storefront or a blog — Product or BlogPosting JSON-LD.
• Content in the HTML, not assembled by JavaScript after load. Disable JS and reload: if the page is blank, every crawler that does not execute JavaScript sees the same blank page.

That last one matters most for a marketing site, where organic search is the point. A client-rendered landing page can be fixed, but you are buying a rebuild of its data flow.

5. Look at the image weight

Open the network panel, filter to images, reload, and read the total.

The number to hold in your head: a product card image should be around 30 KiB, not 250 KiB. When we audited our own catalog it had grown to 111 products and 892 JPEGs totalling 117 MB, with 2120×1325 covers being served into a 530×330 card. Rebuilding them as sized WebP derivatives took the cover from 255 KiB to 33 KiB and the whole image directory from 117 MB to 93 MB.

Two related things to check while you are there. Are files actually the format their extension claims — we found .png files that were JPEGs wearing the wrong extension. And is the largest image above the fold eagerly loaded? A loading="lazy" on the LCP image is a real, common, invisible bug; ours cost 1.67 seconds of load delay before we caught it.

6. Ask what the update policy is, in writing

"Lifetime updates" means nothing without a versioning discipline behind it. Three concrete questions:

1. Is there a changelog with dates and version numbers? Not a "last updated" badge — an actual list of what changed.
2. Does it follow SemVer, and is the meaning stated? Our rule is that the bump reflects the buyer's adoption cost, not the size of the diff: major for anything that makes merging the update painful (removed pages or props, restructured folders, a framework major), minor for backward-compatible additions, patch for fixes.
3. What happens to your copy when a new version ships? For a source-code template the answer is always "nothing automatically" — you merge it. Which means an honest vendor tells you when an update will hurt.

A template with a two-year-old changelog and a current framework in its listing is claiming something the changelog contradicts.

7. Check the framework and dependency versions

Open package.json if you can see it, or ask. What you want to know is not "is it modern" but "how far behind is it, and in which direction".

A template on the current major of its framework is fine. One major behind is usually fine and sometimes deliberate. Two majors behind means you are inheriting the upgrade, and for a UI-heavy template that upgrade is the expensive kind — the CSS framework's major versions in particular tend to move configuration, not just class names.

Also count the dependencies. A landing page template with forty runtime dependencies has made forty maintenance decisions on your behalf.

8. Read the licence for seats and end-user monetisation

The clause that catches people is not domains. Commercial template licences generally limit developer seats and whether your end users can pay you for what you build with it — not how many sites you deploy.

The practical questions: how many developers may work with the files; may you build something your customers pay to access; may you ship it inside a product you resell; and does it cover every framework edition or just the one you downloaded. Ours grants every edition of a product you own, because the framework is not a lever — but that is a choice, not a standard, so check it rather than assume it.

We wrote the clause-by-clause version separately: what "single site" actually means.

9. Open the zip before you commit to it, if you can

Where a trial or free edition exists, download it and look for the things a demo cannot show you:

• Leftover branding from the vendor's own site or a previous client.
• Lorem ipsum in components rather than only in data files.
• Committed secrets — an .env with real keys, an API token in a config file. This happens more than anyone admits.
• A README that describes this template, not a framework's default one.
• Whether content is separated from markup, or every string is inline in JSX. The second is fine for a five-page site and miserable for fifty.

Our own release pipeline runs a brand scan and a secret scan before packaging and fails closed — the zip is not produced if either finds something. That gate exists because both mistakes are easy, silent, and permanent once shipped.

10. Decide whether it is a starting point or a dependency

The last check is about you, not the template. A source-code template is a starting point: you own the files, you can rewrite anything, and nobody will fix your fork. A component library is a dependency: it updates, and you inherit both the fixes and the breaking changes.

Both are legitimate. Buying one while expecting the other is the actual source of most template regret. If you want a design you can take apart, buy source. If you want something maintained on your behalf, you want a library or a hosted builder, and the honest comparison there is Webflow versus Next.js.

The two-minute version

Frequently asked questions

Is a free template a fair way to judge a paid one? It is the best signal available, if the same team built both. Code style, accessibility discipline and dependency taste all transfer. What does not transfer is page coverage — free editions are usually deliberately narrower — so judge the craft from the free one and the scope from the demo.

How much should I trust the marketplace's rating? Ratings mostly measure whether the buyer got what they expected, which is useful for honesty and nearly useless for quality. Read the two-star reviews specifically: they name the missing pages and the support response time, which are the two things the listing will not.

Should I care that a template is not the newest framework version? Care about the direction of travel, not the number. A template one major behind with a dated changelog entry explaining the plan is in better shape than one on the newest major with no changelog at all. And check the CSS framework's version as carefully as the JavaScript one — its majors tend to move configuration, which is the migration that actually costs a weekend.

What does a template genuinely not save me? Content, integrations and decisions. Copywriting, real imagery, wiring a backend, payments, and the fifty small product judgements that make a site yours. The saving is the four-to-nine weeks of UI work between an installed framework and something presentable — we broke the arithmetic down in template versus building from scratch.

Does buying one edition cover the others? Depends entirely on the vendor, which is why it is on the checklist. Where a product ships React, Next.js, Vue and Angular versions of the same design, the useful question is which folder to start from rather than which to buy — we compared the editions directly.

Templates that pass their own checklist

Every template on this site ships under the same audit gates described above — accessibility 100 on every page, a real changelog with SemVer versions, and a release pipeline that will not package a zip that fails its brand or secret scan.

ASoc Axiom is a dark-theme AI and neural-networks consultancy site with a four-service grid, FAQ and project-based pricing. ASoc Quest is a dark-theme games-storefront marketing page with a featured-title hero, weekly-deals carousel and a rated top-sellers grid. ASoc Compound is an automated-investing site built around a portfolio-value dashboard preview and a three-tier pricing page.

Browse every template, compare the licence tiers on the pricing page, or start with the Next.js landing page templates and the Tailwind landing page templates.