Wondering how to check if a website is WordPress? You’re not alone. Whether you’re a marketer planning a campaign, an SEO specialist evaluating technical constraints, or a developer scoping an integration, determining a site’s CMS quickly can save hours. With WordPress powering a significant share of the web—W3Techs reports WordPress is used by around 43% of all websites and over 63% of sites using a CMS (W3Techs, 2024)—the odds are high that the site you’re evaluating might be running on it. In this comprehensive Watsspace Digital Marketing Blog guide, you’ll learn practical, reliable methods to identify WordPress, from fast visual cues to definitive technical checks and smart workarounds for sites that try to hide their stack.

Why you might need to know if a website runs WordPress

Identifying the CMS behind a site is more than curiosity—it informs strategy and execution. Here’s why it matters:

SEO planning: Knowing it’s WordPress helps you anticipate how URLs, schema, sitemaps, canonical tags, and robots rules are typically handled, and which plugins might be in play.
Marketing operations: If you’re building landing pages or integrating forms, WordPress compatibility can influence tool selection and implementation timelines.
Sales qualification: Agencies and SaaS vendors often tailor pitches and demos by CMS. A quick CMS check enables better outreach and personalization.
Content workflows: WordPress conventions (like the Media Library and block editor) shape how teams collaborate, publish, and optimize content.
Security and compliance: If it’s WordPress, you’ll evaluate plugin inventories, update cadences, and potential REST API exposures differently.

Quick checks anyone can do in 60 seconds

Before diving into developer tools, try these fast and non-intrusive checks to tell if a site is WordPress.

Look at the URL structure for WordPress fingerprints

Media uploads path: Right-click an image and copy its address. If you see a path like /wp-content/uploads/2025/09/filename.jpg, that’s a strong WordPress signal.
Login endpoints: Append /wp-login.php or /wp-admin/ to the domain. Hitting a WordPress-style login screen is a strong indicator. Note: Many sites hide or redirect these paths.
Category and tag bases: URLs that include /category/ or /tag/ are common defaults in WordPress, though these are customizable.
Permalink query parameter: Some older or default setups use ?p=123 style post IDs—another hint.

Check page source for WordPress assets

Open the site, right-click, and choose “View page source.” Then search (Ctrl/Cmd+F) for these markers:

wp-content or wp-includes references in CSS/JS or image paths.
wp-block-library styles or references to Gutenberg blocks, which often appear as CSS classes like wp-block- in the HTML and CSS.
wp-emoji-release.min.js, wp-embed.min.js, or other default WordPress scripts.
The generator meta tag that mentions WordPress. Many sites remove it, but if present, it’s definitive.
A link tag with rel=”https://api.w.org/”, which indicates the WordPress REST API is available.

Inspect a few image files

Open images in new tabs and look at the path. WordPress commonly stores media in year/month folders under /wp-content/uploads/.
If you see /uploads/ without wp-content, the site could be a customized WordPress (e.g., Bedrock) or another CMS. Combine this with other checks.

Try the RSS feed

Add /feed/ to the site’s root URL. A working RSS feed with familiar WordPress feed structure (and often a generator note) is a strong indicator.
Check /comments/feed/ too—comments feeds are a WordPress hallmark.

Definitive technical checks for identifying WordPress

These checks are more conclusive and particularly useful when a site tries to hide common WordPress artifacts.

Call the WordPress REST API

Visit /wp-json/. A WordPress site with the REST API enabled will return JSON at this endpoint.
Look for keys such as name, description, and especially routes and namespaces including wp/v2. That’s definitive WordPress.
If /wp-json/ returns a 404, try /?rest_route=/. Some setups rewrite to this internal route.
Go deeper: /wp-json/wp/v2/posts or /wp-json/wp/v2/pages often returns paginated post data if public. If protected, you may still receive headers revealing WordPress-specific info.

Command-line example (safe and light): curl -s https://example.com/wp-json/ | head. If you see JSON with wp/v2 namespaces, you’ve confirmed it.

Check HTTP response headers

Use a header-only request to keep it unobtrusive: curl -I https://example.com

x-redirect-by: WordPress sometimes appears during redirections (such as non-www to www).
link headers pointing to the REST API (look for rel=”https://api.w.org/”).
set-cookie values like wordpress_logged_in_*, wp-settings-*, or wordpress_sec_* after you log in (not visible to outsiders unless authenticated or during comments).
x-wp-prefixed headers on API calls, such as x-wp-total and x-wp-totalpages, when calling /wp-json/wp/v2/posts.

Test XML-RPC

Visit /xmlrpc.php. Many WordPress sites return a message similar to “XML-RPC server accepts POST requests.”
Note: XML-RPC is commonly disabled for security, so a denial doesn’t rule out WordPress.

/wp-login.php and /wp-admin/ are common. Be respectful—don’t attempt to authenticate; you’re just checking for a distinctive WordPress login page design or redirect behavior.
Some sites obfuscate login paths with security plugins, e.g., moving login to /login/. If /wp-admin/ redirects to a different login path, it still indicates WordPress.

Look for readme and license files

Check /readme.html. If present, it mentions WordPress. Many admins remove it, so absence isn’t conclusive.
Some sites expose /license.txt with WordPress references.

Using third-party “WordPress detector” tools and extensions

Third-party detectors can accelerate identification, but you should understand how they work and their limitations.

BuiltWith and Wappalyzer: Recognize CMS, analytics, CDNs, and more by analyzing responses, headers, and asset patterns. They’re strong at recognition but can be fooled by obfuscation or heavy caching.
WhatRuns and similar browser extensions: Instant CMS detection in the toolbar. Convenient for quick checks during research.
IsItWP: Specifically focused on detecting WordPress indicators. Useful, but manual verification via REST API and source checks remains advisable.

Tip: If a detector shows conflicting results, confirm manually via /wp-json/, source references to wp-content, and response headers. That triangulation is rarely wrong.

Signs of headless or heavily customized WordPress

Some sites use WordPress purely as a content backend, rendering the public site via a framework like Next.js, Gatsby, or Nuxt. In these cases, the usual front-end markers may be absent.

Headless WordPress telltales

REST API usage: /wp-json/ exists even if you can’t find wp-content in source. Check /wp-json/wp/v2/posts and /wp-json/wp/v2/pages.
Link headers: The main HTML response might include a link header referencing the API with rel=”https://api.w.org/”.
Content editing clues: Preview URLs may include parameters like ?preview=true and _thumbnail_id in admin links, which sometimes leak into page code or Open Graph tags.
GraphQL endpoint: If the site runs WPGraphQL, /graphql might exist. That alone doesn’t prove WordPress, but combined with other hints it’s suggestive.

Custom file structures and hardened setups

Roots/Bedrock: May replace wp-content with app or move WordPress core to a subdirectory. The REST API remains the strongest clue.
Security plugins: They can hide the generator meta, change login paths, and block direct access to typical files. Try API, headers, RSS feeds, and image paths to corroborate.
CDN and static caching: Heavy caching can rewrite asset URLs (e.g., to a CDN). Even then, you might notice references to original WordPress file names (e.g., wp-embed.min.js) in request maps or source maps.

WordPress.com vs self-hosted WordPress.org

Not all WordPress sites are the same. WordPress.com (a hosted platform by Automattic) and self-hosted WordPress.org installations behave differently in subtle ways.

How to identify WordPress.com sites

Asset hosts: You may see assets from domains associated with WordPress.com’s infrastructure (for example, references to wp.com static assets or stats).
Login flow: Admin or login requests often route through WordPress.com’s authentication experience rather than a standard self-hosted login form.
Jetpack indicators: WordPress.com and self-hosted sites using Jetpack can exhibit similar analytics and image CDN signals. Combine with other markers to be sure.

Self-hosted WordPress clues

Custom server headers: Host-specific headers or configurations (e.g., nginx, Apache) coupled with WordPress signals.
Theme and plugin assets: Paths like /wp-content/themes/ and /wp-content/plugins/ are commonplace unless hidden.
Unique login: A familiar WordPress login screen at /wp-login.php or a branded custom login page that still references WordPress scripts.

WordPress multisite and enterprise implementations

Large organizations often use WordPress Multisite for networked publishing or enterprise content hubs.

Multisite signals

Signup and network admin: /wp-signup.php or /wp-admin/network/ endpoints might be accessible or redirect correctly.
Subdomain or subdirectory patterns: A network may run sites at site.example.com or example.com/site/. Combine with API checks per sub-site.
mu-plugins hints: Source references to mu-plugins (must-use plugins) in asset paths can indicate enterprise-level tooling.

When checks fail: dealing with obfuscation and false negatives

Some sites work hard to hide their stack. Here’s how to proceed without intrusive scanning.

Fallback to API: Even hardened sites often expose the REST API for functionality. Try /wp-json/, /?rest_route=/, and specific routes like /wp-json/wp/v2/types or /wp-json/wp/v2/categories.
Examine caching behavior: Trigger a benign redirect (e.g., adding a trailing slash or uppercase path) and check headers for x-redirect-by: WordPress.
Check RSS variants: /feed/, /tag/keyword/feed/, or /category/topic/feed/ often reveal WordPress structure.
Look at embedded content: oEmbed scripts and wp-embed references are common in WordPress.
Cross-check subpaths: The root may be non-WordPress, but a subdirectory like /blog/ or /news/ could be WordPress. Run checks on those paths too.

Ethical, safe, and legal considerations

Responsible reconnaissance protects you, your client, and the site owner.

Minimal requests: Use HEAD (curl -I) and single GETs to known endpoints. Avoid aggressive scanning or brute force.
Respect robots and rate limits: While robots.txt doesn’t govern humans, it’s a good signpost for respectful behavior.
Don’t probe authentication: Never attempt to log in or exploit vulnerabilities. Your goal is identification, not penetration testing.
Follow terms of service: Ensure your checks comply with the site’s TOS and legal guidelines in your jurisdiction.

Step-by-step checklist: how to check if a website is WordPress

Use this concise process to go from “maybe” to “confirmed” in minutes.

Open the homepage and view the page source. Search for wp-content, wp-includes, wp-block-library, or wp-embed. If found, it’s likely WordPress.
Try the REST API: visit /wp-json/. If you get JSON with wp/v2 namespaces, you’ve confirmed WordPress.
If /wp-json/ fails, try /?rest_route=/. Some servers rewrite to this internal route.
Check /wp-login.php or /wp-admin/ for the login screen. Don’t attempt to authenticate; you’re only confirming presence.
Test /feed/ and /comments/feed/ to see if WordPress-style feeds are present.
Send a header-only request (curl -I https://example.com) and look for x-redirect-by: WordPress or link headers referencing https://api.w.org/.
Check image paths for /wp-content/uploads/YYYY/MM/ structure.
Use a detector (BuiltWith, Wappalyzer) to corroborate your findings, especially on heavily cached sites.
Inspect subdirectories like /blog/ or /news/ if the root shows no signals; many brands host their blog on WordPress while the main site runs a different stack.
Document your conclusion and evidence (e.g., REST API response, asset paths) for stakeholders.

Troubleshooting matrix: signals, reliability, and caveats

Use the following table to interpret signals and understand when they may fail.

Signal: /wp-json/ returns JSON | Where to check: https://example.com/wp-json/ | Reliability: Very High | How: Visit or curl the endpoint | May fail when: REST API disabled or firewalled

Signal: link header rel=”https://api.w.org/” | Where to check: Response headers | Reliability: High | How: curl -I | May fail when: Headers stripped by proxy/CDN

Signal: wp-content or wp-includes in page source | Where to check: View source | Reliability: High | How: Search for strings | May fail when: Headless or asset paths rewritten

Signal: wp-block- classes and wp-block-library CSS | Where to check: Source/Stylesheets | Reliability: High | How: Inspect CSS and DOM | May fail when: Custom themes or CSS inlining removes names

Signal: /wp-login.php or /wp-admin/ shows login | Where to check: Login paths | Reliability: Medium | How: Visit path only | May fail when: Login path is hidden or customized

Signal: /xmlrpc.php message | Where to check: XML-RPC endpoint | Reliability: Medium | How: Visit endpoint | May fail when: XML-RPC disabled (common)

Signal: /feed/ returns WordPress-style RSS | Where to check: RSS endpoints | Reliability: Medium-High | How: Visit /feed/ | May fail when: Feeds disabled or proxied

Signal: x-redirect-by: WordPress | Where to check: Redirect headers | Reliability: Medium | How: curl -I (on redirect) | May fail when: Reverse proxies rewrite headers

Signal: readme.html mentions WordPress | Where to check: /readme.html | Reliability: High if present | How: Visit file | May fail when: File removed (best practice)

Signal: wp-emoji-release.min.js or wp-embed.min.js | Where to check: Source scripts | Reliability: High | How: View source | May fail when: Scripts dequeued or bundled

Authoritative usage statistics to frame your detection strategy

Understanding the prevalence of WordPress helps you prioritize this detection in your workflows:

W3Techs (2024): WordPress powers about 43% of all websites and over 63% of sites that use a CMS. This makes WordPress the dominant platform on the web, far ahead of other CMSs.
BuiltWith (2024): Reports consistently rank WordPress among the top technologies across the top million sites. While exact counts vary over time, the trend confirms WordPress’s dominant presence among both SMB and enterprise websites.

Practical takeaway: Since a large share of sites rely on WordPress, building a reliable, fast CMS identification habit pays dividends across SEO audits, lead qualification, and technical planning.

Common lookalikes and how to avoid misidentification

Some CMSs and static site setups exhibit patterns similar to WordPress. Avoid false positives by cross-checking these details.

Joomla/Drupal: They may have RSS feeds and category-like structures, but they won’t expose WordPress’s REST API namespaces (wp/v2) or WordPress-specific scripts.
Static sites with blog folders: A site might mimic WordPress URL structures without the back end. Check /wp-json/ and asset paths to confirm.
Custom frameworks: A custom app could deliberately copy WordPress conventions. The REST API route and WordPress header behaviors remain reliable differentiators.

Browser developer tools: a practical CMS discovery workflow

When source checks aren’t obvious, your browser’s DevTools can quickly reveal hidden clues.

Network tab: Reload the page with DevTools open. Filter for requests containing wp- or wp-content. Look for preloads, fonts, or CSS referencing WordPress assets.
Headers panel: Inspect the main document’s response headers for link rel=”https://api.w.org/”. Also check for redirection headers like x-redirect-by.
Sources panel: Expand the domain and any CDNs to see file names. Even if minified or bundled, you might spot wp-emoji or wp-embed.
Application panel: Cookies like wp-settings-* and wordpress_logged_in_* appear only after authentication, but public cookies may reference WordPress when comments or sessions are used.

Real-world scenarios and decision-making

Below are practical examples of how to combine signals for a confident decision.

Scenario: Marketing qualification call in 5 minutes
- Check /wp-json/, /wp-admin/, and the page source for wp-content. If two signals confirm, prepare a WordPress-ready pitch.
Scenario: SEO site audit kickoff
- Confirm via REST API and source assets. Then list plugins/themes you can infer (e.g., WooCommerce classes, Yoast-generated meta tags without angle brackets). Tailor your audit checklist accordingly.
Scenario: Enterprise headless marketing site
- No wp-content in source; heavy CDN. The API /wp-json/ is present and returns wp/v2 routes. Classify as headless WordPress and plan content operations integration via REST API.
Scenario: Obscured by security plugin
- /wp-admin/ shows 404; generator tag hidden; feeds disabled. A header-only request on a forced redirect reveals x-redirect-by: WordPress. Combine with an RSS check on a subpath like /blog/feed/ to confirm.

Advanced techniques for analysts and developers

If standard checks are inconclusive, these advanced techniques can help—use responsibly.

Compare sitemaps and API: If /sitemap.xml references typical WordPress taxonomies (categories, tags) and /wp-json/ works, you’ve double-confirmed.
Check canonical and Open Graph tags: Some SEO plugins write distinctive patterns in title, meta description, and Open Graph structures. While not definitive, these hints help.
Probe for specific REST endpoints: /wp-json/wp/v2/types, /wp-json/wp/v2/tags, or /wp-json/wp/v2/media return predictable structures if public.
Observe redirect behavior: The way a site handles trailing slashes or uppercase/lowercase paths can reveal WordPress’s redirect fingerprints in headers.

Frequently asked questions about identifying WordPress

Can a WordPress site hide every indicator?

It’s hard to hide everything without breaking functionality. A site can remove the generator tag, block wp-content, and move the login path, but the REST API, RSS feeds, or redirect headers often remain detectable. Truly headless setups still typically expose /wp-json/ unless they proxy or firewall it.

What if only the blog is WordPress?

That’s common. The root site may be custom or on another CMS, while /blog/ or /news/ runs WordPress. Run your checks on those subpaths to confirm.

Does WooCommerce change detection?

WooCommerce adds predictable classes and URLs (e.g., /cart/, /checkout/, woocommerce classes). It strengthens, not weakens, WordPress detection.

Is WordPress.com easier to detect?

Yes and no. Some WordPress.com configurations leave clear asset and analytics markers. Others are indistinguishable from self-hosted at a glance. REST API checks and login flows are your best clues.

Will CDNs break detection?

CDNs can rewrite asset URLs and strip headers, but they rarely mask all signals. The REST API and internal content structures typically remain intact.

Tools and commands summary for quick verification

Check REST API: Open /wp-json/ in a browser or run curl -s https://example.com/wp-json/.
Check headers: curl -I https://example.com and look for link rel=”https://api.w.org/” or x-redirect-by: WordPress.
View source: Search for wp-content, wp-includes, wp-embed, wp-block.
Try RSS: Visit /feed/ or /comments/feed/.
Login endpoints: Visit /wp-login.php or /wp-admin/ without attempting to authenticate.
Third-party detectors: Use BuiltWith, Wappalyzer, WhatRuns, and IsItWP as corroborative tools.

What to do next if the site is WordPress

Once you’ve identified WordPress, align your plan with platform-specific best practices.

SEO upgrades: Audit permalink structure, schema, XML sitemaps, canonical tags, and page speed. Plan plugin choices (e.g., a trusted SEO plugin) and technical hardening.
Performance: Recommend caching layers, image optimization, and a CDN. Evaluate theme performance and unused plugin bloat.
Security: Encourage update hygiene for core, themes, and plugins; implement a web application firewall; review user roles; and ensure backups.
Content workflow: Leverage the block editor’s reusable blocks and patterns. Propose editorial governance with roles and scheduled publishing.
Integrations: Map out form handlers, CRM connections, analytics tracking, and marketing automation tools known to work well with WordPress.

Case-based heuristics: combining signals with context

Context matters. Here’s how to synthesize clues under different constraints.

Time-constrained research: Prioritize /wp-json/ and page source search for wp-content. If either confirms, proceed with WordPress-tailored planning.
Security-aware brands: Expect hidden generator tags and custom login paths. Focus on REST API, RSS feeds, and header-level clues.
Heavily cached e-commerce: Look for WooCommerce fragments, cart and checkout endpoints, and the presence of REST API e-commerce routes through plugins.
Legacy builds: Older WordPress sites may still use ?p=ID permalinks or default /category/ and /tag/ paths—easy gives for CMS identification.

Building a repeatable internal SOP

If your team frequently evaluates sites, encode this process into a simple standard operating procedure:

Initial pass: REST API, page source markers, login path—collect 2–3 signals.
Corroboration: Headers and feeds; detector tools; check subdirectories.
Documentation: Save a screenshot of the REST API response and a snippet of source showing wp- markers for your CRM or audit file.
Edge cases: If inconclusive, log “possible headless” and note any link headers or API blocks observed.
Review: A second analyst validates findings for high-stakes engagements.

Common pitfalls and how to avoid them

Relying on a single signal: Always confirm with at least two independent signals, such as API plus source assets.
Confusing shared patterns: RSS feeds and category-like paths are not exclusive to WordPress. The WordPress REST API is your definitive differentiator.
Ignoring subpaths: Blogs often live under /blog/ or /news/. Test those paths.
Overprobing: Keep requests minimal and lawful; do not brute-force or scrape heavily.

A quick word on automation

For teams that assess dozens of websites each week, light automation can help while respecting boundaries.

Batch REST API checks: Programmatically request /wp-json/ for a list of domains, with rate limiting and retries. Log whether wp/v2 appears.
Header scans: Use HEAD requests to capture link and x-redirect-by without full downloads.
Human-in-the-loop: When automation returns “uncertain,” escalate to manual verification using DevTools.

Checklist recap: the fastest reliable route

Check /wp-json/ or /?rest_route=/.
Search source for wp-content, wp-includes, wp-embed, and wp-block.
Confirm via headers (link rel=”https://api.w.org/”, x-redirect-by: WordPress).
Validate via RSS feeds or login paths.
Corroborate with a detector tool if needed.

Benchmarking your identification accuracy

Use simple internal metrics to improve your team’s accuracy over time.

Precision/Recall on a labeled set: Maintain a small reference list of sites you know are WordPress or not. Test your process monthly and track false positives/negatives.
Time-to-decision: Measure how long it takes to confidently classify a site. Aim for under 3 minutes with practice.
Escalation rate: Track how often you need advanced checks. If this rises, refine your quick checks or training materials.

Putting it all together

Combine multiple lines of evidence for the strongest conclusion. The most reliable path is: REST API response, page source markers, and header-level clues. If those disagree, consider headless or hardened setups, test subpaths, and consult a detector tool. With practice, you’ll achieve near-instant confidence in your classification.

Conclusion: The fastest and most reliable way to check if a website is WordPress is to confirm via the REST API at /wp-json/, corroborate with source-level markers like wp-content or wp-block-library, and validate with headers or RSS feeds. Given WordPress’s dominant share of the web (W3Techs, 2024), developing a repeatable detection workflow is a high-value skill for marketers, SEOs, and developers. Use the step-by-step checklist above, be respectful and minimal in your requests, and document your evidence. With these best practices, you’ll identify WordPress sites quickly and confidently—and move on to the work that matters: planning, optimizing, and growing results.

Check out other posts

How to check if a website is WordPress