To know if a website is built with WordPress, you need to check the page source for specific folder names or test a few hidden URLs. WordPress leaves a trail of core files, login pages and API endpoints behind the scenes. You can find these clues manually in seconds, or you can use an automated scanner to read the code for you.
How to know if a website is built with WordPress?
You are looking at a competitor ranking above you. You might see a layout you want to recreate. Figuring out how to know if a website is built with WordPress limits your guesswork. Around 40 percent of all websites run on this content management system. The odds are high that the site you are looking at is one of the 455 million active installs.
You do not need access to their server to find out. The platform structure is predictable. Every installation uses the same default file paths, the same login structure and the same database endpoints. When a browser loads a page, it has to download images and scripts from those exact folders. You just need to know where to look.
Sometimes developers install security plugins to mask these footprints. They rename the login page or strip the version numbers out of the code. Even then, the underlying architecture rarely changes completely. You can piece together the remaining clues to get a definitive answer.
Use a dedicated platform scanner
The fastest method is to let a script read the headers and source code for you. You can run the address through a website platform checker to see the exact content management system, the active theme and the server technology in one scan. This skips the manual work of digging through developer tools.
Automated tools read the HTTP response headers and map the site architecture against known patterns. They look for specific caching headers and pingbacks that WordPress broadcasts by default. If the site uses standard settings, the scanner will flag it immediately.
If the site owner uses aggressive caching or a proxy service like Cloudflare, the headers might be stripped. When an automated tool fails to return a clear result, you have to move to manual checks.
Search the page source for wp-content
Every website sends its HTML to your browser. You can read this code to spot the default folder structure. WordPress stores all themes, plugins and uploaded images inside a directory called wp-content. It stores its operational scripts in a folder called wp-includes.
These folder names are the most reliable fingerprint on the internet. Even heavily customised sites usually keep this structure intact.
Here is how you find them:
- Open the website in Google Chrome.
- Right click on a blank space on the page.
- Select View Page Source from the menu.
- Press Ctrl and F on Windows, or Cmd and F on a Mac, to open the search bar.
- Type wp-content into the search box.
Look at the highlighted results. You will see links to stylesheets ending in .css and scripts ending in .js. If the file paths look like /wp-content/themes/ or /wp-content/plugins/, the site runs on WordPress.
You can also search for wp-includes. This folder holds the core files that make the platform function. You will often see it linked to the jQuery library or default block styles. If either of these folders appears in the source code, you have your answer.
Test the default login URLs
Every standard installation places the admin dashboard at the exact same web address. You can test this by typing the URL directly into your browser.
Go to the address bar and add /wp-admin to the end of the domain name. Press enter. If the site is built on WordPress, you will usually be redirected to a login screen. The URL will change to /wp-login.php and you will see a grey box asking for a username and password. The WordPress logo sits right above the form.
This is a definitive test. If the login screen loads, the site uses the platform.
However, a missing login page does not mean the site uses something else. Security plugins routinely change this address to stop automated brute force attacks. A developer might move the dashboard to a custom URL like /portal or /dashboard. If you see a 404 Not Found error, you just need to check the other indicators.
Look for the generator meta tag
WordPress likes to announce itself. By default, it injects a line of code into the head section of every page to declare the software version.
Open the page source again. Search for the word generator.
You are looking for a line of HTML that looks like this: <meta name="generator" content="WordPress 6.x">.
This tag tells you the platform and the exact version number they are running. It is a leftover feature from the early days of blogging. Many modern sites remove this line because broadcasting an outdated version number is a security risk. If you find it, the site is definitely WordPress. If you do not, keep looking.
Check the REST API endpoint
Modern versions of the platform ship with a built in REST API. This allows developers to pull data out of the database and use it in external applications. By default, this API is open and visible to the public.
You can test this by adding /wp-json/ to the end of the domain name.
If the site uses WordPress, the browser will load a plain text page filled with structured JSON data. It looks like a wall of code. This file describes the routes, namespaces and endpoints available on the server. You can read the official WordPress REST API documentation to understand how these routes are structured.
This is an incredibly strong signal. Even headless setups, where the front end is built with React or Vue, still rely on this endpoint to fetch content. The design might look nothing like a traditional blog, but the /wp-json/ directory proves the backend is WordPress.
Check for readme and license files
When you install the software, it drops a few static text files into the root directory. These files sit right next to the main index file.
Try adding /readme.html to the domain. This file contains the standard WordPress installation instructions.
You can also try /license.txt. This file contains the standard public license text.
Most managed hosting providers delete these files automatically during setup. Security plugins also block access to them. If they do load, they are absolute proof of the underlying software.
Test core files for a 403 Forbidden response
Sometimes a site hides all the obvious clues. The owner might use a security plugin to block the login page, strip the meta tags and disable the REST API. You can still find out what they are running by testing how the server responds to specific file requests.
WordPress relies on a file called admin-ajax.php to handle dynamic requests. This file lives inside the wp-admin folder.
Type /wp-admin/admin-ajax.php into your address bar.
If the site is not WordPress, the server will look for that file, fail to find it, and return a standard 404 Not Found error.
If the site is WordPress, the file exists. Because you are trying to access a core system file without sending any data, the server will block you. It will return a blank white screen with a single line of text, or a 403 Forbidden error. A 403 error means the file is sitting exactly where you expect it to be.
You can also test /wp-includes/js/jquery/jquery.js. If you get a script file or a 403 error instead of a 404, the directory structure matches WordPress.
Inspect the browser cookies
Websites leave small text files in your browser to remember your session. WordPress uses specific naming conventions for its cookies.
You can view these in Google Chrome:
- Right click the page and select Inspect.
- Click the Application tab at the top of the developer tools panel.
- Look at the left sidebar and expand the Cookies menu.
- Click on the domain name.
Look at the list of cookie names. If you see wordpress_test_cookie, wordpress_logged_in_, or wp-settings-time, the site is running on the platform. These cookies handle user sessions and interface preferences. Even if the front end is heavily cached, these cookies often slip through.
Use a browser extension
If you find yourself checking sites frequently, you can install a browser extension to do the heavy lifting. Wappalyzer is a free tool that identifies the technology stack of any website you visit.
Once installed, you just click the icon in your toolbar. It drops down a menu showing the content management system, the analytics tools, the payment processors and the server software. It will tell you if the site uses WordPress and often identifies the specific version.
Extensions work by running all the manual checks listed above simultaneously. They scan the source code for wp-content, check the headers and look for specific JavaScript objects like wpApiSettings.
Look for body classes in the HTML
WordPress themes use a standard set of CSS classes to style the page. The system injects these classes directly into the opening body tag of the HTML document.
Open the developer tools by right clicking and selecting Inspect. Look at the very top of the HTML structure for the body tag.
A typical WordPress site will feature a long list of classes inside this tag. You might see terms like page-template-default or wp-custom-logo. These specific hyphenated names are generated by the core software. If you see them clustered together in the body tag, you are looking at a WordPress theme.
Why some sites hide their platform
You might run all these checks and find nothing. The site might load fast, look incredible, and show zero signs of wp-content or the REST API.
This usually means one of two things.
First, the site might be built on a completely different platform. The internet is full of alternatives. Shopify rules the ecommerce space. Wix and Squarespace power millions of small business sites. Developers use Ghost for publishing, Joomla for complex portals, or raw HTML and Node JS for custom web applications. If you suspect they use a different builder, you can learn how to tell what software a website is built with using similar methods.
Second, the site might be a custom headless build. In a headless setup, WordPress is only used as a private database. The front end is built entirely separately using a modern JavaScript framework. The public never interacts with the WordPress server directly. There is no wp-content folder on the live site, no login page and no cookies.
If you are trying to replicate a fast, highly custom design that hides its tracks perfectly, you are looking at a serious development project. You cannot achieve that level of performance and security with a cheap theme. You have to build it from the ground up, often rebuilding it as a proper mobile site with a custom architecture.
Combine your findings
No single check is flawless. A security plugin can hide the generator tag. A custom configuration can rename the wp-content folder. A caching network can strip the HTTP headers.
To get a definitive answer, you have to look at the whole picture. Try the /wp-json/ endpoint. Search the source code for wp-includes. Test the admin-ajax.php file for a 403 response. If two or three of these indicators point to WordPress, you can be certain of the platform.
Once you know the system, you can start digging into the specific themes and plugins they use to achieve their results. You can read their sitemap, check their URL structures and map out exactly how they built their presence. Knowing how to know if a website is built with WordPress is your starting point. The rest is just reverse engineering. If you decide to move your own platform over, reviewing standard pricing for migrations will help you plan the next step.