Digital Break Risk | Free version

fleshlight.eu

8/18/2026, 6:19:54 AM

9/9 tests performed · 8 issues reported

Critical 1High 1Low 6

Near-term: 20%Long-term: 33%

Risk Indicators Detected

This audit identified several risk indicators that may increase the website's exposure to operational, security, compliance-related, or reputational issues over time. Addressing these findings can help reduce avoidable exposure, strengthen customer trust, and lower the likelihood of future business disruption.

Security Risk Signals

Performance Risk Signals

Reputation Risk Signals

Digital Break Risk

Long-Term12 months

33% risk

Near-TermNext 30 days

20% risk

Digital Break Risk estimates the business exposure associated with the indicators identified during this audit. It highlights where improvements can help reduce risk and strengthen sales, trust, operations, and online growth.

Digital Break Risk (DBR) estimates the level of business exposure associated with the technical, operational, reputation, compliance-related, and performance indicators identified during this audit.

The findings are not definitive proof that something is failing, nor do they predict that a specific incident will occur. They highlight signals that, based on our experience, are worth reviewing because improving them can help reduce exposure, strengthen digital operations, and make the website more reliable for customers.

This index measures estimated business exposure, not overall website quality. A website may appear to work normally while still presenting indicators that can be improved to reduce future operational, reputational, or commercial risk.

It is expressed in two time horizons:

Near-Term (Next 30 days): estimated business exposure based on the current findings.
Long-Term (12 months): estimated evolution of business exposure if the identified findings remain unresolved.

The score is calculated from multiple observable indicators, including security configuration, performance signals, availability, domain reputation, email configuration, trust signals, and adherence to commonly accepted practices.

DBR provides a structured starting point for prioritising improvements. Expert review or a dedicated audit may be required to validate findings, rule out false positives, and identify issues that cannot be assessed through automated analysis.

Security Risk Signals

Performance Risk Signals

13%

Reputation Risk Signals

Security Risk Signals

Critical 0High 0Low 3

Long-Term12 months

4% risk

Near-TermNext 30 days

3% risk

Estimated business exposure linked to observable security signals. Highlights signals that can be improved to strengthen customer trust, reduce avoidable exposure, and support safer digital operations.

The Security Risk score evaluates how the website's observable security posture may contribute to overall business risk. It considers indicators such as encryption, security headers, server configuration, outdated protocols, and recognised security best practices.

These findings are not definitive evidence of a vulnerability, compromise, or data breach. They identify areas where, based on recognised practices and our experience, improvements can help strengthen the website's security posture, reduce avoidable exposure, and increase customer confidence.

For an online business, security improvements can support checkout trust, account protection, partner confidence, and operational continuity.

This assessment is based on automated analysis of externally observable information. Expert verification or a dedicated security audit may be required to validate the findings, rule out false positives, assess technical context, and identify risks that are not externally observable.

Business impact

Impact	Indicator
Low	headers-security › HSTS is present but its configuration provides incomplete HTTPS enforcement: max-age must be ≥ 31536000 (1 year) The website has partial HTTPS protection, but gaps in duration, scope or deployment may still leave avoidable insecure-access paths. This does not imply an active incident, but it weakens the security posture expected from a commercial website. WebsiteServer Solution: Review the current `Strict-Transport-Security` header and correct the weak directive. Recommended target: `Strict-Transport-Security: max-age=31536000; includeSubDomains` Check specifically: `max-age` should be long enough for production, typically at least `31536000` seconds. `max-age=0` disables HSTS and should not be used except for rollback. `includeSubDomains` should be enabled only after confirming all subdomains support HTTPS. The header must be sent consistently on HTTPS responses. HTTP should redirect permanently to HTTPS. Avoid enabling `preload` until the domain is operationally ready for long-term HTTPS-only enforcement.
Low	headers-security › No explicit Referrer Policy is configured to control how much URL information is shared when visitors navigate to external resources. External services may receive more referral information than necessary, including page paths or campaign context depending on browser behavior and destination. This creates unnecessary privacy and information-disclosure exposure. WebsiteServer Solution: Configure an explicit `Referrer-Policy` header. Recommended balanced option: `Referrer-Policy: strict-origin-when-cross-origin` Stricter option: `Referrer-Policy: no-referrer` Technical guidance: Use `strict-origin-when-cross-origin` for most commercial websites. Use `no-referrer` where maximum privacy is required. Avoid `unsafe-url`, because it can disclose full URLs to external destinations. Avoid placing sensitive data, tokens, emails or identifiers in URLs. Validate analytics, attribution and affiliate tracking before choosing a stricter policy.
Low	headers-security › No Permissions Policy is configured to restrict access to sensitive browser features and APIs. Browser capabilities such as camera, microphone, geolocation, payment or fullscreen may be available more broadly than required, especially to embedded third-party content. This increases unnecessary privacy and security exposure. WebsiteServer Solution: Define a `Permissions-Policy` header that disables unused browser features and only allows required capabilities. Example restrictive baseline: `Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), fullscreen=(self)` Adapt the policy to the site: Disable features not used by the website. Allow features only for `self` or specific trusted origins when required. Review embedded third-party content, including videos, maps, service widgets and marketing tools. Test user journeys that may require browser permissions. Document intentional exceptions. Common directives to review: `camera` `microphone` `geolocation` `payment` `usb` `fullscreen` `autoplay` `clipboard-read` `clipboard-write`
Info	headers-security › No active web application firewall or bot protection signal was detected from response headers or content This is not necessarily a problem: many legitimate sites operate without a dedicated WAF and rely on other controls. This check only looks for signals of an active protection mode (challenge pages, bot-management cookies). The site may still sit behind a CDN or proxy (e.g. Cloudflare, Sucuri) with WAF capabilities available but not actively challenging this request, which this passive check cannot confirm either way. WebsiteWAF
Info	info-exposure › No security.txt vulnerability reporting file detected The website does not publish a standard security contact file. This is not a vulnerability by itself, but it may make it harder for researchers or third parties to report security issues responsibly. In practice, this can delay remediation of problems that may affect customer trust, service availability, or business reputation. DomainWebsite Solution: Publish a `security.txt` file with a clear vulnerability reporting process. Recommended actions: Create the file at the standard location: `https://example.com/.well-known/security.txt` Include at least a valid contact method. Example: `Contact: mailto:security@example.com Preferred-Languages: en, es Canonical: https://example.com/.well-known/security.txt` Optional but recommended fields: `Policy: https://example.com/security-policy Acknowledgments: https://example.com/security-acknowledgments Expires: 2027-12-31T23:59:59Z` Make sure the contact mailbox is monitored. Define an internal triage process: Who receives the report Who validates the issue Expected response time Escalation path for critical vulnerabilities Criteria for coordinated disclosure Verify publication: `curl -I https://example.com/.well-known/security.txt curl https://example.com/.well-known/security.txt`

Low

headers-security › HSTS is present but its configuration provides incomplete HTTPS enforcement: max-age must be ≥ 31536000 (1 year)

The website has partial HTTPS protection, but gaps in duration, scope or deployment may still leave avoidable insecure-access paths. This does not imply an active incident, but it weakens the security posture expected from a commercial website.

WebsiteServer

Solution:

Review the current Strict-Transport-Security header and correct the weak directive.

Recommended target:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Check specifically:

max-age should be long enough for production, typically at least 31536000 seconds.
max-age=0 disables HSTS and should not be used except for rollback.
includeSubDomains should be enabled only after confirming all subdomains support HTTPS.
The header must be sent consistently on HTTPS responses.
HTTP should redirect permanently to HTTPS.
Avoid enabling preload until the domain is operationally ready for long-term HTTPS-only enforcement.

Low

headers-security › No explicit Referrer Policy is configured to control how much URL information is shared when visitors navigate to external resources.

External services may receive more referral information than necessary, including page paths or campaign context depending on browser behavior and destination. This creates unnecessary privacy and information-disclosure exposure.

WebsiteServer

Solution:

Configure an explicit Referrer-Policy header.

Recommended balanced option:

Referrer-Policy: strict-origin-when-cross-origin

Stricter option:

Referrer-Policy: no-referrer

Technical guidance:

Use strict-origin-when-cross-origin for most commercial websites.
Use no-referrer where maximum privacy is required.
Avoid unsafe-url, because it can disclose full URLs to external destinations.
Avoid placing sensitive data, tokens, emails or identifiers in URLs.
Validate analytics, attribution and affiliate tracking before choosing a stricter policy.

Low

headers-security › No Permissions Policy is configured to restrict access to sensitive browser features and APIs.

Browser capabilities such as camera, microphone, geolocation, payment or fullscreen may be available more broadly than required, especially to embedded third-party content. This increases unnecessary privacy and security exposure.

WebsiteServer

Solution:

Define a Permissions-Policy header that disables unused browser features and only allows required capabilities.

Example restrictive baseline:

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), fullscreen=(self)

Adapt the policy to the site:

Disable features not used by the website.
Allow features only for self or specific trusted origins when required.
Review embedded third-party content, including videos, maps, service widgets and marketing tools.
Test user journeys that may require browser permissions.
Document intentional exceptions.

Common directives to review:

camera
microphone
geolocation
payment
usb
fullscreen
autoplay
clipboard-read
clipboard-write

Info

headers-security › No active web application firewall or bot protection signal was detected from response headers or content

This is not necessarily a problem: many legitimate sites operate without a dedicated WAF and rely on other controls. This check only looks for signals of an active protection mode (challenge pages, bot-management cookies). The site may still sit behind a CDN or proxy (e.g. Cloudflare, Sucuri) with WAF capabilities available but not actively challenging this request, which this passive check cannot confirm either way.

WebsiteWAF

Info

info-exposure › No security.txt vulnerability reporting file detected

The website does not publish a standard security contact file. This is not a vulnerability by itself, but it may make it harder for researchers or third parties to report security issues responsibly. In practice, this can delay remediation of problems that may affect customer trust, service availability, or business reputation.

DomainWebsite

Solution:

Publish a security.txt file with a clear vulnerability reporting process.

Recommended actions:

Create the file at the standard location:

https://example.com/.well-known/security.txt

Include at least a valid contact method.

Example:

Contact: mailto:security@example.com
Preferred-Languages: en, es
Canonical: https://example.com/.well-known/security.txt

Optional but recommended fields:

Policy: https://example.com/security-policy
Acknowledgments: https://example.com/security-acknowledgments
Expires: 2027-12-31T23:59:59Z

Make sure the contact mailbox is monitored.
Define an internal triage process:
- Who receives the report
- Who validates the issue
- Expected response time
- Escalation path for critical vulnerabilities
- Criteria for coordinated disclosure

Verify publication:

curl -I https://example.com/.well-known/security.txt
curl https://example.com/.well-known/security.txt

Performance Risk Signals

Critical 1High 0Low 2

Long-Term12 months

23% risk

Near-TermNext 30 days

13% risk

Estimated business risk linked to the website's performance. Identifies speed and availability signals that may influence user experience, conversion, and campaign performance. Improving them can help support a faster, more reliable, and more consistent website experience.

The Performance Risk score evaluates how observable performance and availability indicators may affect responsiveness, reliability, user experience, and business continuity. It considers signals such as response times, infrastructure behaviour, loading performance, availability patterns, and recognised optimisation best practices.

These findings are not definitive proof that the website is slow, unstable, or losing sales. They identify areas where, based on common performance patterns and our experience, improvements can help create a faster, more reliable, and more consistent experience for visitors.

For an online business, performance improvements can support conversion, reduce abandonment, improve campaign efficiency, and help prevent technical issues from becoming visible to customers.

Actual performance depends on traffic volume, hosting conditions, third-party services, device types, geographic location, caching, and temporary network conditions. Manual analysis may be required to validate the results, rule out temporary anomalies, and identify the root cause of performance or availability issues.

Business impact

Restricted information

Some findings are hidden in this public report because they may include technical details that could facilitate abuse, competitor action, or unnecessary security and reputational exposure. Verify domain ownership to unlock the full report.

Impact	Indicator
Critical	Details are protected until domain ownership is verified to avoid exposing sensitive technical information publicly
Low	performance-basics › Short cache lifetime detected on static resources: max-age 300s Static resources expire quickly, so browsers may re-download files more often than necessary. This reduces the performance benefit of caching for repeat visitors and multi-page sessions. WebsiteServer Solution: Increase cache lifetime for versioned static assets. Recommended technical actions: Use longer `max-age` values for static files that include versioning or hashed filenames. Set at least: `Cache-Control: public, max-age=86400` Prefer longer caching for stable, versioned assets: `Cache-Control: public, max-age=31536000, immutable` Keep shorter cache times for HTML, API responses or assets that change without filename versioning. Confirm that deployment invalidates or renames assets when content changes. Re-test after changes using representative CSS, JavaScript, image and font files.
Low	asset-optimization › Mixed image format usage detected: 5 modern image(s) and 1056 JPEG/PNG/GIF image(s) Some detected images are still served in less efficient formats. This may increase page weight and slow visual loading, especially on mobile or slower connections. The real business impact depends on image size, compression, placement, and whether those images affect the initial loading experience. Website Solution: Progressively migrate the remaining images to modern formats, prioritizing the assets with the highest impact on initial loading. Technical recommendations: Identify the JPEG/PNG/GIF images with the largest transferred size. Prioritize above-the-fold images, hero images, banners, carousels, content images, and category images. Convert suitable images to WebP or AVIF while preserving equivalent visual quality. Use the `<picture>` element when fallback support is required: `<picture> <source srcset="/image.avif" type="image/avif"> <source srcset="/image.webp" type="image/webp"> <img src="/image.jpg" alt="Image description"> </picture>` If the site uses WordPress or another CMS/site platform, check whether the CMS, theme, optimization plugin, CDN, or image service supports automatic WebP/AVIF generation. Verify that the converted images are actually delivered in the final HTML or through the CDN, not only generated on the server. Keep PNG where it is technically justified, for example for complex transparency or specific graphic assets, but optimize file size. Review real displayed dimensions: avoid serving 2000 px images when they are displayed at 400 px. After migration, measure total page weight, LCP, and mobile loading behavior.
Info	asset-optimization › No recognizable CDN was detected for the static assets analyzed Not using a CDN is not necessarily a performance issue. A local website with moderate traffic and solid hosting may serve assets correctly without one. For websites with international traffic, high-volume campaigns, or frequent traffic spikes, a CDN can help make load times more stable. WebsiteCDN
Info	asset-optimization › No external web font providers were detected The analyzed page does not appear to depend on external font services. This removes one possible third-party dependency from the initial loading path and does not require additional resource hints for external fonts. Website

Restricted information

Critical

Details are protected until domain ownership is verified to avoid exposing sensitive technical information publicly

Low

performance-basics › Short cache lifetime detected on static resources: max-age 300s

Static resources expire quickly, so browsers may re-download files more often than necessary. This reduces the performance benefit of caching for repeat visitors and multi-page sessions.

WebsiteServer

Solution:

Increase cache lifetime for versioned static assets.

Recommended technical actions:

Use longer max-age values for static files that include versioning or hashed filenames.
Set at least:

Cache-Control: public, max-age=86400
Prefer longer caching for stable, versioned assets:

Cache-Control: public, max-age=31536000, immutable
Keep shorter cache times for HTML, API responses or assets that change without filename versioning.
Confirm that deployment invalidates or renames assets when content changes.
Re-test after changes using representative CSS, JavaScript, image and font files.

Low

asset-optimization › Mixed image format usage detected: 5 modern image(s) and 1056 JPEG/PNG/GIF image(s)

Some detected images are still served in less efficient formats. This may increase page weight and slow visual loading, especially on mobile or slower connections. The real business impact depends on image size, compression, placement, and whether those images affect the initial loading experience.

Website

Solution:

Progressively migrate the remaining images to modern formats, prioritizing the assets with the highest impact on initial loading.

Technical recommendations:

Identify the JPEG/PNG/GIF images with the largest transferred size.
Prioritize above-the-fold images, hero images, banners, carousels, content images, and category images.
Convert suitable images to WebP or AVIF while preserving equivalent visual quality.

Use the <picture> element when fallback support is required:

<picture>
  <source srcset="/image.avif" type="image/avif">
  <source srcset="/image.webp" type="image/webp">
  <img src="/image.jpg" alt="Image description">
</picture>

If the site uses WordPress or another CMS/site platform, check whether the CMS, theme, optimization plugin, CDN, or image service supports automatic WebP/AVIF generation.
Verify that the converted images are actually delivered in the final HTML or through the CDN, not only generated on the server.
Keep PNG where it is technically justified, for example for complex transparency or specific graphic assets, but optimize file size.
Review real displayed dimensions: avoid serving 2000 px images when they are displayed at 400 px.
After migration, measure total page weight, LCP, and mobile loading behavior.

Info

asset-optimization › No recognizable CDN was detected for the static assets analyzed

Not using a CDN is not necessarily a performance issue. A local website with moderate traffic and solid hosting may serve assets correctly without one. For websites with international traffic, high-volume campaigns, or frequent traffic spikes, a CDN can help make load times more stable.

WebsiteCDN

Info

asset-optimization › No external web font providers were detected

The analyzed page does not appear to depend on external font services. This removes one possible third-party dependency from the initial loading path and does not require additional resource hints for external fonts.

Website

Reputation Risk Signals

Critical 0High 1Low 1

Long-Term12 months

10% risk

Near-TermNext 30 days

5% risk

Estimated business exposure linked to observable trust and reputation signals. Identifies trust, email, and reputation signals that may influence customer confidence, brand credibility, and commercial perception. Improving them can help reduce avoidable friction and support a more trustworthy buying experience.

The Reputation Risk score evaluates how publicly observable trust signals may affect customer confidence, digital reputation, email deliverability, commercial perception, and compliance-related exposure. It considers indicators such as email authentication, blacklist status, domain reputation, and other recognised trust signals.

These findings are not definitive evidence of legal non-compliance, reputational damage, or business loss. They identify areas where, based on recognised trust practices and our experience, improvements can help strengthen credibility, reduce friction, and make the website more trustworthy for customers, partners, and prospects.

For an online business, reputation improvements can support email delivery, customer confidence, brand perception, and the overall credibility of the buying experience.

Legal, compliance, or technical verification may be required to validate the findings, rule out false positives, and determine their actual business impact.

Business impact

Restricted information

Impact	Indicator
High	Details are protected until domain ownership is verified to avoid exposing sensitive technical information publicly
Low	accessibility-basics › 3 of 193 image(s) are missing an alt attribute Images without alternative text are announced as generic or unlabelled by screen readers, making the content harder to understand for users with visual impairments. This is a common and low-effort accessibility gap. WebsiteAccessibility Solution: Add a descriptive alt attribute to every content image. Recommended implementation: `<img src="content-image.jpg" alt="Person speaking at a workshop">` Technical checks: Describe the image content or purpose concisely; avoid generic text such as "image" or "photo". Use `alt=""` (empty, not missing) for purely decorative images so screen readers skip them. Do not stuff alt text with keywords for SEO purposes. Re-test after deployment using a screen reader or accessibility browser extension.
Info	seo-basics › 2 <h1> headings detected on the analysed page Multiple H1 headings are not always a critical SEO problem, but they can make the page structure less clear and may reveal a template issue. On commercial pages, this can weaken the clarity of the main message and make technical review advisable. WebsiteSEO Solution: Review the heading structure and confirm whether multiple `<h1>` elements are intentional. Recommended technical actions: Identify where each `<h1>` is generated: theme, CMS field, hero block, content component, header component or third-party widget. Keep one primary `<h1>` for the main page topic where possible. Convert secondary headings to `<h2>` or `<h3>` when they represent sections, blocks or supporting content. Ensure hidden, duplicated or responsive-only headings are not creating repeated H1s. Preserve a logical heading hierarchy for accessibility and document structure. Re-test key page templates after the change.
Info	seo-basics › Incomplete Open Graph metadata detected (missing: og:image) When Open Graph metadata is incomplete, social platforms and messaging apps may generate fallback previews. This can produce inconsistent titles, weak descriptions or unattractive images when users share the page. WebsiteSEO Solution: Complete the missing Open Graph tags inside the document `<head>`. Recommended implementation: `<meta property="og:title" content="Page title for social sharing"> <meta property="og:description" content="Short, compelling description for social sharing"> <meta property="og:image" content="https://example.com/path/to/image.jpg">` Technical checks: Use an absolute URL for `og:image`. Recommended image size: at least 1200x630 px. Ensure the image URL returns HTTP `200`. Ensure the image is crawlable and not blocked by authentication or robots rules. Keep `og:title` and `og:description` aligned with the visible page content. Use page-specific values for content pages, categories and landing pages. Ensure the tags are present in the initial HTML response. Test previews in major social and messaging platforms after deployment.
Info	accessibility-basics › 14 of 442 link(s) or button(s) have no accessible text Links or buttons with no visible text, aria-label or title are announced as empty or generic by screen readers (for example, just \"link\" or \"button\"), making them unusable for assistive technology users. This is common in icon-only buttons and image links. WebsiteAccessibility Solution: Provide an accessible name for every interactive link and button. Recommended implementation: `<a href="/account" aria-label="View account"> <svg aria-hidden="true">...</svg> </a> <button aria-label="Close dialog">×</button>` Technical checks: Prefer visible text content over aria-label when possible. For icon-only controls, add `aria-label` or visually hidden text. Ensure decorative icons inside the control use `aria-hidden="true"`. Avoid generic labels such as "click here" or "read more" without context. Re-test with a screen reader or accessibility browser extension.
Info	dns-email-reputation › No validated DNSSEC delegation was found for the domain: No DS records in the parent zone DNS responses for this domain cannot be cryptographically validated, leaving some exposure to DNS spoofing or cache poisoning in vulnerable network paths. This is a common configuration across the web and is rarely a critical issue on its own, but enabling DNSSEC adds a meaningful layer of trust for domains handling logins or sensitive customer data. DomainDNS Solution: Enable DNSSEC signing for the domain. Recommended technical actions: Confirm DNSSEC support with the current DNS hosting provider or registrar. Enable DNSSEC signing on the authoritative DNS zone. Publish the resulting DS record with the domain registrar so the parent zone can delegate trust. Verify propagation and validate the chain of trust with an external DNSSEC validation tool. Monitor key rotation schedules if the provider does not automate them.
Info	legal-compliance › Known tracking services detected: Google Analytics / GA4, Google Tag Manager, Shopify Analytics / Marketing, Zendesk Chat, Mailchimp, Klaviyo These services are commonly used for analytics, advertising, attribution, personalisation or behaviour measurement. This indicator is informational; privacy and compliance impact depends on the service purpose, configuration, consent behaviour, data sharing model and applicable jurisdiction. WebsiteLegal

Restricted information

High

Details are protected until domain ownership is verified to avoid exposing sensitive technical information publicly

Low

accessibility-basics › 3 of 193 image(s) are missing an alt attribute

Images without alternative text are announced as generic or unlabelled by screen readers, making the content harder to understand for users with visual impairments. This is a common and low-effort accessibility gap.

WebsiteAccessibility

Solution:

Add a descriptive alt attribute to every content image.

Recommended implementation:

<img src="content-image.jpg" alt="Person speaking at a workshop">

Technical checks:

Describe the image content or purpose concisely; avoid generic text such as "image" or "photo".
Use alt="" (empty, not missing) for purely decorative images so screen readers skip them.
Do not stuff alt text with keywords for SEO purposes.
Re-test after deployment using a screen reader or accessibility browser extension.

Info

seo-basics › 2 <h1> headings detected on the analysed page

Multiple H1 headings are not always a critical SEO problem, but they can make the page structure less clear and may reveal a template issue. On commercial pages, this can weaken the clarity of the main message and make technical review advisable.

WebsiteSEO

Solution:

Review the heading structure and confirm whether multiple <h1> elements are intentional.

Recommended technical actions:

Identify where each <h1> is generated: theme, CMS field, hero block, content component, header component or third-party widget.
Keep one primary <h1> for the main page topic where possible.
Convert secondary headings to <h2> or <h3> when they represent sections, blocks or supporting content.
Ensure hidden, duplicated or responsive-only headings are not creating repeated H1s.
Preserve a logical heading hierarchy for accessibility and document structure.
Re-test key page templates after the change.

Info

seo-basics › Incomplete Open Graph metadata detected (missing: og:image)

When Open Graph metadata is incomplete, social platforms and messaging apps may generate fallback previews. This can produce inconsistent titles, weak descriptions or unattractive images when users share the page.

WebsiteSEO

Solution:

Complete the missing Open Graph tags inside the document <head>.

Recommended implementation:

<meta property="og:title" content="Page title for social sharing">
<meta property="og:description" content="Short, compelling description for social sharing">
<meta property="og:image" content="https://example.com/path/to/image.jpg">

Technical checks:

Use an absolute URL for og:image.
Recommended image size: at least 1200x630 px.
Ensure the image URL returns HTTP 200.
Ensure the image is crawlable and not blocked by authentication or robots rules.
Keep og:title and og:description aligned with the visible page content.
Use page-specific values for content pages, categories and landing pages.
Ensure the tags are present in the initial HTML response.
Test previews in major social and messaging platforms after deployment.

Info

accessibility-basics › 14 of 442 link(s) or button(s) have no accessible text

Links or buttons with no visible text, aria-label or title are announced as empty or generic by screen readers (for example, just \"link\" or \"button\"), making them unusable for assistive technology users. This is common in icon-only buttons and image links.

WebsiteAccessibility

Solution:

Provide an accessible name for every interactive link and button.

Recommended implementation:

<a href="/account" aria-label="View account">
  <svg aria-hidden="true">...</svg>
</a>

<button aria-label="Close dialog">×</button>

Technical checks:

Prefer visible text content over aria-label when possible.
For icon-only controls, add aria-label or visually hidden text.
Ensure decorative icons inside the control use aria-hidden="true".
Avoid generic labels such as "click here" or "read more" without context.
Re-test with a screen reader or accessibility browser extension.

Info

dns-email-reputation › No validated DNSSEC delegation was found for the domain: No DS records in the parent zone

DNS responses for this domain cannot be cryptographically validated, leaving some exposure to DNS spoofing or cache poisoning in vulnerable network paths. This is a common configuration across the web and is rarely a critical issue on its own, but enabling DNSSEC adds a meaningful layer of trust for domains handling logins or sensitive customer data.

DomainDNS

Solution:

Enable DNSSEC signing for the domain.

Recommended technical actions:

Confirm DNSSEC support with the current DNS hosting provider or registrar.
Enable DNSSEC signing on the authoritative DNS zone.
Publish the resulting DS record with the domain registrar so the parent zone can delegate trust.
Verify propagation and validate the chain of trust with an external DNSSEC validation tool.
Monitor key rotation schedules if the provider does not automate them.

Info

legal-compliance › Known tracking services detected: Google Analytics / GA4, Google Tag Manager, Shopify Analytics / Marketing, Zendesk Chat, Mailchimp, Klaviyo

These services are commonly used for analytics, advertising, attribution, personalisation or behaviour measurement. This indicator is informational; privacy and compliance impact depends on the service purpose, configuration, consent behaviour, data sharing model and applicable jurisdiction.

WebsiteLegal

What to do now?

Choose the option that best fits your situation.

Free

Fix it in-house

Ideal if you have a developer, agency, or technical team available.

Prioritised action plan.
Explanation of each issue.
Step-by-step remediation guide.

Free access for verified domain owners: Verify ownership with an email from this domain to unlock the protected findings, technical evidence, and remediation guide.

Verify domain & unlock full report

Recommended

Request an advanced audit

Recommended if the site generates significant revenue or you need complete information to decide.

Manually verifies all findings.
Rules out false positives.
Analyses configurations that cannot be checked automatically.
Evaluates platform-specific risks (Shopify, WooCommerce, PrestaShop, Magento…).
Prioritises issues by business impact.
Delivers an executive report and remediation plan.

We can also implement fixes or coordinate them with your provider.

15 min

Not sure what to do?

Request a 15-minute review where we will analyse your audit results and tell you:

Which issues are genuinely important.
Which ones can wait.
Which are likely false positives.
The most cost-effective way to resolve them.

What is behind this report?

Built to detect the kind of issues that silently affect sales, trust, checkout confidence, campaign performance, and operational continuity.

fixthe.site — automated web auditing platform

A system designed to prevent your website and digital marketing from failing.
A team with over 25 years of experience building digital projects for businesses.
Thousands of automated audits run during platform training and validation.
Dozens of technical indicators analysed on every execution.
Multiple data sources combined — DNS, TLS, HTTP, performance, reputation, email, legal compliance, SEO, and more.
AI specialised in interpreting business impact, not just technical results.

About this audit

This report is provided for informational and prioritisation purposes only. It reflects automated observations obtained from publicly available information at the time of analysis. The findings are not definitive proof of a vulnerability, legal breach, security incident, performance failure, reputational damage, or business loss. They highlight indicators that may deserve review because improving them can help reduce exposure, strengthen digital operations, and support customer trust. Risk estimates are decision-support indicators, not predictions of specific events. Automated analysis cannot verify every technical, legal, operational, or business context. Expert review may be required to validate results, rule out false positives, and determine actual impact before making significant remediation or compliance decisions.