WordPress vs custom sites: what VibeScan checks differently

Not every website is the same under the hood. A WordPress blog, a Webflow export, and a Next.js app on Vercel all fail in different ways.

WordPress & popular CMS paths

When we detect WordPress, Drupal, Joomla, or similar platforms, we lean into CMS-specific checks:

• Public wp-admin and login exposure
• Version and plugin fingerprints from public assets
• xmlrpc.php, readme files, and common leak paths
• Directory listings under /wp-content/uploads

CMS sites are attacked by bots 24/7. You don't need to be a target—just online.

Static & marketing sites

Even "just a landing page" gets checked for:

• DNS and domain health
• SSL/TLS grade
• Security headers (HSTS, CSP, X-Frame-Options)
• Email authentication (SPF, DMARC) if you send mail from the domain
• Exposed .env, backup files, and git folders

Vibe-coded apps (React, Next, etc.)

Modern apps often hide issues behind client-side routing:

• API routes discovered from JavaScript bundles
• CORS misconfigurations
• Cookies without Secure/HttpOnly flags
• SSRF-prone URL fetch features
• Forms across multiple pages (we crawl up to ~50 pages)

Same scan, different emphasis

VibeScan's ONLY_WEBSITE mode runs a broad catalog—identity, DNS, TLS, headers, exposure, CMS, OWASP surface, email, performance, and risk scoring.

Fingerprinting tells us which checks matter most for your stack. You see grouped results: Identity & Domain, HTTP & Headers, CMS & Applications, OWASP & Input Surface—not a flat dump of 1,000 lines.

Practical takeaway

Whether you clicked "Publish" in a no-code builder or merged a PR at 2 a.m., run one scan per environment. Compare staging vs production. Fix what fails on production before you announce.