How to Tell What a Website Is Built On

A complete guide to identifying the technology stack behind any website using browser tools, online detectors, and expert techniques.

Image: Website tech stack detection concept showing browser tools inspecting HTML, CSS, and JavaScript source code on a responsive screen

☰ What You Will Find in This Guide

01 Introduction

02 View Page Source

03 Browser DevTools

04 Online Detection Tools

05 URL Structure Analysis

06 HTTP Headers

07 CSS & JS Analysis

08 CMS Signatures

09 Server-Side Clues

10 Robots & Sitemap

11 3rd Party Integrations

12 Common CMS Identifiers

13 Why It Matters

14 Tools Comparison

15 Practical Walkthrough

16

17 Final Thoughts

Introduction

Have you ever visited a website and wondered what makes it work? What content management system powers it? What programming language its backend uses? Which JavaScript framework makes those smooth animations possible? Being able to identify the technology stack behind a website is a valuable skill for developers, designers, marketers, and business owners alike.

Knowing what a website is built on helps you understand its capabilities, limitations, and potential performance characteristics. It can inform your own technology choices when planning a new project. It can help you identify potential competitors and understand their technical strategy. It can even tell you whether a particular site might be a good fit for a plugin, theme, or integration you are developing.

The good news is that you do not need special access or insider knowledge to figure out most websites technology stacks. In most cases, the clues are hiding in plain sight in the HTML source code, the URL structure, the HTTP headers, and the way the site behaves in the browser. With the right techniques and a little practice, you can become proficient at identifying the tech stack behind almost any website you visit.

This guide covers ten different methods for identifying what a website is built on, from the simplest approach of viewing the page source to using specialized online detection tools. Each method is explained in plain language with real examples. By the end of this guide, you will have a complete toolkit for analyzing any website technology stack with confidence.

Image: Tech stack detection concept showing a magnifying glass over website code elements with different technology nodes

Method 1: View the Page Source

The simplest and most direct way to start investigating a website tech stack is to view its HTML source code. Every web browser makes this easy. On most browsers, you can right-click anywhere on a page and select View Page Source, or use the keyboard shortcut Ctrl+U on Windows or Cmd+U on Mac. This opens a new tab displaying the raw HTML that the server sent to your browser.

Once the source code is open, there are several things to look for that can reveal the underlying technology. Start by scanning for meta tags, specifically the generator meta tag. Many content management systems automatically include a meta tag in the head section of the HTML that identifies the CMS and its version. For example, WordPress sites often include a tag like <meta name="generator" content="WordPress 6.4" />. This is one of the fastest ways to confirm a site is running WordPress.

If the generator meta tag is not present or has been removed, look at the file paths and URLs referenced in the source code. WordPress sites typically load assets from paths like /wp-content/. Shopify stores use /cdn.shopify.com for assets. Drupal sites reference /sites/default/ paths. Joomla sites include /components/ and /modules/ in their paths. Squarespace sites typically load resources from static1.squarespace.com.

JavaScript file names can also be revealing. Many frameworks and libraries have distinctive naming conventions. A reference to jquery.js or jquery.min.js tells you jQuery is in use. References to react.js, vue.js, or angular.js indicate the respective JavaScript frameworks. CSS files often include framework names in their paths too, like bootstrap.css or tailwind.css.

Do not overlook the comments in the source code. Developers sometimes leave HTML comments that reveal the framework or CMS in use. You might find something like <!-- This site is powered by WooCommerce --> or version-specific comments that developers include in their themes and plugins.

"The page source is like looking under the hood of a car. You may not understand every component, but the telltale signs are there: branded parts, specific configurations, and familiar patterns that any experienced mechanic can identify."

Image: HTML source code view in browser tab showing meta tags, script references, and link paths that reveal the CMS

Method 2: Browser Developer Tools

While viewing the page source is useful, the browser developer tools give you a much more interactive and powerful way to inspect a website technology. You can open DevTools by right-clicking anywhere on a page and selecting Inspect, or by pressing F12 on Windows or Cmd+Shift+I on Mac.

The Elements panel shows you the rendered DOM, which can be different from the raw source HTML because JavaScript has had a chance to modify it. This is particularly useful for single-page applications built with frameworks like React, Vue, or Angular, where most of the content is generated dynamically. In the Elements panel, you can inspect the class names applied to elements. Many CSS frameworks use distinctive class naming conventions. Bootstrap uses classes like container, row, and col-md-. Tailwind CSS uses utility classes like flex, text-center, and p-4.

The Network panel is one of the most valuable tools for tech stack detection. It shows every request the browser makes to load the page, including HTML documents, CSS stylesheets, JavaScript files, images, fonts, and API calls. By examining these requests, you can identify the server software from response headers, spot API endpoints that reveal the backend framework, and see the file naming conventions that hint at specific technologies. Look for headers like X-Powered-By, Server, and X-Generator in the response headers.

The Console panel can also provide clues. JavaScript errors sometimes reference framework-specific files. Console warnings from libraries like React or Vue include their version numbers. If a site is running a development build of a framework, the console may explicitly tell you. You can also run JavaScript expressions in the console to probe the environment, such as typing typeof jQuery to check if jQuery is loaded, or typeof React to detect React.

Image: Browser developer tools panels Elements, Network, Console showing how to inspect a website technology stack

Method 3: Online Detection Tools

If you want a quick, comprehensive analysis of a website tech stack without manually digging through source code, several online tools can do the heavy lifting for you. These tools crawl the site, analyze its characteristics, and generate a detailed report of the technologies detected.

BuiltWith

BuiltWith is one of the most comprehensive technology lookup tools available. Enter any URL, and it returns a detailed profile of the technologies used, including web frameworks, CMS platforms, analytics tools, CDN services, JavaScript libraries, server software, and much more. BuiltWith maintains an extensive database of technology signatures and updates it regularly. The free version provides a solid overview, while the paid version offers historical data and trend analysis.

Wappalyzer

Wappalyzer is available both as a browser extension and a website. It identifies content management systems, e-commerce platforms, JavaScript frameworks, analytics tools, and much more. Unlike BuiltWith, which runs a full scan on its servers, Wappalyzer can analyze sites in real time through your browser. The browser extension adds a small icon in your toolbar that shows the detected technologies for the current page. It is fast, easy to use, and works well for quick checks.

WhatRuns & Similar Extensions

WhatRuns is another browser extension that detects technologies as you browse. It identifies frameworks, CMS platforms, analytics services, fonts, and design tools. Similar tools include BuiltWith browser extension, Library Detector for Chrome, and Ghostery, which focuses on tracking technologies but also reveals analytics and advertising platforms. These extensions are particularly useful for competitive research and inspiration gathering, as they work silently in the background.

Image: Three online detection tools BuiltWith, Wappalyzer, and WhatRuns displayed with their logos and scan results

Method 4: URL Structure Analysis

The way a website structures its URLs can reveal a great deal about the underlying technology. Different content management systems and frameworks have characteristic URL patterns that are often easy to spot once you know what to look for.

WordPress sites, especially older ones, often include /?p=123 in their URLs, which is the default query parameter for posts. Even sites that use pretty permalinks may still respond to this parameter. The WordPress admin area is always at /wp-admin/ and the login page at /wp-login.php. These paths are reliable indicators even if the generator meta tag has been removed.

Shopify stores have URLs that include /products/ and /collections/ followed by the product or collection handle. The cart page is at /cart and the checkout is typically on a Shopify subdomain. Squarespace sites often use a ?format= parameter for different content views, while Drupal sites commonly include /node/ in their content URLs.

Custom-built applications on specific frameworks also have telltale URL patterns. Laravel applications often use /api/ routes for API endpoints. Ruby on Rails applications commonly have RESTful routes like /users/1/edit. Django applications frequently include /admin/ for their admin interface. If you see URL patterns like /index.php?route= it often indicates an older custom PHP application or OpenCart.

Image: URL structure comparison showing WordPress, Shopify, Drupal, and custom framework URL patterns side by side

Method 5: HTTP Headers

HTTP headers are sent by the server with every response, and they can contain valuable information about the server software, programming language, and sometimes even the framework in use. You can view HTTP headers using the Network panel in browser DevTools, or by using command-line tools like curl with the -I flag to fetch only the headers.

The Server header often reveals the web server software. Common values include Apache, Nginx, Microsoft-IIS, Cloudflare, and Google Frontend. Some servers also include version numbers in this header, though many production servers are configured to hide version information for security reasons.

The X-Powered-By header can reveal the programming language or framework. You might see PHP, ASP.NET, Express, or Python in this header. Many sites remove this header for security, but it is still commonly present. Similarly, the X-Generator header is sometimes set by CMS platforms like Drupal or Wix.

Cookies set by the server can also be revealing. WordPress sets a cookie named wordpress_ when you log in. Laravel sets a laravel_session cookie. ASP.NET sets ASP.NET_SessionId. These session cookie names are usually not changed from their defaults and provide reliable clues about the backend technology.

"HTTP headers are like the ID card of a web server. They may not tell you everything, but they tell you enough to know what you are dealing with. The Server header, the X-Powered-By header, and the session cookie name form a powerful trio for tech stack identification."

Image: HTTP response headers displayed in browser DevTools Network panel showing Server, X-Powered-By, and cookie information

Method 6: Analyzing CSS and JavaScript

The CSS and JavaScript files loaded by a website often contain direct references to the frameworks and libraries they use. By examining these files, you can build a detailed picture of a site frontend technology stack.

Start by looking at the stylesheet URLs in the page source or DevTools. CSS framework files typically have recognizable names. Bootstrap files often contain bootstrap in their name, Tailwind files include tailwind, and Foundation files reference foundation. If the site uses a CDN like cdnjs, jsDelivr, or unpkg, the framework name is usually part of the URL path.

Many sites also include font loading scripts that reveal specific font services. Google Fonts URLs contain fonts.googleapis.com, Adobe Fonts (formerly Typekit) use use.typekit.net, and Font Awesome icons are typically loaded from use.fontawesome.com. Icon libraries like Material Icons, Ionicons, and Feather Icons also have distinctive CDN paths.

JavaScript frameworks often leave signature patterns in the code. React sites typically have a root element with a id="root" or id="__next" (for Next.js). Vue.js applications commonly mount to an element with id="app". Angular applications include custom HTML tags like <app-root> and have distinctive attributes like ng-version on the root element. jQuery is still widely used and can be detected by checking for jQuery.fn.jquery in the console.

CSS preprocessors can also be detected in some cases. Sites using Sass or SCSS often have class names that follow BEM naming conventions with double underscores and hyphens. Sites using CSS Modules have hashed class names that look like random strings. CSS-in-JS libraries like styled-components inject unique data attributes like data-styled into the DOM.

Image: CSS and JavaScript framework detection showing React, Vue, Angular signatures and CDN resource references

Method 7: CMS-Specific Signatures

Beyond the obvious clues in page source and URL structure, each major content management system has unique behavioral and structural signatures that experienced developers can identify. These signatures stem from how each CMS handles content, renders pages, and manages assets.

WordPress, for example, automatically adds several distinctive elements to every page. It includes a reference to the WordPress REST API at /wp-json/ in the page source, usually as a link tag in the head. It also adds the WordPress embed script and includes a wlwmanifest.xml link for Windows Live Writer integration. These references are present even when other WordPress identifiers have been hidden.

Drupal sites have a distinctive HTML structure. The body tag typically includes classes like path-frontpage or path-node depending on the current page. Drupal also includes a /sites/default/files/ path for uploaded files and uses .html.twig or .tpl.php file extensions in theme-related paths.

Joomla sites include /index.php?option= in their URLs, and the HTML source often contains references to /components/ and /modules/. The Joomla admin interface is typically at /administrator/. Shopify sites always include a Shopify-specific JavaScript file called shopify_common.js and have a distinctive checkout flow hosted on a Shopify-owned domain.

Squarespace sites are typically hosted on a Squarespace CDN and include references to static1.squarespace.com. They use a unique block-based content structure in the HTML and include Squarespace-specific JavaScript files. Wix sites are easily identified by the wix.com CDN references and their characteristic inline SVG icons and dynamic loading patterns.

Image: CMS-specific signatures comparison showing WordPress, Drupal, Joomla, Shopify, and Squarespace unique identifiers

Method 8: Server-Side Clues and Error Pages

Sometimes the most revealing clues about a website tech stack come from what happens when something goes wrong. Error pages, default server responses, and file extension patterns can all provide strong signals about the underlying technology.

Try visiting a non-existent page on the site, such as /this-page-does-not-exist. The resulting 404 page often reveals the CMS or framework. WordPress has a distinctive default 404 page layout. Shopify also has a recognizable default 404. Custom 404 pages may still include CMS-specific HTML structures, CSS classes, or JavaScript references in the source code that give away the platform.

Pay attention to file extensions in the URLs. Seeing .php extensions often indicates a PHP-based CMS like WordPress, Drupal, or Joomla. .aspx or .asp extensions point to ASP.NET. .jsp indicates Java Server Pages. However, many modern sites use URL rewriting to hide these extensions, so their absence does not rule out a particular technology. The presence of specific extensions, though, is a strong positive signal.

Server response behavior can also be revealing. How does the server handle different HTTP methods? Does it return detailed error messages in development mode? Does a specific URL pattern trigger a particular response? Some frameworks have distinctive default error handling behaviors. Laravel debug pages, ASP.NET yellow screens of death, and Django debug pages are all immediately recognizable to experienced developers. While production sites should disable debug mode, developers sometimes forget, leaving these revealing error pages accessible.

Image: Error page inspection showing 404 responses, file extension patterns, and debug mode indicators for tech stack detection

Method 9: Robots.txt and Sitemap.xml Analysis

Two of the most overlooked sources of technology clues are the robots.txt file and the XML sitemap. These files are standard for almost every website and often contain platform-specific paths and references that reveal the underlying CMS or framework.

The robots.txt file, typically located at /robots.txt, tells search engine crawlers which parts of the site they are allowed to access. WordPress sites commonly disallow paths like /wp-admin/, /wp-content/, and /wp-includes/. Seeing these paths in robots.txt is almost definitive proof of WordPress. Drupal sites often disallow /node/ and /user/. Joomla sites disallow /components/ and /administrator/.

The sitemap.xml file, located at /sitemap.xml, can be even more revealing. WordPress plugins like Yoast SEO generate sitemaps at /sitemap_index.xml. Shopify generates sitemaps at /sitemap.xml with product and collection URLs that are unmistakably Shopify. Squarespace sitemaps have a distinctive format and URL structure. The way the sitemap organizes content, the URL patterns within it, and even the XML namespace URLs can all point to a specific platform.

Some platforms also generate additional files you can check. WordPress creates a /wlwmanifest.xml file for Windows Live Writer integration. Drupal has a /update.php file. Magento generates a /sitemap.xml with distinctive catalog paths. These ancillary files are often overlooked by site owners trying to hide their platform, making them reliable indicators.

Image: Robots.txt and sitemap.xml file inspection with CMS-specific paths like wp-admin, node, components, and sitemap formats

Method 10: Third-Party Integrations and Embeddings

The third-party services a website integrates with can reveal a great deal about its technology stack. Analytics scripts, advertising networks, live chat widgets, form builders, and marketing automation tools all leave footprints in the page source that provide valuable clues.

Start by looking for analytics scripts. Google Analytics has a distinctive script structure with gtag or ga references. Facebook Pixel begins with fbq. Hotjar, Crazy Egg, and other analytics tools each have their own unique script patterns. The presence of specific analytics tools can sometimes hint at the broader technology ecosystem. For example, a site using Google Analytics, Google Tag Manager, and Google Ads is more likely to be a Google-centric stack.

Live chat and customer support widgets are also revealing. Intercom, Drift, Zendesk Chat, LiveChat, and Tidio each have their own JavaScript snippets. E-commerce sites using Shopify often integrate with specific payment processors or shipping services. The presence of a particular payment gateway like Stripe, PayPal, or Square can provide context about the e-commerce platform. Form builders like Gravity Forms are specific to WordPress, while Webflow has its own native form system.

Even the comment system can be revealing. If you see disqus.com references, the site uses Disqus for comments. Facebook comments integration uses Facebook SDK. Native WordPress comments have a distinctive HTML structure. These third-party footprints, while not directly identifying the CMS, provide additional context that helps build a complete picture of the website technology ecosystem.

Image: Third-party integration detection showing analytics scripts, live chat widgets, payment gateways, and form builder footprints

Common CMS Identifiers Quick Reference

Here is a quick reference table of the most common content management systems and their identifying characteristics for rapid on-the-spot detection.

CMS Platform

Key Identifiers

Typical URL Patterns

WordPress

/wp-content/, /wp-admin/, generator meta

/wp-json/, ?p=123

Shopify

cdn.shopify.com, Shopify JS files

/products/, /collections/, /cart

Drupal

/sites/default/, path-node class

/node/123

Joomla

/components/, /modules/, /administrator/

/index.php?option=

Squarespace

static1.squarespace.com, block structure

?format=, /s/

Wix

wixstatic.com, dynamic loading patterns

wix.com CDN references

Webflow

webflow.js, Designer class references

.webflow.io subdomain

Magento

/skin/, /media/, Magento-specific JS

/catalog/, /checkout/

This table is not exhaustive, but it covers the platforms you are most likely to encounter. As you practice identifying these systems, you will develop an intuition for the subtle differences between them. For example, you will start to recognize the distinctive administrative styling of WordPress login pages, the particular way Shopify handles product image galleries, or the unique grid system that Squarespace uses for its page builder blocks.

Image: CMS platform comparison table with WordPress, Shopify, Drupal, Joomla, Squarespace, Wix, Webflow, and Magento logos

Why Knowing a Website Tech Stack Matters

Being able to identify the technology behind a website is more than a technical party trick. It has practical applications across multiple roles and industries.

For Developers

Knowing a website tech stack helps developers understand the tools and patterns used by other teams, learn from real-world implementations, and evaluate potential approaches for their own projects. When you encounter a beautifully performing site, identifying its stack teaches you which technologies can deliver that level of performance. For freelancers and agency developers, being able to quickly identify a site CMS is essential when pitching redesign services or estimating migration projects.

For Marketers & SEO Professionals

Understanding a competitor tech stack helps marketers evaluate the competitive landscape. If a competitor is using a modern, fast-loading framework while yours is on an older, slower platform, that could explain differences in search rankings and conversion rates. Knowing what CMS a potential client uses helps you tailor your pitch and demonstrate relevant expertise. For SEO professionals, knowing the CMS helps you understand the technical SEO capabilities and limitations of a site before you start working on it.

For Business Owners & Decision Makers

If you are planning a new website or considering a redesign, understanding what technologies are available and which ones your competitors use helps you make more informed decisions. You can evaluate whether a particular CMS or framework aligns with your business needs, scalability requirements, and budget. You can also have more productive conversations with web development agencies when you understand the basic landscape of available technologies.

Image: Three stakeholder groups developers, marketers, and business owners benefiting from tech stack knowledge

Technology Detection Tools Comparison

Different tools serve different purposes. Here is a comparison of the most popular technology detection tools to help you choose the right one for your needs.

Tool

Best For

Free

Speed

BuiltWith

Deep comprehensive scans, historical data

Yes

Medium

Wappalyzer

Quick real-time detection, browser extension

Yes

Fast

WhatRuns

Design tech detection, fonts, icons

Yes

Fast

BuiltWith Ext

Quick browser-based lookups

Yes

Fast

DevTools

Deep manual inspection, full control

Yes

Manual

curl

Headless header inspection, automation

Yes

Fast

For most day-to-day needs, a combination of Wappalyzer for quick checks and manual DevTools inspection for deeper analysis is the most effective approach. BuiltWith is excellent for competitive research when you need a complete technology profile. The command line tools like curl are invaluable when you need to automate detection or work with server environments that do not have a graphical browser available.

Image: Technology detection tools comparison chart featuring BuiltWith, Wappalyzer, WhatRuns, DevTools, and curl

Practical Walkthrough: Identifying a Real Website

Let us walk through a real example to see how these techniques work in practice. Imagine you have been asked to evaluate a competitor website to understand what technology it uses. Instead of relying on a single method, you combine several approaches to build a complete picture.

You start by opening the site and using the Wappalyzer browser extension. Within seconds, it reports that the site is running WordPress with the Elementor page builder, WooCommerce for e-commerce, and Yoast SEO. The server is identified as Nginx, and the site uses Cloudflare for CDN and security. This gives you a solid starting point, but you want to verify these findings manually.

Next, you open the page source by pressing Ctrl+U. Scrolling through the head section, you find the generator meta tag confirming WordPress. You also notice references to /wp-content/ paths for stylesheets and scripts, further confirming WordPress. Looking more closely, you see elementor references in the CSS file names, confirming the page builder detection.

In the DevTools Network panel, you examine the response headers for the main page. The Server header says Nginx, matching Wappalyzer finding. The Set-Cookie header includes a WordPress session cookie. You also notice the CF-Ray header confirming Cloudflare. Each finding reinforces the others.

Finally, you check some common WordPress URLs. Visiting /wp-admin/ takes you to a WordPress login page. The URL for a product page includes /product/ consistent with WooCommerce permalinks. You have now confirmed the technology stack using four independent methods. The site is definitively WordPress with WooCommerce, Elementor, Yoast SEO, on Nginx behind Cloudflare.

Image: Step-by-step walkthrough showing detection process from initial scan to confirmed technology stack identification

Frequently Asked Questions

Final Thoughts

Learning to identify what a website is built on is a skill that gets easier with practice. The more sites you examine, the more patterns you recognize, and the faster you become at pinpointing the technology stack. Start by using online tools and browser extensions for quick identification. As you grow more comfortable, begin digging into the page source and DevTools to understand the underlying evidence that supports these automated detections.

Remember that no single method is foolproof. The most reliable approach combines multiple techniques: checking the page source for CMS signatures, using DevTools to inspect the DOM and network requests, running online tools for a comprehensive scan, and analyzing URL patterns and HTTP headers. Cross-referencing findings from several methods gives you confidence in your conclusions.

The technology landscape is always changing. New frameworks, CMS platforms, and build tools emerge regularly. Staying curious and keeping your detection skills sharp is part of the ongoing journey of working with the web. Every site you analyze teaches you something new about the choices developers make and the technologies they use to bring digital experiences to life.

Whether you are a developer looking to learn from others work, a marketer researching competitors, or a business owner making technology decisions, understanding what makes websites tick gives you a valuable perspective on the digital world. The next time you visit a site that impresses you, take a moment to look under the hood. You might be surprised at what you discover.

Image: A developer inspecting website source code across multiple devices representing the practice of technology stack detection

Michael Chen

Senior Web Developer • 10+ years building and analyzing web applications

Michael has spent over a decade building websites and web applications across a wide range of technologies including WordPress, React, Laravel, and Shopify. He specializes in technology strategy, performance optimization, and helping businesses choose the right tools for their digital projects.

Tech Stack Detection

Web Development

CMS Identification

Share:

in