Free Website Technology Checker
Paste in any address and find out what it is built with: the platform, the theme, the page builder, the plugins that load something on the page, the analytics tags, the CDN and the server. It reads what the site already announces to every visitor — the same information a browser has with the developer tools open.
What this checks
Platforms: WordPress, Shopify, Wix, Squarespace, Webflow, Drupal, Joomla, Magento, and others, identified from the markup and headers.
Theme the active theme slug, the friendly name where it is a well-known one, and whether a child theme is in front of it.
Page builder Elementor, Divi, Beaver Builder, WPBakery, Bricks, or Oxygen, detected from their own markup rather than guessed from the theme.
Plugins: every plugin slug that loads a stylesheet or a script on the page, named where the slug is one we recognise.
Plugin footprint: how many distinct plugins are visible, and a flag when that number is high enough to be a maintenance problem in itself.
Analytics and tracking: Google Analytics 4, Universal Analytics, Tag Manager, Meta Pixel, Hotjar, Microsoft Clarity and LinkedIn Insight.
Caching: caching and optimisation layers found in plugin assets, response headers, or the signature they leave in the markup.
CDN: whether the site is served through an edge network and whether its static files come from a second one.
The public response status code, first-response time, HTTPS handling, and whether the platform announces its version number.
Server and e-commerce: the web server it reports, and whether the site is running a shop.
How a website tells you what it is made of
A web page is not a finished picture. It is a set of instructions telling the browser where to fetch everything from, and those instructions are written in plain text that anybody can read. A WordPress site loads its stylesheets from /wp-content/themes/astra/ and /wp-content/plugins/contact-form-7/, so the theme and that plugin have named themselves before the page has finished rendering. Elementor puts data-elementor-type on its sections. Shopify loads from cdn.shopify.com. The server adds its own name to every response.
That is all this tool does. It requests the page once, the way a browser would, and reads those names out. Nothing is probed, no hidden paths are requested, and no attempt is made to find anything the site did not already publish. It is closer to reading the credits than to looking through a window.
This also explains the gaps. A plugin that does its work entirely in the admin area — a backup tool, an SEO plugin in some configurations, a staging or security plugin — loads nothing on the front end and so appears nowhere. What you get is an accurate floor, not a full inventory.
Three good reasons to run this
The first is competitor research. Knowing that the firm outranking you runs a lightweight block theme with four plugins, while you are on a bought multipurpose theme with a builder and thirty, explains a great deal about why their pages load in a second and yours take five. It also tells you what is realistic: if they have built the thing you want on Elementor, you can have it too.
The second is inheriting a site. Taking over a website from another agency usually starts with nobody being able to tell you what it is. Running this before the handover call means you walk in already knowing the builder, the theme, whether there is a child theme, what the tracking looks like and whether anything is caching. That changes the conversation from discovery to decisions.
The third is your own site. Plenty of business owners genuinely do not know what their website is built on, because the person who built it left four years ago. Two minutes here gives you the vocabulary to ask sensible questions — and, quite often, the first sign that the site is running a theme that has not been updated since 2019.
Plugin sprawl is a maintenance problem before it is anything else
Every plugin on a WordPress site is code written by somebody else, running with full access to your database, updated on their schedule rather than yours. One or two dozen of those is normal and fine. The trouble starts when nobody is counting, because the cost of each one is invisible on the day it is installed and only shows up later.
The maintenance cost compounds. Fifteen plugins is fifteen changelogs to skim, fifteen chances that an update changes behaviour, and a rising probability that two of them disagree — which is how a site ends up with a broken checkout on a Tuesday afternoon and no obvious culprit. Then there are the abandoned ones. A plugin whose author stopped shipping two years ago keeps working right up until a PHP or WordPress release changes something underneath it, and by then nobody is going to fix it for you.
The security cost is the same arithmetic. The overwhelming majority of compromised WordPress sites are compromised through a vulnerable plugin, not through core and not through a guessed password. More plugins is more attack surface, and an unmaintained plugin is the single highest-risk thing on most sites. Deactivating is not removing, either — a deactivated plugin still sits on disk and can still be reachable.
The practical answer is unglamorous. Audit what is installed against what is genuinely used, delete rather than deactivate the rest, and replace two plugins doing one job with one that does it properly. Then put updates on a routine with a staging copy and a restore point, so an update that breaks something is ten minutes of work instead of a lost day. That is the whole of what a care plan is, and it is worth having whether you buy it from us or run it yourself.
Reading the result sensibly
Most of what this reports is information rather than fault. A page builder is not a problem, a multipurpose theme is not a problem, and nobody needs a CDN if all their customers are within fifty miles. A stack is a set of choices, and the report treats it that way.
A few things are worth acting on when they appear. A publicly announced WordPress version is a small, free thing to remove. Several analytics tools doing the same job usually means two of them were installed by different people and one is quietly double-counting your conversions. No child theme on a heavily customised site means someone's changes are one update away from disappearing. And a large visible plugin count on a site that already feels slow is the place to start looking.
Detection is also a judgement, not an oracle. Slugs get renamed, white-label builds hide their origins, and a site behind an aggressive optimisation layer that merges every stylesheet into one file will show far fewer plugins than it has, simply because the individual names have been merged away. Treat an unexpected result as a question rather than a verdict.
What this checker cannot see
It reads one page. Plugins that only load on other templates — a form plugin used solely on the contact page, a shop plugin on product pages, a booking widget on one landing page — will not appear unless you check a page that uses them. Run it against a few different URLs if you want a fuller picture.
It cannot see anything with no front-end footprint at all, which is a long list: backup tools, security plugins, migration tools, SMTP plugins, most SEO plugins in their quieter settings, editorial and workflow tools, and every custom snippet somebody dropped into the theme functions file. The real installed count on a typical site is meaningfully higher than the number shown here, and the report says so rather than implying otherwise.
It cannot tell you plugin versions, whether any of them are out of date, or whether a known vulnerability applies — a version number is not published in an asset URL in any reliable way, and inventing one would be worse than leaving it out. It cannot see anything behind a login, and it does not run the site's JavaScript, so a tool loaded only after a consent banner is accepted is invisible to it.
What it gives you is an accurate, honest floor: this is what the site is telling the world it is made of. Everything above that floor needs admin access and somebody looking.
Questions people ask
How can you tell what plugins a site uses?
WordPress serves plugin assets from predictable paths. A stylesheet loaded from /wp-content/plugins/woocommerce/ names the plugin in its own URL, and the page has to include that URL for the browser to fetch the file. This tool reads every asset URL on the page and collects the plugin slugs out of them.
Some plugins also leave other traces — a body class, a comment, a script variable — and those get picked up too. But the asset path is the main one, which is why a plugin that loads nothing on the front end stays invisible.
Is it legal to check another website like this?
Yes. This requests the public homepage once and reads the HTML and headers it returns — exactly what your browser does every time you visit a site, and exactly what you can see yourself by pressing Ctrl+U to view the source. Nothing hidden is accessed, no login is attempted and nothing is probed.
It is the same information a browser extension like Wappalyzer reads, and the same thing any developer does by hand before quoting on a project.
Why does it show fewer plugins than I have installed?
Because only plugins that load a stylesheet or a script on the page you checked can be seen from outside. Backup plugins, security plugins, SMTP plugins, migration tools, and most admin-only plugins add nothing to a front-end page, so there is nothing for the checker to read.
Two other things shrink the number. An optimisation plugin that merges every stylesheet into one combined file removes the individual plugin names in the process. And plugins used only on certain templates will not show up unless you check a page that uses them. The number here is a floor, never a total.
Is this technology checker free?
Yes, with no account and nothing to install. There is a fair-use limit so it cannot be used to profile thousands of sites at once, but normal use will not get near it.
Do I have to give you my email address?
The platform, theme, builder and the first part of the stack are shown straight away. The full plugin list and the rest of the detail sit behind an email address. You are asked once.
Does running this change anything on the site being checked?
No. It is a single read-only request for the page, the same as one visitor loading it. Nothing is submitted, nothing is written and the site owner sees one ordinary hit in their logs.
It could not identify the theme. Why?
Usually one of three reasons. The site is not WordPress, so there is no theme directory to read. The theme is fully custom, in which case the slug shown is the real answer — it just is not a name anyone would recognise. Or an optimisation layer has merged and moved the theme's stylesheets, taking the folder name out of the URL with them.
Can I use this to copy a competitor's website?
You can find out what they built it with, which is genuinely useful when you are deciding what to build yours with. You cannot get their design, their content or their code from this, and copying those would be both a copyright problem and a bad strategy. The useful takeaway from a competitor's stack is almost never "use their theme" — it is noticing that they are running five plugins and you are running thirty.
Inherited a site and not sure what is in it?
This page shows you what a site announces publicly. The full picture — what is installed, what is abandoned, what two plugins are doing the same job and which one is slowing everything down — needs someone in the admin area. That is a morning of our time and it is usually the most useful morning you will spend on the site all year.
