A modern website is rarely built with a single technology.
What looks like a simple ecommerce store or company website in a browser may actually combine a content management system, JavaScript framework, CSS library, backend application, CDN, analytics platform, payment provider, authentication service and several third-party integrations.
That is why asking:
“What platform is this website using?”
usually tells you only part of the story.
A more useful question is:
“What is this website’s complete technology stack?”
Understanding a website's technology stack can be useful when researching competitors, planning a website rebuild, evaluating a potential client, learning how a particular feature was implemented, or simply understanding modern web architecture.
Some technologies can be identified directly from public website code. Others leave indirect fingerprints in scripts, cookies, HTTP headers, asset URLs or public API endpoints. Certain backend technologies, however, may be completely hidden.
In this guide, we will look at each layer of a website technology stack and explain what can — and cannot — realistically be detected.
You can also use WebBuildFinder to analyze a public website and bring many of these signals together in one technology report.
What Is a Website Technology Stack?
A website technology stack is the collection of software, frameworks, services and infrastructure used to build and operate a website or web application.
The stack can include everything from the code running inside the visitor's browser to the server hosting the application.
A typical modern website might look something like this:
LayerExample technologiesCMSWordPressEcommerceWooCommerceFrontendJavaScript, ReactCSS/UITailwind CSSBackendPHP, LaravelWeb serverNginxCDNCloudflareHostingAWSDatabaseMySQLAnalyticsGoogle Analytics 4Tag managementGoogle Tag ManagerPaymentsStripeAuthenticationAuth0Live chatCrispEmail marketingKlaviyo
Not every website contains every layer.
A simple static website may contain little more than HTML, CSS and JavaScript.
A SaaS application, on the other hand, could contain dozens of technologies spread across frontend rendering, API services, authentication, analytics, cloud infrastructure and internal systems.
This is also why technology detection should not be treated as an all-or-nothing process.
You may be able to identify the frontend framework with high confidence while knowing almost nothing about the database running behind it.
A good website technology analysis therefore separates confirmed public evidence from educated technical clues.
Frontend Technology
The frontend is the portion of a website that runs in the visitor's browser.
It is generally the easiest part of the technology stack to investigate because the browser must receive many of the files required to display the page.
These files may expose framework names, asset paths, class names, JavaScript bundles and other useful fingerprints.
HTML and CSS
HTML defines the structure of a webpage, while CSS controls its visual presentation.
Although almost every conventional website ultimately delivers HTML and CSS to the browser, examining those files can reveal much more than that.
For example, page source may expose paths such as:
/wp-content/themes/
which strongly suggests WordPress.
You may see:
cdn.shopify.com
on a Shopify storefront.
Stylesheets may also reveal framework-specific patterns.
A Bootstrap website might expose classes such as:
container
row
col-md-6
btn
navbar
Tailwind-based websites often contain utility-style classes such as:
flex
items-center
px-6
text-lg
bg-blue-500
md:grid-cols-3
However, CSS detection is not always straightforward.
Production websites frequently minify, combine or rename assets. Some frameworks remove most recognizable development fingerprints during the build process.
For this reason, one CSS class should rarely be treated as conclusive evidence by itself.
JavaScript Frameworks
JavaScript frameworks are an important part of modern website architecture.
Popular technologies include:
- React
- Next.js
- Vue.js
- Nuxt
- Angular
- Svelte
- SvelteKit
- Alpine.js
Framework detection can sometimes be relatively easy.
For example, Next.js sites commonly expose resources under:
/_next/
and may contain framework-specific JavaScript or data structures.
Nuxt applications may expose Nuxt-specific assets or hydration data.
Other frameworks can be significantly harder to detect after their code has been compiled and bundled.
A React application in production may no longer contain obvious references to the word "React" in its HTML.
Technology detection therefore often requires looking at several sources together:
JavaScript filenames, DOM patterns, script contents, framework-generated assets, hydration data and hosting clues.
The presence of one signal increases confidence, while several independent signals provide a much stronger result.
UI Frameworks
A JavaScript framework controls how an application behaves.
A UI framework or component library helps developers build the interface itself.
Examples include:
- Material UI
- Vuetify
- Ant Design
- Chakra UI
- Bootstrap
- PrimeVue
- Element Plus
These libraries may reveal themselves through CSS classes, component structures, script packages or stylesheet URLs.
For example, a Vue application may also use Vuetify.
That means a technology report could legitimately show:
Vue.js
Nuxt
Vuetify
These technologies are not duplicates. They represent different layers of the same frontend architecture.
Vue provides the underlying JavaScript framework, Nuxt adds application architecture and rendering features, while Vuetify supplies interface components.
JavaScript Libraries
Websites frequently use smaller JavaScript libraries alongside their main framework.
Common examples include:
- jQuery
- Lodash
- Axios
- GSAP
- Swiper
- Moment.js
- Day.js
- core-js
These libraries may support animation, HTTP requests, compatibility, sliders, utility functions or date processing.
Library detection is often possible through script URLs or JavaScript bundle contents.
Sometimes a version number is also exposed.
For example:
core-js 3.48.0
But version detection should be treated carefully.
A query parameter such as:
?ver=3.2
does not always represent the actual software version. It may simply be a cache-busting or build identifier.
A reliable technology detector should distinguish between a confirmed version and an ambiguous public asset version.
Backend Technology
The backend is where website technology detection becomes much more difficult.
Backend code runs on the server rather than inside the user's browser.
Visitors normally receive only the final output generated by that code.
A server could theoretically be written in PHP, Python, Java, Ruby, Go or JavaScript while returning almost identical HTML to the browser.
As a result, backend detection should usually be described as identifying public backend clues, not viewing the site's private backend.
Programming Language
Some websites expose evidence about the programming language used on the server.
Possible signals include response headers, cookies, framework-specific paths or error pages.
A response might contain:
X-Powered-By: PHP
or:
X-Powered-By: Express
These can provide useful evidence.
However, security-conscious websites often remove such headers.
A CDN such as Cloudflare can also sit between the visitor and the original server, making infrastructure detection more difficult.
Languages commonly encountered in web development include:
PHP
JavaScript / Node.js
Python
Ruby
Java
C#
Go
Elixir
If a technology checker reports a programming language, it should ideally explain what public signal caused that detection.
Server Framework
Programming languages are often paired with web frameworks.
PHP websites might use:
Laravel
Symfony
CodeIgniter
Python applications may use:
Django
Flask
FastAPI
Node.js applications may use:
Express
NestJS
Fastify
Ruby applications may use Ruby on Rails, while Microsoft environments may expose ASP.NET clues.
Frameworks can sometimes leave recognizable cookies, headers, paths or generated markup.
Laravel, for example, may expose cookies such as:
laravel_session
or XSRF-related cookies.
Django applications may expose CSRF-related cookies or recognizable static-file patterns.
None of these should automatically be considered proof in isolation.
The strongest detection comes from multiple independent signals pointing toward the same framework.
API Layer
Many modern websites separate the frontend from the backend entirely.
A React or Next.js frontend may communicate with APIs built using a completely different technology.
Those APIs could use:
REST
GraphQL
tRPC
JSON:API
WebSockets
A browser's network panel may reveal public API endpoints.
For example:
/api/products
/graphql
/wp-json/
WordPress exposes a REST API through:
/wp-json/
when it is publicly available.
Shopify storefronts may also expose public ecommerce requests and platform-specific resources.
However, an API endpoint tells you only what the website makes publicly accessible.
It does not necessarily reveal the internal services, database structure or private architecture behind that API.
CMS and Ecommerce Platform
The CMS or ecommerce platform is often one of the easiest technologies to identify.
Common CMS platforms include:
WordPress
Drupal
Joomla
Webflow
Wix
Squarespace
Ghost
Common ecommerce platforms include:
Shopify
WooCommerce
Magento / Adobe Commerce
BigCommerce
PrestaShop
Wix Ecommerce
Squarespace Commerce
WordPress frequently exposes distinctive paths such as:
/wp-content/
/wp-includes/
/wp-json/
A WordPress site may also reveal its active theme through:
/wp-content/themes/theme-name/
and publicly loaded plugins through:
/wp-content/plugins/plugin-name/
Shopify stores may expose:
cdn.shopify.com
along with Shopify-specific JavaScript objects, product structures and theme metadata.
Platforms can also be used in headless architectures.
For example, a website might use:
Next.js frontend
+
Shopify backend
or:
React frontend
+
Headless WordPress
In such cases, the traditional CMS fingerprint may be weaker because the frontend is no longer rendered directly by the CMS.
This is one reason a complete technology analysis should look beyond the first detected platform.
Database — What Can and Cannot Be Detected
Database detection is one of the areas where technology-analysis tools can easily become misleading.
The database normally sits entirely behind the application's server.
A browser does not directly connect to it.
Common databases include:
MySQL
PostgreSQL
Microsoft SQL Server
MongoDB
Redis
MariaDB
SQLite
DynamoDB
Knowing that a website uses WordPress may make MySQL or MariaDB statistically plausible because those databases are commonly used with WordPress.
But that does not mean the specific site's database has been publicly detected.
Likewise, a Laravel application might use MySQL, PostgreSQL or another supported database.
Without direct public evidence, the correct result should be:
Database not publicly detectable.
There are occasional cases where database technology becomes visible through public error messages, APIs, documentation or improperly exposed metadata.
But intentionally triggering errors or probing private endpoints moves beyond ordinary public technology detection and may create security and authorization concerns.
WebBuildFinder is designed around public website signals rather than intrusive infrastructure probing.
Infrastructure
Website infrastructure describes how the application is hosted and delivered to visitors.
This can include cloud platforms, hosting providers, reverse proxies, CDNs and web servers.
Infrastructure analysis can provide useful insight into how a website handles performance, scaling and security.
CDN
A content delivery network distributes website assets through servers positioned closer to visitors.
Common CDNs include:
Cloudflare
Amazon CloudFront
Fastly
Akamai
Bunny CDN
CDNs can reveal themselves through DNS records or HTTP response headers.
Cloudflare, for example, may expose headers such as:
cf-ray
Amazon CloudFront may expose headers beginning with:
x-amz-cf-
Detection becomes more complicated when a website uses multiple delivery layers.
A business could use Cloudflare in front of infrastructure hosted on AWS.
In that situation both:
Cloudflare
Amazon Web Services
may legitimately appear in the technology profile.
Hosting
Hosting detection attempts to identify where the website or application is deployed.
Modern websites may use traditional hosting companies or cloud platforms such as:
Amazon Web Services
Google Cloud
Microsoft Azure
Vercel
Netlify
DigitalOcean
Render
Railway
Fly.io
Hosting signals may come from DNS records, response headers, asset domains and platform-specific infrastructure.
Next.js websites, for example, are frequently hosted on Vercel, although Next.js itself does not require Vercel.
That distinction is important.
Detecting:
Next.js
does not automatically prove:
Vercel
Both should require their own supporting evidence.
Web Server
The web server handles HTTP requests before returning content to visitors.
Common technologies include:
Nginx
Apache
LiteSpeed
Microsoft IIS
Caddy
Sometimes the server exposes itself directly:
Server: nginx
But production websites frequently remove or replace this information.
Reverse proxies and CDNs can also hide the origin server completely.
For example, a website may physically use Nginx while visitors see only Cloudflare-related response information.
The absence of a server fingerprint therefore does not mean no web server exists. It simply means the origin technology is not publicly exposed.
Marketing Stack
Website technology is not limited to the code responsible for rendering pages.
Modern marketing websites often contain a substantial marketing technology stack.
That may include:
Google Analytics 4
Google Tag Manager
Meta Pixel
Google Ads
TikTok Pixel
Microsoft Clarity
Hotjar
Segment
HubSpot
Klaviyo
Marketo
Mailchimp
Intercom
Crisp
These technologies often leave relatively visible browser-side fingerprints because they need JavaScript to track interactions or communicate with external services.
Google Tag Manager, for example, commonly loads resources from:
googletagmanager.com
Google Analytics may expose measurement scripts or identifiers.
Meta Pixel can expose Meta-related JavaScript calls and network requests.
Detecting these tools can be useful for marketers researching how competitors measure traffic, advertise or communicate with customers.
However, modern consent platforms can delay analytics scripts until visitors accept tracking.
Server-side tracking can also make some marketing tools difficult or impossible to detect from the browser.
A scan should therefore be understood as a view of the technologies publicly visible at the time of analysis.
Payments and Authentication
Payment and authentication systems are another important layer of many ecommerce and web applications.
Common payment providers include:
Stripe
PayPal
Klarna
Adyen
Square
Braintree
Razorpay
Paddle
Payment technology can sometimes be identified from public JavaScript SDKs, checkout integrations or external domains.
Stripe, for example, may load browser-side resources from Stripe-controlled infrastructure.
However, many payment transactions happen server-side.
A website could therefore use a payment provider without exposing obvious evidence on its public homepage.
Checkout pages may reveal more information than general content pages.
Authentication systems can include:
Auth0
Amazon Cognito
Clerk
Okta
Firebase Authentication
Keycloak
Public login pages may expose authentication SDKs, OAuth endpoints, cookies or external identity domains.
Again, these are clues rather than access to the website's private identity infrastructure.
The same principle applies throughout website technology detection:
Report what the public website exposes, not what you assume must exist behind it.
Example Complete Stack Analysis
To understand how the pieces fit together, consider a hypothetical ecommerce website.
Suppose a technology scan identifies the following:
LayerDetected technologyEcommerce platformShopifyThemeDawnJavaScriptShopify storefront scriptsAnalyticsGoogle Analytics 4Tag managerGoogle Tag ManagerAdvertisingMeta PixelEmail marketingKlaviyoReviewsJudge.meCDNCloudflarePaymentsShopify Payments / public Stripe-related signalsLive chatGorgias
Looking only at the first result would tell us:
This website uses Shopify.
That is correct, but incomplete.
The fuller technology profile explains much more about how the business operates.
Shopify provides the ecommerce platform.
The theme controls much of the storefront presentation.
Google Analytics and Google Tag Manager support measurement.
Meta Pixel supports advertising attribution.
Klaviyo provides marketing automation.
Judge.me handles reviews.
A CDN helps deliver content and protect the storefront.
Customer-support tools can manage shopper communication.
That is what makes a complete technology stack analysis more useful than a simple CMS detector.
The same idea applies to a custom SaaS application.
A scan might instead identify:
Next.js
React
Tailwind CSS
Vercel
Cloudflare
Google Analytics
Stripe
Auth0
Intercom
That tells a very different architectural story.
The frontend is built around React and Next.js.
Tailwind CSS helps construct the interface.
Vercel handles application deployment.
Cloudflare may provide DNS, CDN or security services.
Stripe handles payments.
Auth0 manages identity.
Intercom supports customer communication.
Some important technologies may still remain unknown.
You might have no reliable public evidence about:
database
internal APIs
message queues
private microservices
CI/CD platform
source repository
internal monitoring
server operating system
A professional technology analysis should be comfortable saying:
Not publicly detectable.
That is better than filling gaps with guesses.
How to Check a Website’s Technology Stack With WebBuildFinder
You can perform many of the checks described above manually using browser source code, developer tools, DNS lookups and HTTP response inspection.
For a faster first pass, WebBuildFinder combines multiple public website signals into one report.
Enter a public website URL and the scanner looks for technologies across areas such as:
- CMS and ecommerce
- Shopify themes and visible apps
- WordPress themes and visible plugins
- JavaScript frameworks
- CSS and UI frameworks
- JavaScript libraries
- backend framework clues
- programming-language clues
- analytics and tag managers
- advertising pixels
- CDN and hosting infrastructure
- web servers
- payments
- authentication
- live chat
- security technologies
Each detection should be treated according to the strength of the available public evidence.
If a technology does not expose a reliable fingerprint, its absence from the report does not necessarily mean the website does not use it.
That distinction is especially important for backend applications, databases and private integrations.
Final Thoughts
Identifying a website's technology stack is not simply a matter of finding whether it uses WordPress, Shopify or React.
A complete website architecture can span several layers:
Platform
Frontend
UI framework
JavaScript libraries
Backend
API
Database
Hosting
CDN
Web server
Analytics
Advertising
Payments
Authentication
Security
Customer support
Some of those layers are relatively easy to identify from public code.
Others can only be inferred from indirect signals.
And several — particularly databases and private backend services — may not be publicly detectable at all.
The most reliable approach is therefore to combine multiple fingerprints, verify important findings manually and avoid treating assumptions as facts.
If you want to investigate a public website without checking every signal individually, you can use the free WebBuildFinder website technology detector to see what technologies the site publicly exposes and how those technologies fit together.