13 Ways To Find the Tech Stack of Any Website

13 Ways To Find the Tech Stack of Any Website

How I find the tech stack of any website — a practical, step-by-step guide

I love digging into how websites are built. It’s like reading the blueprint of a house — messy wiring, clever hacks, and much more. In this post we will walk through every useful, ethical method and possible methods we use to identify a website’s tech stack: front-end frameworks, back-end language, CMS, CDNs, analytics, hosting, and more.

Important note (ethics): everything below is about observing public signals. Do not scan, probe, or access resources you don’t have permission to test. Don’t try to access private files, run port scans on third-party servers without consent, or exploit misconfigurations. When in doubt: ask for permission.

These are just for learning purpose.

Follow: Techolyze for more in-depth guides and learning.

Quick overview — how to approach this

When you have to check a site you need follow this order:

  1. Quick glance (URL patterns, visible meta tags).

  2. View source + DevTools (fast wins).

  3. Check headers & network resources.

  4. Use browser extensions & online services for confirmation.

  5. DNS / WHOIS / hosting clues.

  6. Combine signals and rate confidence.

Below are the methods we use — each with step-by-step instructions and examples.

1) View page source (the fastest first look)

Why: many sites leave telltale strings in HTML (meta generator tags, links to framework assets).

Steps

  1. Open the page in your browser.

  2. Right-click → View Page Source (or Ctrl+U).

  3. Search (Ctrl+F) for keywords: wp-, __NEXT_DATA__, angular, vue, react, generator, wp-content, shopify, gatsby, jekyll.

  4. Look at the <head> for <meta name="generator" content="..."> or script/link URLs that reveal libraries.

Example

  • If you see /wp-content/themes/ or /wp-content/plugins/ → almost certainly WordPress.

  • If you find a large script tag named __NEXT_DATA__ or JSON object with "next" → likely Next.js (server-rendered React).

2) Browser DevTools — Elements, Network, Application (my go-to)

Why: DevTools shows scripts, XHR requests, cookies, service workers — a goldmine.

Steps

  1. Open DevTools (F12 or Ctrl+Shift+I).

  2. Elements: inspect the DOM — is there a root div <div id="root"> (React), <app-root> (Angular), or <div id="__next"> (Next)?

  3. Network: reload the page (disable cache) and inspect JS/CSS files and XHRs. Look at script filenames and request paths.

  4. Application (Storage): inspect cookies, localStorage and sessionStorage keys — cookie names often reveal framework/CMS (e.g., laravel_session, PHPSESSID, wordpress_logged_in).

  5. Console: sometimes frameworks log warnings that reveal versions or devtools hooks.

Example

  • Network shows requests to cdn.shopify.com → Shopify.

  • Application → cookie named wp-settings-1 → WordPress.

3) HTTP headers (quick server hints)

Why: servers or middlewares sometimes include headers revealing server, framework, or CDN.

Steps

  1. Use curl -I https://example.com (or browser devtools → Network → click main request → Headers).

  2. Check for headers: Server:, X-Powered-By:, Via:, CF-Cache-Status, X-Cache.

  3. Interpret: Server: nginx says webserver; X-Powered-By: Express suggests Node.js/Express backend; Server: cloudflare usually means Cloudflare sits in front of origin.

Example header block

HTTP/1.1 200 OK
Server: cloudflare
X-Powered-By: Express
CF-Cache-Status: HIT

Here I’d conclude Cloudflare is the CDN/proxy and the origin app might be Express (Node.js).

4) JavaScript globals & in-page clues

Why: many frameworks expose global variables or specific markup.

Steps

  1. In DevTools Console type a few checks:

    • window.__NEXT_DATA__ → Next.js SSR data.

    • window.__REACT_DEVTOOLS_GLOBAL_HOOK__ → React present.

    • window.__VUE_DEVTOOLS_GLOBAL_HOOK__ → Vue present.

  2. Inspect inline JSON-LD (<script type="application/ld+json">) — may reveal CMS or plugins (e.g., schema added by Yoast SEO).

Example

  • window.__NEXT_DATA__ exists and contains props.pageProps → strong Next.js evidence.

5) Check for common CMS/Platform patterns

Why: CMSs leave consistent URL and folder structures.

Steps & examples

  • WordPress: look for /wp-content/, /wp-admin/, xmlrpc.php, wp-json/.

  • Shopify: assets from cdn.shopify.com, presence of shopify in HTML comments, /collections/ and /products/ URL structure.

  • Drupal: paths like /sites/default/files/ or meta tags mentioning Drupal.

  • Squarespace / Wix: usually more opaque but you’ll see platform-specific inline comments or URLs.

6) Browser extensions & devtools plugins (fast confirmation)

Why: tools like Wappalyzer & WhatRuns detect many technologies automatically.

Steps

  1. Install Wappalyzer or WhatRuns in your browser.

  2. Navigate to the site — the extension icon shows detected tech.

  3. Click the icon to see libraries, server, analytics, frameworks.

Example

  • Wappalyzer reports: React, Webpack, Google Analytics, Cloudflare — great for quick confirmations.

7) Online services (BuiltWith, Netcraft, SimilarTech)

Why: these services aggregate fingerprints and historical data.

Steps

  1. Go to BuiltWith (or Wappalyzer online) and paste the URL.

  2. Read the breakdown: analytics, frameworks, widgets, CDN, hosting.

  3. Cross-check with your DevTools findings.

Note: these services are a great second opinion — they often list versions and trends.

8) DNS, WHOIS, and hosting clues

Why: nameservers and DNS records help identify hosting/CDN.

Steps

  1. Use dig example.com NS or online DNS lookup to see nameservers.

  2. If nameservers are cloudflare.com or awsdns, that indicates Cloudflare or AWS.

  3. WHOIS lookup may show registrar or hosting contact (limited for privacy-protected domains).

Example

  • NS: ns1.cloudflare.com → site uses Cloudflare.

9) Certificates & TLS information

Why: certificate issuer and SANs sometimes reveal hosting provider or vendor.

Steps

  1. Click the padlock in browser → View Certificate (or use openssl s_client).

  2. Check Issuer (Let’s Encrypt, DigiCert) and Subject Alternative Names (SANs).

  3. Some platforms (e.g., Shopify) present specific certificate patterns.

10) Look for APIs, GraphQL endpoints, and AJAX patterns

Why: endpoints tell you the backend style.

Steps

  1. In DevTools → Network, filter XHR/Fetch requests and inspect endpoints.

  2. /api/ with JSON payloads and cookies → API-driven app.

  3. /graphql endpoint or POST XHRs with query → GraphQL backend.

Example

  • Frequent calls to /api/posts returning JSON → headless CMS or custom API (maybe Node/Express, Next.js, etc.).

11) Third-party tags and analytics

Why: analytics providers and tag managers are easy to spot and useful to know.

Steps

  1. Search source for gtag(, ga('create', G- (GA4), matomo, segment, gtm.js (Google Tag Manager).

  2. Tag managers usually load many vendor scripts — check which tags are firing.

Example

  • GTM-XXXX → Google Tag Manager; UA- or G- suggests Google Analytics.

12) Fingerprinting & favicon hashing (advanced finger-printing)

Why: some fingerprinting services identify stacks by favicon hash or JS file hashes.

Steps

  1. Note favicon.ico path and URL.

  2. Use services that map favicon hashes to tech stacks (I use this only as corroboration).

  3. Treat this as one more signal — not definitive.

13) Command-line & remote probes (with strict ethical limits)

Why: CLI tools can reveal DNS and header info quickly.

Steps (ethical)

  1. Use curl -I for headers and dig for DNS.

  2. Don’t run intrusive scans (nmap/shodan port scans) without explicit permission.

  3. Use whois for ownership metadata.

14) How to combine evidence (confidence scoring)

We never have to trust one single indicator. Combine multiple signals and assign a confidence level:

  • High confidence: /wp-content/ + WP cookies + /wp-admin/ → WordPress.

  • Medium: X-Powered-By: Express but obfuscated JS → likely Node/Express but could be misleading.

  • Low: a single external script from a vendor (could be just a widget).

Make decisions like a jury: multiple independent pieces of evidence increase confidence.

15) Common pitfalls & false positives

  • Headers can be intentionally misleading (proxies mask origin).

  • Single third-party scripts don’t mean the whole site uses that stack.

  • Minified/bundled JS may hide original library names.

  • Serverless and headless setups blur classical "CMS" categories.

Quick cheat-sheet

  • View source → search for wp-, next, __NEXT_DATA__, generator.

  • DevTools Network → check script names and XHR endpoints.

  • Cookies → PHPSESSID, laravel_session, wp- keys.

  • Headers → X-Powered-By, Server, CF-.

  • DNS/WHOIS → nameservers reveal CDNs/hosts.

  • Extensions/Online tools → Wappalyzer, BuiltWith, WhatRuns.

  • Console globals → window.__NEXT_DATA__, React/Vue hooks.

  • Tag/Analytics → G-, UA-, gtm.js, matomo.

Related Posts