Website Technology Checker and CMS Detector

Last updated: What’s new

Find public clues about what a website is built with, including its CMS or website platform, frameworks, analytics, hosting, CDN, fonts and ecommerce tools. Review evidence and confidence, then export a CSV or JSON stack inventory with verification steps.

No signup required. Technical scan results may be used to produce aggregate website statistics. Research records do not include your name, email, IP address, or analytics ID. Privacy details

Enter a website to detect its technology stack:

Not sure what to expect?

Site blocked or built with JavaScript?

How the Website Technology Checker Works

This tool analyzes publicly visible code and server responses to help identify what a website is built with. It works as a CMS, website platform, and tech stack checker, but it cannot inspect private backend code. Here's the process:

  1. Enter a URL, type or paste any website address. The tool adds https:// if no protocol is specified.
  2. Fetch and analyze, the checker follows safe public redirects, then reads the final response headers and scans up to 2 MB of returned HTML. It does not render the page or run JavaScript.
  3. Match public evidence, it checks specific asset URLs, meta generator tags, source attributes and inline markers, cookie names, and relevant header values. It inspects referenced URLs and reads the opening of up to three of the site's own CSS or JavaScript files for version banners.
  4. Review qualified results, matches are grouped by category with confidence and visible evidence. Any version shown came from a technology-specific public string and still needs verification.
  5. Export a working inventory, copy or download CSV or JSON with evidence, version provenance, uncertainty and verification steps. Confirm the findings with the site owner before migration or maintenance decisions.

Why Knowing a Website's Tech Stack Matters

Understanding what technologies a website uses gives you actionable intelligence for several scenarios:

  • Competitor research, see what CMS, frameworks, and analytics your competitors use. If a high-ranking competitor uses a specific setup, understanding their stack helps you evaluate your own technical decisions.
  • Sales and prospecting, agencies and SaaS companies use technology detection to find potential clients. If you offer WordPress services, knowing which sites run WordPress (and which plugins they use) helps you target the right prospects.
  • Security review preparation, exposed version and server clues can help scope a proper authenticated audit. A public technology scan does not determine whether a site is patched or vulnerable.
  • Migration planning, use the exposed CMS, analytics, form, chat, and payment clues to start an inventory, then confirm it with the site's owners and account records before estimating a migration.
  • Learning and inspiration, curious what stack a beautifully designed site uses? Technology detection lets you learn from sites you admire.

Combine this with the WordPress Theme & Plugin Detector for deeper WordPress analysis, or the SSL Certificate Checker to complete your site security profile. Check the site's font stack to see whether fonts are self-hosted or loaded from external CDNs, relevant for GDPR and performance. To inspect publicly exposed PHP version clues, use the PHP Version Checker.

Turn a technology clue into a decision

Open the evidence under a detected technology. A generator tag, an asset URL and an HTTP header are different observations; several independent signatures are stronger evidence than one filename.

  • A WordPress asset path: confirm the active platform and version in Site Health. A copied or cached asset can outlive a migration.
  • An analytics script: test that an intended action produces the right event once. Script detection cannot establish correct reporting.
  • A CDN header: inspect representative responses and the resource waterfall. A detected provider does not prove a cache hit or good Core Web Vitals.

Our Gridinta migration case study pairs implementation changes with dated test reports. Use that method to evaluate a change on your site, then follow the relevant checks in your result.

CMS Detector: Check Which CMS a Website Uses

Use it as a CMS checker: enter the address above and look at the CMS, Website Builder and E-commerce Platform groups in the result. The checker recognizes these platforms when they leave public evidence in the page, its headers or its cookie names:

  • CMS: WordPress, Drupal, Joomla, Ghost, HubSpot CMS, Blogger, TYPO3, Umbraco, Sitecore, Adobe Experience Manager and 1C-Bitrix.
  • Website builders: Wix, Squarespace, Webflow, Duda, Framer, Tilda and Weebly.
  • E-commerce: Shopify, BigCommerce, Adobe Commerce (Magento), PrestaShop and Shopware, plus WooCommerce on WordPress.
  • Static site generators: Astro, Hugo, Gatsby, Docusaurus, VitePress, Jekyll and Eleventy, usually through a generator tag or their own page markers.

What counts as evidence

Every match lists the clues behind it, and the confidence label depends on how specific they are. Typical evidence:

  • Platform file paths: /wp-content/ or /wp-includes/ for WordPress, /sites/default/files/ for Drupal, /media/system/ for Joomla.
  • Platform asset hosts: cdn.shopify.com, static.wixstatic.com, Squarespace and Webflow asset domains.
  • Generator tags: a meta name="generator" value such as "WordPress 6.8" or "Drupal 11". These are the only source we use for a WordPress core version.
  • Platform markup and headers: data-drupal- or data-wf-site attributes, the x-shopify-stage or x-wix-request-id response headers, and platform cookie names.

High confidence means one platform-specific clue or corroboration from two independent sources. Medium and low results rest on less distinctive clues. If two platforms both match strongly, the result says so, because an embedded store, migration leftovers or a mixed setup can expose both.

Limits: headless and custom builds

  • Headless CMS: when a CMS only feeds content to a separate front end, the public page shows the front end, such as Next.js, Nuxt or Astro, not the CMS. A headless WordPress site is detected only if it still serves files from WordPress paths. The checker has no signatures for API-only CMSs such as Contentful, Sanity or Strapi.
  • Custom builds: a hand-built site or a framework without a public marker can return no CMS at all. That does not prove there is none, only that nothing public identified it.
  • Hidden or blocked pages: sites can remove generator tags, rename asset folders or answer with a bot check. For a bot check or a page built by JavaScript, use Paste page source above to run the same detector on the HTML your browser received.

For WordPress sites, the WordPress Theme & Plugin Detector goes one level deeper and lists the public theme and plugin clues.

A free BuiltWith or Wappalyzer alternative?

For checking one website, often yes. For market research, no. The difference is scope:

This checker BuiltWith and Wappalyzer
Lookup One URL at a time, free, no account Single lookups plus paid bulk lookups and APIs
Evidence The matched clue, its source and a confidence label for every result Technology names and categories, without the clue that matched
Coverage Just over 100 technologies, chosen for website owners and agencies Thousands of technologies
Lead lists and history None: no lists of sites using a technology and no history of past stacks Core paid features
Rendered page Reads the server response; no JavaScript is run Wappalyzer's browser extension also sees the page your browser rendered

Use this checker when you need to know what one site runs and why the result says so, for example before a migration quote. Use BuiltWith or Wappalyzer when you need lists of sites, historical data or thousands of lookups.

Technologies We Detect

This tool identifies technologies across a wide range of categories:

  • CMS, website builders & E-commerce, WordPress, Shopify, Wix, Squarespace, Webflow, Drupal, Joomla, Ghost, Magento, WooCommerce, BigCommerce, Duda, Framer, PrestaShop, Tilda, 1C-Bitrix, Weebly, HubSpot CMS, Blogger, Shopware, TYPO3, Umbraco, Sitecore, Adobe Experience Manager, and more.
  • JavaScript Frameworks, React, Next.js, Vue.js, Nuxt.js, Angular, Svelte, SvelteKit, Astro, Gatsby, Remix, Ember.js, jQuery. A framework that only runs on another one also lists that technology, marked as implied.
  • Static site generators, Astro, Hugo, Gatsby, Docusaurus, VitePress, Jekyll, Eleventy.
  • UI Frameworks, Bootstrap, Tailwind CSS, Foundation, Material UI, including version banners in the site's own CSS or JavaScript files.
  • Analytics & Marketing, Google Analytics, Tag Manager, Facebook Pixel, Hotjar, Plausible, Matomo, Microsoft Clarity, HubSpot, Intercom, Mailchimp, Brevo.
  • Consent managers, OneTrust, Cookiebot, CookieYes.
  • Hosting, CDN & edge clues, Vercel, Netlify, Cloudflare, Amazon CloudFront, Amazon S3, Fastly, and managed hosts such as WP Engine, Kinsta, WordPress VIP, WordPress.com, Pantheon, Flywheel and SiteGround.
  • Server & backend clues, Nginx, Apache, LiteSpeed, PHP, ASP.NET, Express, Java Servlet, Ruby on Rails, Laravel and Django. These can describe an edge proxy or session convention rather than the complete origin architecture.
  • SEO & Page Builders, Yoast SEO, Rank Math, Elementor.
  • Fonts, Payments & Security, Google Fonts, Adobe Fonts, Stripe, PayPal, reCAPTCHA, hCaptcha, Turnstile.
  • Declared page language, the HTML lang value is shown separately from backend programming-language clues, with a warning if it conflicts with the Content-Language header.

For a broader SEO audit beyond technology detection, check the Meta Tag Checker and Schema Markup Validator to ensure the site's on-page SEO and structured data are properly configured.

Which Language Is a Website Written In?

A website language check can mean the language people read or the technology used to build it. The report separates these observations:

Illustrative clueHow to read itHow to confirm
<html lang="en">The page declares English. This is metadata, rather than automatic classification of its text.Compare the visible content, HTML declaration and translated route.
/_next/static/A Next.js asset signature. React can also appear as implied because Next.js uses it.Review the site’s project dependencies and which parts use that framework.
X-Powered-By: PHP/…The response exposes a PHP banner. It does not reveal all backend code or verify its version.Check the active runtime in the hosting account or application administration.

No backend-language result means no supported public signature was found in this scan. It does not establish that the site uses only HTML, or that a particular backend is absent. A headless CMS, private API or bundled application can leave few public clues.

If the question is who supplies the infrastructure, use the Website Hosting Checker to inspect public DNS and network records alongside this response-based report.

What’s new

  • Explains scan timeouts and unreadable responses in both URL and pasted-source checks.

  • Reserves room before scanning and keeps long reports compact, with expandable technology details and complete exports.

  • Bot-check pages from Cloudflare, Akamai and similar services are labelled as blocked instead of being shown as normal results.

Next steps

Website Technology Checker related tools and articles

Continue with the closest follow-up checks and guides based on this tool's topic, crawl intent, and optimization workflow.

WordPress vs Astro

Is Astro right for your business?

Custom website vs template

What Is Astro? A Plain-English Guide for Business Owners

How to Use Google Search Console: A Guide for Business Owners

Elementor PHP Requirements: Versions, Memory and Compatibility

Technology Checker: FAQ

How do I find out what technology a website uses?
Enter a public URL and run the scan. This website technology checker follows safe public redirects and looks for exposed clues in the final response that can identify the CMS or website builder, frontend frameworks, analytics, hosting and CDN services, fonts, ecommerce software, and some server or programming-language signals. It cannot see a private backend or every technology loaded later by a browser.
Can this identify a website's platform or programming language?
It can identify website platforms such as WordPress, Shopify, Wix, Squarespace, and Webflow, plus backend clues such as PHP or ASP.NET when public headers or cookies expose them. The page's declared human language is reported separately from backend technology clues. A missing result does not prove that a platform or language is absent.
What CMS is this site using?
Enter the site's URL and read the CMS, Website Builder and E-commerce Platform groups in the result. Matches come from public clues such as generator tags, asset paths like /wp-content/, response headers and cookie names, and each one shows its evidence. A headless or custom-built site can show no CMS, which does not prove there is none.
How can I tell if a website is built with WordPress, Shopify or Wix?
Each platform leaves its own public signature: WordPress loads files from /wp-content/ or /wp-includes/ and often has a generator tag, Shopify loads assets from cdn.shopify.com and sends Shopify headers, and Wix serves files from static.wixstatic.com and sends an x-wix-request-id header. The result names the clue that matched. For a WordPress site, the WordPress Theme & Plugin Detector then lists its public theme and plugin clues.
Is this a free BuiltWith or Wappalyzer alternative?
For checking one website, often yes. It is free, needs no account, and shows the clue, source and confidence behind every result. It does not replace their paid products: it checks one URL at a time, covers just over 100 technologies rather than thousands, does not run JavaScript, and offers no lists of sites using a technology, no history of past stacks and no bulk API.
How does the technology checker identify a site's stack?
After following safe public redirects, it compares the final HTML and response headers, meta tags, cookie names, and up to 300 script or stylesheet URLs against specific signatures for CMSs, frameworks, analytics, hosting, security, marketing, fonts, and other technologies. It also reads the opening 300 KB of up to three of the site's own CSS or JavaScript files to find version banners such as Tailwind CSS, Bootstrap and jQuery. A framework that only runs on another one, such as Next.js on React, also lists that technology, marked as implied.
Does the checker execute JavaScript or inspect the live DOM?
No. It performs a server-side GET request, follows safe public redirects, and scans the final response. Technologies loaded only after JavaScript runs, consent is granted, a user logs in, or an interaction occurs may not appear.
Can a detected technology be a false positive?
Yes. High confidence means at least one technology-specific signal or corroboration across independent public sources. Medium and low results rely on less distinctive clues. Every result shows the evidence that matched, but embedded services, migration leftovers, proxy headers, and copied markup can still mislead.
Why might a technology be missed?
Sites can remove identifying headers, rename or bundle assets, block automated requests, or expose different markup by region, consent state, or user agent. This checker does not render the page, and it reads only the opening of a few same-host stylesheets or scripts. When a site answers with a bot-protection check instead of the page, the result says so and lists header clues only.
How reliable are detected version numbers?
Version clues include their source and provenance. WordPress core versions come only from WordPress generator declarations, never plugin, theme or core asset ver parameters. Conflicting declarations remain unresolved. Public versions may be stale; this scan does not establish patch or vulnerability status.
Does a server or X-Powered-By result prove the hosting architecture?
No. Those values are direct response headers and may describe a CDN, reverse proxy, edge platform, or intentionally altered banner rather than the origin server. Treat them as clues, not a complete infrastructure map.
What is a useful next step after identifying the stack?
Use the evidence as a starting inventory for migration planning, compatibility checks, performance reviews, or competitor research. Verify consequential findings against package, plugin, tag-manager, and hosting records you control.
Can I export a stack inventory?
Yes. Copy or download CSV or JSON after a successful scan, including an empty result. Exports contain detected technologies, evidence sources, confidence, version provenance, uncertainty, verification steps and scan limits. URLs omit credentials, queries and fragments. Raw response headers and cookie values are not exported.
What if the site blocks the checker or only renders with JavaScript?
Some sites answer automated requests with a bot-protection check from Cloudflare, Fastly, Akamai, DataDome, PerimeterX or AWS WAF. The result then says "Blocked by bot protection, header clues only" and lists only response-header and cookie-name clues. Open the page in your browser, copy its page source and use Paste page source: the same detector runs on that HTML. Header clues such as server, hosting, CDN and cookies are not available in that mode.
Is the scanned URL or technology list stored?
The URL, or pasted page source, is sent to Web Aloha's server for analysis; a URL scan uses a live fetch with a 12-second timeout. When research collection is enabled, limited technical results from URL scans may be used for research for up to 90 days to produce aggregate website statistics, then removed by daily cleanup. Research records use coded website and page keys, without raw URLs, page text, raw headers, names, email addresses, visitor IP addresses, or analytics IDs. Pasted source and its results are excluded from research collection. Ordinary hosting and analytics processing is described in our Privacy Policy.