Website technology guide

How to Find Out What a Website Is Built With

Public website responses can reveal clues about a site’s content management system, libraries and services. They do not expose its complete architecture. To find those clues, start with PeerPeek’s Technology Checker: it compares a fetched response with known technology fingerprints and groups the matches by category.

Technology detection recognizes public signals. It does not access the website’s source repository, administration area or private systems. Treat the report as a starting point for understanding what a visitor-facing response reveals.

Enter a domain such as example.com. PeerPeek also accepts an HTTP(S) URL, but extracts its hostname, discards the path, query and fragment, and removes a leading www. when the remainder is a domain. Other subdomains are retained. For example, https://www.example.com/shop starts a check of example.com/, not the shop page. Internationalized domain names are supported; credentials, IP addresses and nonstandard ports are rejected.

What you can discover

PeerPeek displays the categories attached to detected technologies. These examples have public-response rules in the fingerprint database used by the current implementation; they are examples of coverage, not a promise to identify every installation.

CMS: content platforms such as WordPress and Drupal.
JavaScript frameworks and Web frameworks: for example, Next.js. JavaScript libraries includes jQuery.
Analytics: services such as Google Analytics. A reference can suggest an integration without establishing that it collects data.
Ecommerce: store platforms such as Shopify, which can also appear under CMS.
CDN: delivery services such as Cloudflare.
Web servers and Reverse proxies: software such as Nginx. These categories describe identifiable signals at the public edge, not necessarily the origin server.

These categories and examples reflect PeerPeek’s current detection coverage. One website can use several libraries, analytics services or content systems. A technology can belong to several categories, so seeing its name in two groups does not mean two installations were found.

How website technology detection works

PeerPeek tries the domain’s root over HTTPS first. It falls back to HTTP only if HTTPS fails before response headers arrive. It follows up to four HTTP redirects, validating each destination, and analyses the final response. That response may come from another hostname. HTTP redirects differ from JavaScript navigation or a page’s timed refresh; see MDN’s explanation of redirections.

Signals the engine actually reads

PeerPeek’s technology detection engine performs static matching on response headers and body bytes. HTML patterns, named metadata and script source URLs provide clues. Stylesheet paths can match HTML rules; PeerPeek does not fetch the referenced stylesheet or script files.

Metadata: a tag such as <meta name="generator" content="WordPress"> can identify a CMS. WordPress documents its generator output, and the engine has a corresponding rule.
Resource references: a script source containing /wp-includes/ or a stylesheet link under /wp-content/ can support a WordPress match.
Headers: Server: nginx can suggest Nginx; CF-Ray can suggest Cloudflare. The same response can identify both a platform and a delivery layer.
Cookies set by the response: cookie rules can recognize names such as PHPSESSID from Set-Cookie. These are response headers, not cookies read from your browser. The engine can match their associated text too; the report does not display cookie values. See the Set-Cookie documentation.

A script URL is a reference in the response, not proof that a browser downloaded or executed it. A script element can refer to external code, but recognizing that reference does not establish successful loading, consent or execution. See the HTML script documentation.

Independent WordPress clues: generator metadata, a wp-includes script path and a wp-content stylesheet path each support a possible WordPress identification. They do not prove the private architecture. — Illustrative WordPress clues, not a scan result. A rule may match one clue; detection does not require all three or establish the whole architecture.

Captured data is not all detection input

The application captures the requested and final URLs, HTTP status, content type, charset, redirect count, body size, truncation flag, fetch duration and fetch time. It also holds response headers and body bytes during processing. The internal detector request includes the final URL and status, but the matching call uses only the headers and body. The separately extracted cookie-name list is not sent as a separate input; cookie matching reads the headers.

PeerPeek does not launch a browser, execute JavaScript, inspect a rendered page or observe browser network traffic. Public text can identify a technology even when its code never runs. Conversely, content created only after JavaScript execution is outside this check.

The engine also supports implied technologies: a matched rule can add related technologies. These are inferences from the rule relationship, not additional observations of private software. PeerPeek does not label individual entries as direct or inferred, so a database or programming-language entry does not prove a particular backend deployment.

How to read a PeerPeek report

Start with the response context, then read the technology groups. A result describes the response fetched for that analysis, not a complete software inventory.

Report area	What to read	How to interpret it
Summary	Analysed domain, detected technology count, provider outcome and detection duration.	The domain is normalized input. Detection duration concerns matching, not page speed or the full waiting time.
Technologies by category	Technology name and category group, plus a version when available.	Categories organize matches. A repeated name in different groups can be the same technology.
Website snapshot	Requested URL, Final URL, HTTP status, Redirects and HTTPS.	Read the final hostname and status before attributing matches to the site you intended to inspect. HTTPS describes the final response.
Document coverage	Content type, Charset, Body size and Body truncated.	A truncated body means later bytes were not analysed. Charset is the response header’s declaration; it is not a browser rendering result.
Timing	Fetch duration and Fetched at in the snapshot; completion time above the report.	Fetched at records the observation in UTC. Completion records when processing finished, which can be later.

A detected version can come from a public string. That string may be stale, customized or misleading, and may identify a referenced asset rather than the entire platform. No version does not mean the software is current or outdated. The report does not expose confidence percentages, matched snippets or a per-entry evidence trail.

Stored reports and fresh checks

Each accepted submission on the Technology Checker creates a new analysis; this tool does not reuse a previous report through a freshness window. Opening an existing result URL reads its stored record and does not fetch the website again. Where Check again appears, it reloads that record’s status; it does not start a fresh scan. To inspect a deployment change, return to the checker and submit the domain again.

Copy link shares the result URL. Anyone with that URL can open the report, so treat it as shareable rather than private. Stored technology results and snapshot metadata reflect the recorded observation, not the website’s current state. PeerPeek does not store the fetched body or response headers for later inspection in this report, and the public checker does not provide a technology change timeline.

Why technologies can be missing or misidentified

Absence from the report does not prove absence from the website. A false negative is a technology that is present but not detected. A false positive is a reported match that does not describe the site’s actual use. Both are possible when matching public patterns.

Removed or customized identifiers: a site can omit generator metadata, change identifying headers or use custom markup.
Bundled, renamed or self-hosted assets: a distinctive filename or vendor URL may disappear. The code can still be present without its familiar public reference.
Generic or overlapping patterns: shared names, copied markup and stale resource references can suggest a technology that is no longer used.
CDNs and reverse proxies: the visible header may identify the intermediary while hiding or replacing the origin’s headers.
Conditional content: consent gates, geography, language and visitor state can change the returned page. A tag loaded only after consent may leave no initial-response clue.
Access restrictions and challenges: a login wall, bot challenge or error page can replace the intended page. Matches may describe that response or its protection service.
JavaScript-generated content: the check does not execute JavaScript, so technologies revealed only after scripts run may be missed. Truncation can also remove clues near the end of a document.

Empty, incomplete and failed are different outcomes

“No known technologies matched” means a document was fetched and analysed without a known match. It is a valid empty result, not a statement that the site uses no software.

“Document body was truncated” means matching used only the bytes received before the size limit or an interrupted transfer. Some matches can still be useful, but the observation is incomplete; there is no completeness percentage.

Skipped or unsupported documents are not empty successful scans. The fetcher accepts HTML, XHTML, XML and plain text, and will also try a response with no Content-Type. A PDF or image response is skipped, as is an empty body; a domain with no address records can also be skipped. A blocked destination or unavailable fetch has its own provider outcome and explanation. Detector or resolver failures can instead produce “The analysis failed”; a missing report is a separate retrieval error.

An HTTP 403 or 500 does not by itself prevent matching if the response contains a supported document. Check the status and final URL: a successful detection of a challenge page can still be the wrong observation for your intended comparison. The tool does not certify that the expected page was served.

Practical uses

Preparing for a website migration

Use the category groups to draft an initial list of the visible CMS, store platform, libraries and third-party services. Separate the items you expect to move from those you plan to replace. Then use authorized administration and repository access to verify extensions, custom code, build dependencies, scheduled jobs and data stores. A frontend match cannot tell you which private integrations or business processes the migration must preserve.

Preparing for a client conversation

A report can make the first conversation more specific: “The public response suggests this CMS and an analytics reference; are those still part of your setup?” That is a useful question without claiming access to private infrastructure. Ask which systems the client owns, who maintains them and which integrations matter to their workflow.

Comparing websites

Compare category groups and visible versions alongside the final URL, status and Fetched at time. A storefront, a redirect destination and a challenge page provide different samples. Different match counts can reflect page content and detection coverage rather than a larger stack or greater technical complexity. Detection alone does not rank performance, security or implementation quality.

Checking a public deployment

After a change, submit a new check and look for an expected public signal, such as a newly exposed CMS identifier or the removal of an old library reference. Check the new fetch time and destination. An old signal may remain because cached HTML or an unused reference is still served. A new analytics match establishes neither correct configuration nor delivery of events; use the integration’s own authorized validation tools to test its operation.

What the report cannot establish

Technology detection alone does not establish:

That a vulnerability exists, or that a website is secure.
That a platform, theme or plugin is fully updated.
That a third-party integration is executing or collecting data correctly.
The complete backend, database, hosting topology or private source code.
Ownership, licensing rights or permission to access private systems.

A publicly detected version can guide further authorized investigation, but this is not a vulnerability assessment. The report does not test exploitability, inspect installed patches or establish which components are reachable behind the public response.

The fetched response supplies headers and body for matching, with URL, status and timing kept as context. Private code, authenticated configuration, complete databases and browser runtime activity remain outside the check. — The response is the observation boundary. Inferred technologies can appear in a report without direct access to the systems they describe.

How to investigate further

Confirm the page actually checked. Read Requested URL and Final URL, including their hostnames, then the HTTP status. The input path is discarded; the final page can still have a path introduced by a redirect.
Read the categories and versions in context. Identify which entries matter to your question. Allow for several technologies in one category and for inferred relationships.
Compare important clues with the public response. Where appropriate, inspect the original response or page source and response headers using your browser’s developer tools. Distinguish original HTML from the DOM after JavaScript runs. Your browser may receive different content, and PeerPeek does not provide the original response bytes for replay.
Use authorized access for a definitive inventory. Administration screens, dependency manifests, lockfiles, deployment records and infrastructure configuration answer questions that public fingerprints cannot.
Submit a fresh check after relevant changes. Return to the Technology Checker, submit the domain and compare its new Fetched at time. Reopening the old report does not refresh the observation; the website or its CDN can still serve cached content.

Choose the tool that answers your next question. The domain lookup guide covers registration, DNS and website status; the SSL guide explains certificate validity and trust; the performance guide separates lab audits from real-user measurements. None of those results makes a technology match more certain. Each describes a different part of the website.

Sources and further reading

WordPress: generator output.
MDN: HTTP redirections, Set-Cookie response headers and the script element.