Deliveroo
UK delivery marketplace connecting consumers with restaurants, grocers, retailers, and on-demand couriers.
Reviewed site: deliveroo.com · Based on public pages
Observation
No information architecture is exposed to the user. There are no navigation menus, links, sitemaps, or any other pathways to other content. The user lands on the root domain (https.deliveroo.com/) and is presented with a terminal page that does not link to any other part of the website.
Inference
The system's architecture intercepts the user request before any of the site's IA can be rendered. For a user who triggers this security rule, the site's information architecture is effectively a single, isolated node. This demonstrates a security-first approach where access to the entire information structure is denied wholesale, rather than allowing access to a limited subset of public pages. Uncertainty about the actual site IA is 100%.
Recommendation
Even on a blocking page, consider providing a minimal, curated set of links that do not expose the core application. For example, links to a corporate blog, a press page, or a service status page can provide value without compromising the security posture. This creates a small, helpful information architecture for otherwise blocked users and prevents the experience from being a complete dead-end.
Observation
The user is presented with a generic, unbranded error page. The page title is Access denied | deliveroo.com used Cloudflare to restrict access | deliveroo.com | Cloudflare. The primary headings are Error 1009, Access denied, and What happened?. The design is minimal, text-based, and lacks any of Deliveroo's visual branding, such as logos, color schemes, or typography.
Inference
The design of this page is functional, not promotional or brand-aligned. It is served by Cloudflare, not the origin application server. This suggests that Deliveroo has prioritized security and traffic filtering at the network edge over providing a custom-branded experience for users who are blocked. The decision to use a default error page indicates that customizing this specific user journey is a low priority compared to the operational benefit of the security rule.
Recommendation
To improve user experience and maintain brand consistency, create custom branded error pages within the Cloudflare dashboard. A custom page can offer a more reassuring message, briefly explain why access might be restricted (e.g., "We're not yet available in your region"), and provide helpful links to a corporate site or help center. This transforms a jarring dead-end into a more helpful, on-brand interaction, especially for legitimate users who may be blocked by mistake.
Observation
The page is composed of basic HTML elements: a <title> tag and text-based headings. There is no evidence of interactive components, custom styling, JavaScript-driven widgets, or a recognizable design system. The components are generic and browser-native in their rendering.
Inference
The components used on this page are served by Cloudflare's infrastructure and are not part of Deliveroo's front-end application or component library. The simplicity of the components ensures fast delivery and universal compatibility across all browsers. This implies a clear separation between the edge security layer and the application's presentation layer. The lack of shared components suggests these two layers are managed and deployed independently.
Recommendation
Establish a pattern for using a lightweight, centrally-managed set of components for system-level pages like error messages. Even if served from an edge provider like Cloudflare, these pages can often be customized with HTML. Injecting a simple branded header or footer component via this customization can maintain a consistent user experience and brand identity across all user touchpoints, including error states.
Observation
The provided evidence explicitly states Detected stack: Cloudflare (70%). The page content, title, and headings all reference Cloudflare and a specific Cloudflare error code, Error 1009. The page is served directly by Cloudflare's network.
Inference
Cloudflare is a definite and critical component of the technology stack, acting as a Web Application Firewall (WAF) and/or Content Delivery Network (CDN). It is configured to sit in front of the main application servers and enforce access rules, in this case based on IP address, country of origin, or other factors associated with Error 1009. The underlying application stack (backend language, database, etc.) is completely hidden behind this Cloudflare layer, which is a deliberate security practice. The 70% confidence rating is likely understated; the evidence makes Cloudflare's presence a near certainty.
Recommendation
When using a service like Cloudflare, fully leverage its capabilities for security, performance, and reliability. However, it is crucial to configure robust logging and monitoring. Ensure that logs from the edge (Cloudflare) are ingested into an observability platform to gain insight into blocked traffic. This helps distinguish between malicious attacks and legitimate users being inadvertently blocked, allowing for the refinement of security rules without losing potential customers.
Observation
A user request to the root domain is intercepted by an intermediary service (Cloudflare) before it can reach the origin application server. This service evaluates the request against a set of rules and, upon failure, serves a static error page directly from its own infrastructure, terminating the request.
Inference
The system employs a multi-layered, proxy-based architecture. An edge layer, provided by Cloudflare, acts as a gatekeeper for the core application. This is a common and effective pattern for enhancing security, performance, and scalability. It decouples traffic management and security policy enforcement from the primary business logic. The core application infrastructure is shielded from direct public internet traffic. The architecture of the origin servers remains unknown, but the presence and function of the edge layer are clear.
Recommendation
This edge proxy architecture is a strong foundation. To build upon it, ensure the origin servers are hardened to only accept traffic from the proxy's IP ranges. This is a critical step to prevent attackers from discovering and targeting the origin server's IP directly, thereby bypassing the security protections offered by the edge layer. This practice is often referred to as creating an "authenticated origin pull."
Observation
The website is configured to deny access to certain visitors, triggering a Cloudflare Error 1009. This is an explicit choice to block traffic rather than allow it to pass through to the main application.
Inference
A strategic decision was made to prioritize security and/or market control over universal accessibility. This decision likely stems from business requirements, such as operating only in licensed regions, or from security imperatives, like blocking traffic from geographies known for malicious activity. The business has accepted the trade-off of potentially blocking some legitimate users (e.g., customers using a VPN) in favor of the broader benefits of the access control policy.
Recommendation
Decision-making for access control rules should be a documented and regularly reviewed process. Create a clear policy that defines why specific traffic is blocked. Implement an exception handling process for false positives, allowing legitimate users who are blocked to request access. This ensures that security measures adapt to changing business needs and do not become a permanent, unexamined barrier to entry.
Observation
The system uses a third-party service, Cloudflare, as a reverse proxy to filter incoming traffic before it reaches the application. This service handles security enforcement and serves error pages independently of the core application.
Inference
A highly transferable and effective pattern is the use of a managed edge security layer. Offloading tasks like DDoS mitigation, bot detection, and geographic access control to a specialized service simplifies the core application, reduces infrastructure load, and benefits from the provider's global scale and expertise. The application can then focus on its primary function: delivering business value.
Recommendation
When designing a web application, always incorporate a managed edge layer (such as a CDN or WAF) from the start. Do not expose your application servers directly to the public internet. Configure this layer to handle security policies, caching of static assets, and TLS termination. This layered approach is a foundational pattern for building secure, scalable, and performant web services. Ensure you lock down your origin to only accept traffic from this edge provider to complete the security model.
Observation
The only path available from the evidence is the root URL (/). This URL leads to a terminal error page with no links to any other part of the site. No sitemap, navigation, or other structural information is provided.
Inference
For any user triggering the access rule, the sitemap is effectively a single page. The true complexity and structure of the website's sitemap are completely hidden. This is a direct consequence of the security-first architecture, which prevents any information leakage about the site's structure to unauthorized users. The uncertainty about the actual sitemap is total.
Recommendation
On terminal error pages, provide a minimal 'utility' sitemap. This should not link to the core application but to publicly accessible corporate resources. For example, a footer on the error page could include links to About Us, Careers, Press, or Service Status. This provides a degree of usefulness and brand engagement even when access to the primary service is denied, guiding users to alternative, non-sensitive information.