Supported Platforms and Technical Requirements for Your Audit

To generate an accurate, actionable report, the Brand Health Audit crawler must be able to discover, render, and evaluate your public-facing web pages in the same manner as modern search engines, AI retrieval agents, and real users. The Brand Health Audit, a platform created by The Branded Agency, evaluates brand positioning, messaging clarity, technical SEO, conversion friction, accessibility, and AI discoverability across modern web architectures.

Whether your website is hosted on a managed content management system (CMS) like WordPress, Webflow, or Shopify, or built as a custom headless single-page application (SPA), the underlying code must be accessible to automated discovery tools. If your site blocks automated visitors, requires password authentication, hides critical copy behind unrendered client-side scripts, or disallows access via server directives, the audit crawler cannot evaluate your brand signals accurately.

Supported Content Management Systems and Frameworks

The Brand Health Audit is platform-agnostic. Because our engine evaluates the rendered DOM (Document Object Model), raw HTML, network responses, and external entity footprints, it does not rely on CMS-specific plugins or server-side integrations.

Platform Type	Common Examples	Support Level	Technical Considerations
Traditional & Headless CMS	WordPress, Webflow, HubSpot, Ghost, Craft CMS	Fully Supported	Ensure caching plugins do not serve stale headers or block automated user agents.
E-commerce Platforms	Shopify, BigCommerce, Adobe Commerce (Magento)	Fully Supported	Ensure checkout flows do not trigger false-positive bot blocks on product and landing pages.
Modern JS Frameworks (SSR/SSG)	Next.js, Nuxt, Remix, Astro, Gatsby	Fully Supported	Recommended for SPAs; pre-rendered HTML guarantees complete messaging and metadata capture.
Client-Side SPAs	Pure React, Vue, or Angular applications	Supported (Conditional)	Dependent on client-side script execution; delayed API hydration can impact content scoring.
Closed & Staging Environments	Password-protected staging, internal intranets	Not Supported	Environments behind Basic Auth or IP whitelists cannot be crawled by public audit workers.

If you are curious about what data points are extracted across these architectures, review how it works to see the technical progression from crawl to scoring.

Core Technical Prerequisites

Before initiating an evaluation at /audit, ensure your infrastructure meets the following technical baseline. Failure to meet these criteria can lead to incomplete data collection, lower confidence ratings, or scan termination.

1. Public Accessibility and Firewall Rules

The target domain must resolve over standard HTTP/HTTPS protocols without requiring session cookies, basic authentication prompts, or CAPTCHA validation.

Enterprise firewalls and Web Application Firewalls (such as Cloudflare, AWS WAF, or Akamai) frequently flag automated crawling systems. If your security policy implements rate limiting, ensure that your infrastructure does not serve 403 Forbidden or 429 Too Many Requests responses when multiple page requests occur within a brief evaluation window.

2. Crawl Directives and Robots.txt Configuration

Our automated discovery engine respects standard web conventions. As outlined in Google's introduction to robots.txt, rules defined in your root directory govern how automated agents explore your site structure.

Ensure that your robots.txt file does not disallow the scanning of primary navigation paths, landing pages, or utility assets (such as CSS files and primary images) that are essential for evaluating visual hierarchy and design systems.

3. XML Sitemap Availability

To map your brand footprint comprehensively, the crawler checks for the presence of valid XML sitemaps declared in your robots.txt or standard root endpoints (/sitemap.xml). Sitemaps provide the discovery engine with a complete index of canonical pages, preventing orphaned yet critical landing pages from being omitted during evaluation.

4. Single-Page Application (SPA) Hydration

The audit uses a dynamic rendering engine capable of executing JavaScript, reading custom elements, and inspecting hydrated DOM nodes. However, if your application relies on asynchronous API calls that take several seconds to populate primary body text or heading structures, our crawler may capture a preliminary state. For client-rendered applications, ensuring rapid DOM hydration prevents messaging extraction failures.

Verifying Pre-Audit Readiness: A Step-by-Step Guide

To ensure your report captures an accurate picture of your brand health, execute this brief technical check before submitting your URL:

1. Test in a Clean Incognito Session: Open your primary URL in a private browser window without active login cookies. Confirm that all core navigation links, value proposition text, and proof points render immediately without password prompts.
2. Inspect HTTP Response Codes: Verify that your domain serves clean 200 OK responses across key pages. Avoid redirect chains (e.g., http:// to http://www. to https://www.) that waste crawl budget or introduce latency.
3. Verify Asset Delivery: Check that your Content Delivery Network (CDN) allows the loading of stylesheets and font files to non-standard user agents, as layout metrics, contrast ratios, and typography drift directly affect your visual identity and accessibility scores.
4. Audit JavaScript Console Errors: Open browser developer tools and check the console. Fatal JavaScript errors that halt DOM execution will prevent dynamic scrapers and AI agents from discovering structured schema or text.

To understand how crawl issues impact your final scoring, explore our guide on how the Brand Health Score is calculated.

Technical Limitations and Platform Boundaries

While the Brand Health Audit is designed to provide comprehensive diagnostic clarity, certain structural boundaries apply:

• Authenticated Portals: The audit cannot log into gated customer portals, SaaS dashboards, or membership areas. It evaluates only public-facing brand, product, and marketing pages.
• Geographic Restrictions: If your website serves different content or blocks traffic based on visitor geography, the audit will reflect the experience of our primary processing nodes (predominantly North America and Western Europe).
• Intranet and Localhost Domains: Staging environments hosted locally (e.g., localhost or private internal DNS records) cannot be reached.
• Dynamic Variable Testing: The audit evaluates the live, rendered state of a site at the time of execution. It does not simulate bespoke multi-step user configuration journeys (such as interactive price calculators or multi-stage custom checkout flows).

If you need clarity on how our platform processes and retains technical crawl assets, consult our privacy and data policies.

Next Steps

Verifying your technical prerequisites ensures that your audit produces an accurate, high-confidence assessment of your brand health. Once your public endpoints are confirmed accessible, you can begin the diagnostic process.

Ready to inspect your site's brand, messaging, and technical visibility? Start your Brand Health Audit to receive your comprehensive score and prioritised remediation roadmap.

Frequently asked questions

Can the audit scan staging or password-protected websites?

No. The Brand Health Audit crawler operates as an external agent and cannot bypass Basic HTTP authentication, form logins, or IP-restricted staging environments. To audit a new build before launch, you must temporarily expose the staging environment to public traffic or run the audit immediately upon deploying to production.

How does the crawler handle JavaScript-heavy websites?

The platform uses dynamic headless browser rendering to execute client-side JavaScript, capture hydrated DOM states, and inspect client-rendered elements. However, if an application exhibits extreme rendering latency or network delays during API hydration, static pre-rendering (SSR or SSG) is recommended to guarantee complete data capture.

Will the audit crawler impact website performance or trigger alerts?

The audit crawl is lightweight and rate-limited to avoid degrading server performance or skewing real-time user metrics. However, high-sensitivity Web Application Firewalls (WAFs) configured to block rapid sequential requests from automated agents may register the scan in security logs unless configured to allow the audit worker.

Does the audit support multi-language and international domains?

Yes. The platform can evaluate websites operating in multiple languages across international subdirectories or ccTLDs. The crawler evaluates the primary language declared in the HTML attributes and inspects localized metadata, hreflang tags, and regional navigation structures.

What should I do if my audit fails with a crawler error?

If an audit terminates prematurely or reports a connection error, verify that your domain does not enforce geo-blocking, CAPTCHA challenges, or rate-limiting rules against automated requests. Ensuring your robots.txt file permits crawling of primary directories will typically resolve discovery failures.

Sources

• Robots Exclusion Protocol (RFC 9309) — IETF. The official internet standards track specification for crawler directives.
• Introduction to robots.txt — Google Search Central. Technical guidance on how crawlers discover and interpret robots exclusion files.
• Sitemaps overview — Google Search Central. Explains XML sitemap protocols, discovery mechanisms, and indexing best practices.

Editor notes

• Double-checked that all internal links use the provided exact paths (/audit, /how-it-works, /privacy).
• Ensured no external links were used outside the supplied Source Catalogue (RFC 9309 and Google Search Central docs cited inline and in Sources).
• Inserted infographic prompt, alt text, and the exact markdown placeholder INFOGRAPHIC_SRC above the verification steps.