ÉKO '77
Overview of Issues
ÉKO '77 is, visually and editorially, one of the better-presented restaurant sites we have audited. The brand voice is confident and distinctive, the typography reads like a printed fine-dining menu, the four restaurant pages carry real interior photography with live "CLOSED · OPENS TOMORROW AT 1PM" status indicators, and the trust stack is genuinely enviable: 4.5★ across 2,288 Google reviews, Food Standards Agency hygiene ratings of 5/5, 5/5, 5/5 and 4/5, HACCP compliance and full public liability insurance — all published openly. Desktop performance is excellent (96/100 PageSpeed, CLS 0.012). This is not a site that needs rebuilding. It is a site whose single most valuable action — booking a table — is leaking badly.
The booking system is the headline problem, and it is worse than it looks. Four restaurants are served by three different booking platforms, and one restaurant has no online booking at all. Kingstanding books through one resOS account; Wolverhampton books through a completely separate resOS account; New Cross books through OpenTable — a third-party marketplace that charges per-cover commission and actively advertises competing restaurants to your own diner at the moment of booking. Pershore Road has no reservation system whatsoever: its primary green call-to-action button, styled identically to the "Book Kingstanding" button on every other location, simply says "Walk-in" and links to Google Maps. That is 25% of the estate that cannot take an online reservation, on a site whose header CTA promises "Book a table".
Every booking also leaves your website entirely. A guest who clicks "Book a table" is handed off to a third-party domain (eko77.resos.com, or opentable.co.uk) where they are immediately met by a full-screen cookie-consent wall — a second one, after the one they already accepted on eko77.co.uk — before they can select even the number of guests. The complete path from homepage to confirmed table is five-plus steps across two domains with two separate cookie prompts. Restaurant booking is an impulse action, usually taken on a phone, often while the guest is doing something else. Every additional screen in that path costs covers.
This is compounded by a measurement blind spot that is costing real money. The site carries a live Google Ads conversion tag (AW-16830630781) — so ÉKO '77 is paying for traffic — but because bookings complete on someone else's domain, the outbound click is the last event the business can see. Google Ads cannot attribute a single completed booking, which means ad spend is being optimised against a click rather than a cover. There is also no Meta Pixel installed anywhere, despite Instagram being the brand's only linked social channel — so every pound of Instagram interest is untracked and unretargetable, and no diner database is being built.
The second gap is that the food is invisible. ÉKO '77 sells Nigerian cooking — an intensely visual, unfamiliar-to-many cuisine where the photograph is the sales argument. The menu page lists 79 priced dishes and carries just 5 food photographs. The homepage "Bill of Fare" section — the block whose entire job is to make a visitor hungry — is 100% text: elegant, beautifully set, and completely unappetising to someone who has never eaten Abula, Ogbono or Efo Riro and has no idea what arrives at the table. Meanwhile mobile LCP on the homepage is 8.1 seconds (PageSpeed mobile 68/100) — more than three times Google's 2.5s threshold, on the device where virtually all "restaurant near me" decisions are made.
The third gap is that the proof is buried and the questions go unanswered. That 4.5★ / 2,288-review trust block — the strongest conversion asset the brand owns — sits 4,773px down the homepage, roughly five screens below the fold, appears nowhere near any booking button, is presented as bare aggregate numbers with no quoted reviews, and is not linked to Google so a sceptical visitor cannot verify it. There is also no FAQ page anywhere on the site (all common URLs return 404): nothing on parking, halal, vegetarian options, children, dress code, group bookings, private hire or allergens. On the catering side, a well-designed enquiry form asks ten questions with no price guidance whatsoever — no "from £X per head" anywhere — and submits to a plain Shopify contact form with no automated confirmation, so the enquirer receives silence.
Finally, there is a dormant Shopify catalogue quietly damaging SEO. Eighteen catering products still exist in the store and 19 product URLs are still published in the XML sitemap — but every product, collection and cart URL now serves a meta refresh redirect to /pages/restaurants. Google is being instructed to crawl pages that immediately bounce, which produces soft-404 signals and wastes crawl budget. Compounding this, the site has zero structured data — no Restaurant, LocalBusiness, Menu or AggregateRating schema for a four-location restaurant group — no H1 on the homepage, and no meta description (the og:description is literally the word "ÉKO '77"). Those stars could be showing in Google results. Right now they are not.
Bottom line: the brand, the rooms, the food and the reputation are all in place — 2,288 reviews at 4.5★ is something most restaurants never achieve. The losses are concentrated in one place: the path between a hungry visitor and a confirmed table. Unifying booking onto your own domain, making the food visible, and fixing mobile speed are the three changes that will move covers, and they are all bounded, well-defined pieces of work.
The booking layer: what you actually need (and what you don't)
You asked us to look specifically at building an app that lets guests book tables online. We audited that question first, and the honest answer is: you do not have a booking-app problem — you have a booking-fragmentation problem. Four restaurants currently run on three separate systems, and a native mobile app would sit on top of that fragmentation rather than solve it. Here is the current state:
| Restaurant | Booking route today | Domain the guest ends on | Status |
|---|---|---|---|
| Kingstanding (flagship, Birmingham) | resOS account #1 | eko77.resos.com | Off-site |
| Wolverhampton | resOS account #2 — a separate account | eko-77-wolverhampton-…resos.com | Off-site |
| New Cross (London) | OpenTable marketplace | opentable.co.uk | Off-site + commission |
| Pershore Road (Stirchley) | None — green CTA reads "Walk-in" → Google Maps | — | No online booking |
What this costs you today. Three systems means three admin panels, three sets of covers data, and no single guest database — you cannot see that the diner who books Kingstanding in March is the same person who books New Cross in June, so you can never market to them as one customer. OpenTable additionally charges per-cover fees and puts your New Cross guest in front of competing restaurants at the exact moment of booking. Pershore Road turns away every guest who wants to reserve rather than chance a walk-in. And because every booking completes off-domain, your Google Ads account cannot attribute a single cover.
The current guest journey — every step is a place to lose them:
Our recommendation, in three options:
1. Unified on-site booking layer
Consolidate all four restaurants onto one booking platform, then embed it directly into eko77.co.uk so the guest never leaves your domain. Add a location picker to the header CTA so "Book a table" opens a live booking widget instead of a page of addresses. Pershore Road gets online booking for the first time; New Cross comes off OpenTable and off commission.
Result: one guest database you own, one admin panel, bookings tracked as real conversions in GA4 and Google Ads, and a journey that drops from six steps to two.
2. Booking + guest CRM layer
Everything in option 1, plus an owned guest profile: booking history across all four rooms, automated confirmation and reminder messages, post-visit review requests routed to Google, birthday and anniversary win-backs, and segmentation for the email platform. This is where a unified booking system starts generating repeat covers rather than just recording them.
This is the step that actually raises revenue per guest — and it depends on option 1 existing first.
3. Native mobile app
A downloadable iOS/Android app for bookings. We would advise against this as the first step. Restaurant bookings are overwhelmingly one-off, impulse actions taken from Google or Instagram — asking a guest to install an app before they can reserve a table adds friction rather than removing it, and app install rates for single-city restaurant groups are typically very low.
If you want an app-like experience, a PWA (installable web app, home-screen icon, push notifications, no app store) delivers 90% of the benefit at a fraction of the cost — and only makes sense after options 1 and 2 are live and you have a guest database worth pushing to.
⚠️ "Book a table" leads to a list, not a booking
The primary green header CTA links to /pages/restaurants — a page of four addresses. A guest who has decided to book must then choose a location and click a second time before any booking interface appears. The highest-intent click on the site does not start a booking; it starts more navigation. This should open a booking widget with a location selector.
⏱ Estimated: 4 dev hours
⚠️ No announcement bar
There is no announcement bar anywhere. For a four-location restaurant this is free, high-visibility space for exactly the things guests need to know before they commit: opening hours changes, bank-holiday service, private hire availability, or a seasonal message. It is also the natural place to surface "4.5★ · 2,288 Google reviews".
⏱ Estimated: 2 dev hours
⚠️ Search exists but has no autocomplete
A search form is present in the markup (action="/search") but there is no predictive/autocomplete layer. Given a 79-dish menu spanning unfamiliar dish names, a guest searching "jollof" or "goat" should get instant suggestions. Currently search is effectively decorative.
⏱ Estimated: 3 dev hours
✅ Sticky header confirmed
The header uses position: fixed and remains available through the full 11,535px homepage. On a page this long that is essential, and it is correctly implemented.
✅ Both conversion CTAs permanently visible
"Catering quote" and "Book a table" sit in the header at all times, visually distinct (outlined vs solid green). The two revenue actions are never more than one click away — this is the right architecture.
✅ Clean, logical navigation
Six items — Restaurants, Menus, Event Catering, Gallery, Our Story, Contact — with no mega-menu overload. Every label is plain English and maps to a real guest intent.
✅ Strong contrast and legibility
Dark text on the cream header and white-on-green CTAs are comfortably readable; the green CTA carries clear visual priority over the outlined secondary button.
⚠️ Hero CTAs sit at the very edge of the fold
Measured: the "Event catering" and "Book a table" buttons render at y = 798px in a 900px viewport. On any laptop with a shorter viewport — or with a browser bookmarks bar — they fall below the fold entirely. The two actions the entire page exists to drive are balancing on the edge of visibility.
⏱ Estimated: 4 dev hours
⚠️ The hero section is 1,775px tall — roughly two full screens
The hero alone occupies almost two viewport heights before the next section begins, which pushes every supporting argument (locations, hygiene ratings, reviews, menu) further down an already 11,535px page. Tightening the hero would lift the entire page's content up by a meaningful amount.
⏱ Estimated: 3 dev hours
⚠️ The headline is poetry, not a value proposition
"Come hungry, come as you are — in Èkó the table is always laid for one more" is beautiful brand writing, but a first-time visitor cannot tell from the first screen what kind of food this is, where the restaurants are, or that there are four of them. "Modern Nigerian cuisine" appears only in the small logo lockup. A first-time visitor should know cuisine + cities + rating within three seconds.
⏱ Estimated: 2 dev hours
⚠️ No social proof above the fold
4.5★ from 2,288 Google reviews is the single most persuasive fact ÉKO '77 owns, and none of it appears on the first screen. A one-line rating strip directly beneath the hero CTAs is one of the highest-return changes available on this page.
⏱ Estimated: 3 dev hours
✅ Static hero — no carousel
Verified: zero slides, no autoplay. A single, focused hero is exactly right — it loads faster, holds one clear message, and avoids the conversion penalty that rotating banners carry. This is the correct decision.
✅ Two clearly differentiated CTAs
"Event catering" (outlined) and "Book a table" (solid green) map precisely to the two revenue streams, with correct visual hierarchy between them.
✅ Genuinely appetising hero imagery
The hero uses real, atmospheric food photography with video support rather than stock imagery — warm, dark, restaurant-lit and true to the brand.
✅ Distinctive brand voice
The Yoruba greeting "Ẹ káàbọ̀" and the Lagos framing give the page a personality that most restaurant sites completely lack. This is an asset worth protecting — the fix above is to add clarity, not remove character.
🔴 The "Bill of Fare" showcase has zero food photography
The homepage dish showcase — Ewa Agoyin, Abula, Abula Fresh Fish, Assorted Meat, Grilled Whole Tilapia, Grilled Whole Croaker and more — is presented entirely as typeset text and prices. For Nigerian cuisine served to a mixed UK audience, many visitors have never seen these dishes. A name and a price cannot sell a dish nobody can picture. This is the single biggest content gap on the site.
⏱ Estimated: 8 dev hours (photography supplied separately)
⚠️ No "book this location" action in the homepage locations block
The locations section lists all four restaurants with live open/closed status — but offers no direct booking action per location. A guest who has just decided on Wolverhampton must navigate to the restaurants page and start again. Each location card should carry its own "Book" button.
⏱ Estimated: 3 dev hours
⚠️ No dish-level "bestseller" or "signature" signalling
Nothing on the homepage tells a first-time visitor what to order. With 79 dishes and an unfamiliar cuisine, decision paralysis is real. Tagging 3–5 signature dishes ("Our most-ordered", "Chef's signature") directly addresses the most common first-visit anxiety.
⏱ Estimated: 3 dev hours
⚠️ No customer photos or UGC anywhere on the homepage
An Instagram account is linked in the footer, but no gallery, feed or customer-photo block appears on the homepage. For a restaurant — where guests photograph their food constantly — this is a large, free content source going unused, and the most credible form of food imagery available.
⏱ Estimated: 4 dev hours
✅ "Three ways to the same kitchen" is excellent IA
Event catering / Book a table / Menus — a clean, honest three-way split of guest intent placed early on the page. Most restaurant sites never make this choice explicit.
✅ Live open/closed status per restaurant
Each location shows real-time state ("CLOSED · OPENS TOMORROW AT 1PM"). This is a sophisticated touch that answers the most common pre-visit question before it is asked, and very few restaurant sites implement it.
✅ Full address and phone for all four rooms
Every location carries a complete address and a tap-to-call number, with Google Maps links — strong for both conversion and local SEO.
✅ Rich brand storytelling
The "love letter to Lagos", the chef's statement and the "Proud origins" section give the brand genuine depth and differentiation — unusually good content for a restaurant site.
✅ Menu prices shown openly on the homepage
Dish prices are displayed up front rather than hidden behind a PDF — reduces friction and pre-qualifies guests before they arrive.
🔴 The strongest trust asset on the site is 4,773px from the top
Measured precisely: the block containing 4.5★ / 2,288 Google reviews and the Food Standards Agency ratings begins at 4,773px — approximately five screens down on desktop and far deeper on mobile. It also appears nowhere near either the "Book a table" or "Catering quote" buttons. Proof this strong should be working at the point of decision, not filed away in the lower half of the page.
⏱ Estimated: 4 dev hours
⚠️ No FAQ page exists anywhere on the site
Verified: /pages/faq, /pages/faqs and /pages/frequently-asked-questions all return 404. For a restaurant this means no answers to parking, halal, vegetarian and vegan options, spice levels, children and high chairs, dress code, group bookings, private hire, BYOB or allergens. Each unanswered question is either a phone call to staff or a lost booking — and FAQ content is among the strongest local-SEO assets a restaurant can publish.
⏱ Estimated: 6 dev hours
⚠️ Review claims are unverifiable and unlinked
"4.5 average across 2,288 Google reviews" is presented as plain text with no outbound link to any Google listing. A sceptical visitor has no way to check it, and the site gains none of the credibility of the live listing. Each location's rating should link to its own Google Business profile.
⏱ Estimated: 2 dev hours
⚠️ Footer is missing key links
Privacy and Contact are present, but there is no Terms of Service, no FAQ (none exists), no allergen information link (the allergen PDF lives only on the menu page), and no gift voucher or private hire entry. Allergen information in particular is a legal-adjacent expectation for UK hospitality and should be reachable from every page.
⏱ Estimated: 3 dev hours
⚠️ Instagram is the only social channel linked
For a UK restaurant group with four sites across Birmingham, Wolverhampton and London, Facebook remains a significant local-discovery channel — particularly for private hire, group bookings and an older catering audience. No Facebook, TikTok or Google Business links appear anywhere.
⏱ Estimated: 1 dev hour
✅ Exceptional trust content — once found
FSA hygiene ratings published per site (5/5, 5/5, 5/5, 4/5), HACCP compliance and full public and product liability insurance, stated openly. Publishing a 4/5 alongside three 5/5s rather than hiding it reads as genuine honesty, and that builds more trust than a curated version would.
✅ All four restaurants in the footer with NAP data
Name, address and phone for every location in the footer on every page — textbook local SEO, and convenient for guests.
✅ WhatsApp contact available
A prominent "WhatsApp us" button in the footer offers a low-friction channel that suits this audience well — faster than email and less intimidating than a phone call.
✅ Privacy policy and cookie preferences present
A privacy policy, a contact-information policy and a working cookie-preferences control are all in place — UK GDPR basics correctly handled.
✅ Clean "Explore" navigation column
The footer repeats the key journeys — Menus, Restaurants, Event catering, Book a table, Our story, Gallery, Contact — giving a second route to conversion at the end of a long page.
🔴 79 dishes, 5 photographs
Counted directly on the page: 79 price points and just 5 food images (peppersoup, egusi, okra, jollof, fried rice). Roughly 94% of the menu has no photograph. Food photography is the single highest-impact asset a restaurant website can carry, and it matters most precisely where ÉKO '77 is strongest — dishes like Abula, Ogbono, Ewa Agoyin, Asun and Nkwobi that a large share of UK diners have never seen. The typography is genuinely beautiful; it is also doing a job that only photography can do.
⏱ Estimated: 10 dev hours (photography supplied separately)
⚠️ Many dishes carry no description
Chicken Wings, Peppered Prawns, Spicy Gizzard, Puff Puff, Beef Suya and Chicken Suya are listed with a price and nothing else. Where descriptions do exist ("Grilled goat meat with peppers", "Amala with assorted meat stew, gbegiri and ewedu") they are excellent — the pattern simply is not applied consistently.
⏱ Estimated: 4 dev hours
⚠️ No dietary, spice-level or allergen tagging inline
An allergy PDF is offered at the top of the page, but no dish carries an inline vegetarian, vegan, gluten-free or spice-level marker. Guests with dietary requirements — and anyone nervous about heat — must download and cross-reference a document. Inline icons would resolve this instantly and are strong SEO content besides.
⏱ Estimated: 5 dev hours
⚠️ No booking CTA within the menu itself
The menu page is 7,062px tall and is where appetite actually forms — yet apart from the sticky header there is no contextual "Book a table" prompt within or at the end of the menu. A booking CTA after each category, or a closing prompt, would capture intent at its peak.
⏱ Estimated: 2 dev hours
✅ Excellent category tab navigation
Starters, Authentic Mains, Modern Mains, Soups, Sides, Mocktails, Juice, Soft Drinks and Water are navigable via a sticky tab bar — a long menu made genuinely usable.
✅ Allergy information offered up front
"Have an allergy? Download our allergy information" is placed prominently at the top of the menu — responsible, and a real trust signal for UK diners.
✅ One menu across all four rooms, stated explicitly
"One kitchen, one menu. Every dish below is cooked the same way in all four rooms" removes an obvious source of guest doubt in a multi-site group.
✅ Multi-size pricing handled clearly
Dishes with two prices (e.g. Grilled Whole Tilapia £22 / 25) are explained by a note at the top — clean handling of a detail most restaurant sites fumble.
✅ Correct H1 and clear page structure
"The bill of fare" is a proper H1 with a supporting intro, and the page hierarchy is clean and semantic.
⚠️ No map embedded on the page
Addresses link out to Google Maps, which pushes the guest off-site. An embedded map — ideally one showing all four locations — would let a visitor judge "which one is nearest me" without leaving the page. For a four-site group this is the core navigational question.
⏱ Estimated: 3 dev hours
⚠️ No parking, transport or accessibility information
None of the four locations mentions parking, nearest station or step-free access. For a Birmingham suburb site and a New Cross London site these are decisive practical questions, and their absence generates avoidable phone calls.
⏱ Estimated: 3 dev hours
⚠️ Per-location reviews and photography are thin
Each room gets one interior photograph and a short description. Individual Google ratings exist (4.5★, 4.5★, 4.4★) but are shown only in the aggregate block on the homepage, not on each location card where the choice is actually made. Two or three quoted reviews per room would make each location sell itself.
⏱ Estimated: 4 dev hours
✅ Genuinely well-structured location cards
Address, telephone, email, full opening times, live open/closed status, interior photograph, descriptive copy and a primary CTA — every question a guest has, answered in one card.
✅ Sticky location tab navigation
Kingstanding / Wolverhampton / New Cross / Pershore Road tabs let a guest jump straight to their city instead of scrolling — the right pattern for a multi-site page.
✅ Distinct, useful copy per room
Each location describes its own neighbourhood and signature dishes rather than repeating boilerplate — good for guests and materially better for local SEO.
✅ Proper H1 and honest hierarchy
"Four rooms, one kitchen" is a strong H1 that states the group's proposition immediately, with "THE FLAGSHIP", "THE SECOND", "THE THIRD", "THE FOURTH" giving each room a clear place in the story.
✅ Tap-to-call on every location
Every phone number is a working tel: link with a dedicated "Call the restaurant" button — essential for mobile, and correctly implemented throughout.
🔴 Four restaurants, three booking systems
Verified in the page source: Kingstanding → eko77.resos.com; Wolverhampton → eko-77-wolverhampton-1720006438.resos.com (a separate resOS account); New Cross → opentable.co.uk. Three admin panels, three sets of covers data, and no unified view of a guest who visits more than one room. The business cannot see its own customers as single people.
⏱ Estimated: 48 dev hours (unified booking layer)
🔴 Pershore Road cannot be booked online at all
Its primary CTA — styled exactly like the green "Book" buttons on the other three locations — reads "Walk-in" and links to Google Maps. A guest who arrives intending to reserve a table at Stirchley either phones or gives up. That is 25% of the estate excluded from every online booking journey, while the site header promises "Book a table".
⏱ Estimated: included in the unified booking layer
🔴 Every booking leaves your domain — and hits a second cookie wall
Captured in the screenshot above: the guest is handed to a third-party domain and immediately blocked by a full-screen cookie-consent modal with four toggles, after having already accepted cookies on eko77.co.uk. The booking page carries no ÉKO '77 branding. Booking a restaurant is an impulse decision — a brand break plus an extra consent step at the moment of highest intent is exactly where covers are lost.
⏱ Estimated: included in the unified booking layer
🔴 New Cross bookings run through a competitor marketplace
OpenTable charges per-cover commission on bookings and — more importantly — places your London guest inside a marketplace that actively recommends competing restaurants at the exact moment of reservation. You are paying a third party to market your competitors to your own customer, and the guest relationship belongs to OpenTable rather than to ÉKO '77.
⏱ Estimated: 6 dev hours (migration)
⚠️ The booking path is six steps long
Header CTA → location list → choose restaurant → third-party domain → cookie wall → People/Date/Time/Details. Each screen sheds users. An embedded widget with a location selector reduces this to two.
⏱ Estimated: included in the unified booking layer
⚠️ No booking incentive or deposit strategy
Nothing encourages booking over walking in, and no deposit or card-hold is taken on large parties. For a restaurant group this size, no-show protection on groups of six or more typically pays for the booking system on its own.
⏱ Estimated: 4 dev hours
✅ Three of four locations do accept online bookings
Kingstanding, Wolverhampton and New Cross all have working, reachable booking systems — both resOS endpoints returned HTTP 200 during testing. The infrastructure exists; it simply is not unified.
✅ Phone booking available everywhere
Every location offers a tap-to-call "Call the restaurant" button as a fallback, so no guest is left with no route at all — including Pershore Road.
✅ The resOS flow itself is sensibly structured
Once the cookie wall is dismissed, the People → Date → Time → Submit progression is clear, with a visible step indicator. The problem is where it lives, not how it works.
✅ Booking CTAs are visually unmistakable
Solid green buttons with location-specific labels ("Book Kingstanding", "Book Wolverhampton") make the action and its destination clear — the labelling pattern is good.
🔴 No price guidance anywhere in the catering funnel
Verified across the whole page: not a single figure. The three packages — Corporate (up to 100), Celebrations (100–300), Weddings (400+) — are defined purely by headcount. Someone planning a 200-guest wedding has no idea whether ÉKO '77 means £15 or £60 per head, so the form becomes a blind enquiry. A "from £X per head" indicator per package is the highest-impact change on this page: it pre-qualifies enquiries and dramatically raises completion.
⏱ Estimated: 4 dev hours
⚠️ Ten questions before a first conversation
The form asks for package, date, guest count, location, catering type, chafing dishes, on-site staff, name, phone and email. Chafing dishes and staffing are operational details that belong in a follow-up call, not in a first-contact form. Splitting into a short first step (date, guests, contact) and an optional detail step would materially lift completions.
⏱ Estimated: 5 dev hours
⚠️ No automated confirmation after submission
The form posts to the standard Shopify contact endpoint with no email platform connected, so an enquirer receives no confirmation and no indication of when to expect a reply. For a wedding enquiry — a high-value, emotionally significant purchase — silence after submitting is the point at which people contact a competitor.
⏱ Estimated: 4 dev hours
⚠️ No catering menus, galleries or case studies
The packages describe headcount but not what is actually served. There is no sample catering menu, no photography of a set-up event, and no case study of a real wedding or corporate booking. "Twenty years of catering" is claimed but never evidenced with a specific event.
⏱ Estimated: 6 dev hours
⚠️ No response-time commitment
Nothing states when a quote will arrive. "We reply to every enquiry within 24 hours" is a single line of copy that measurably increases form completion by removing uncertainty about what happens next.
⏱ Estimated: 1 dev hour
✅ Genuine customer testimonials on the page
Real named reviews with five-star ratings and locations ("Tomilayo Akinduro ★★★★★ Wolverhampton") appear directly in the catering funnel — the right social proof in the right place.
✅ Clear three-package structure
Corporate / Celebrations / Weddings, banded by guest count, lets an enquirer self-identify immediately rather than facing an undifferentiated "contact us".
✅ Credibility statistics stated plainly
"12–1,000 guests catered for", "20 years of events before the restaurants", "4 kitchens" — concrete numbers that establish capability quickly.
✅ Strong catering photography
Unlike the menu pages, the catering page carries genuinely appetising event and spread photography — proof the brand has the photographic capability; it simply is not applied to the menu.
✅ Pickup and delivery both offered explicitly
The form captures catering type (pickup vs delivery) and on-site requirements up front, which is operationally sensible once the enquirer has committed.
✅ Dedicated header CTA for catering
"Catering quote" sits permanently in the header alongside "Book a table", giving the second revenue stream equal billing site-wide.
🔴 2,288 reviews and not one quoted on the homepage
The homepage shows aggregate numbers only — "4.5", "2,288 Google reviews" — with no actual review text, no reviewer names, no dates and no photographs. Numbers establish scale; quoted reviews create belief. A restaurant sitting on 2,288 reviews has an enormous library of persuasive content going completely unused on its most-visited page.
⏱ Estimated: 6 dev hours
⚠️ No review or rating appears beside any booking CTA
Neither the hero CTAs, the locations block, nor any of the four location cards on the restaurants page carries a star rating. Social proof is strongest when adjacent to the decision, and here it is entirely separated from it.
⏱ Estimated: 3 dev hours
⚠️ No review platform integration — reviews are hard-coded
No Google review widget, Judge.me, Yotpo, Trustpilot or equivalent was detected. The rating figures appear to be manually entered, which means they will silently go stale as the real count grows past 2,288, and no new review ever reaches the site automatically.
⏱ Estimated: 5 dev hours
⚠️ No customer photography anywhere
The gallery's 43 images are all professional brand photography. There is no UGC, no Instagram feed and no customer-photo wall — despite restaurant guests being among the most prolific food photographers there are. Customer photos consistently outperform professional shots for credibility.
⏱ Estimated: 4 dev hours
⚠️ No post-visit review request loop
With no email platform and no unified booking database, there is no mechanism to ask a guest for a Google review after they dine. The 2,288 figure has been earned organically — a simple automated post-visit request would compound it substantially.
⏱ Estimated: included in email platform setup
✅ A genuinely outstanding underlying reputation
4.5★ across 2,288 reviews, with per-location detail (Kingstanding 4.5★, New Cross 4.5★, Wolverhampton 4.4★), is an exceptional asset. The reputation is real; only its presentation needs work.
✅ Honest handling of the newest location
"Pershore Road opened most recently and has too few ratings to publish" — transparent rather than evasive, and that candour itself builds trust.
✅ Third-party credentials, not just self-assessment
Food Standards Agency ratings, HACCP standards and liability insurance are independent, verifiable signals — considerably stronger than self-authored trust badges.
✅ Named testimonials on the catering page
Real reviewer names, star ratings and locations appear in the catering funnel — proof the brand already knows how to present reviews well, and simply has not applied it to the homepage.
✅ Professional gallery with working lightbox
43 images across four rooms with "Every picture opens" — well-built, well-shot and well-organised.
🔴 19 product URLs published to Google, all of which bounce
The XML sitemap still lists 19 product URLs, and /products.json still returns 18 live catering products (Jollof Rice, Egusi, Efo Riro, Moi Moi and others, £15–£70). Every one of those URLs serves <meta http-equiv="refresh" content="0; url=/pages/restaurants">. Google is being instructed to crawl pages that immediately redirect — which generates soft-404 signals, wastes crawl budget, and is explicitly discouraged by Google in favour of proper 301 redirects.
⏱ Estimated: 4 dev hours
🔴 A complete catering catalogue is invisible to search
Eighteen products with names, descriptions and prices exist in the store but rank for nothing, because every page redirects before it can be indexed. Terms like "Nigerian catering Birmingham", "jollof rice catering tray" or "Egusi London delivery" are exactly the high-intent local searches this business should own — and the content to serve them already exists.
⏱ Estimated: 8 dev hours
⚠️ Six orphaned collections still live
/collections/frontpage, bulk-orders, stews, peppered, rice and sides all remain published and all meta-refresh to the restaurants page — more crawlable dead ends.
⏱ Estimated: 2 dev hours
⚠️ Meta refresh used instead of server-side 301
Redirects are implemented client-side via meta refresh plus window.location.replace(). Server-side 301s pass link equity properly, resolve instantly with no flash of content, and are the correct instrument for a permanent move.
⏱ Estimated: 3 dev hours
⚠️ A strategic decision is pending here
Either the catering shop is a live revenue channel — in which case the products should be reachable, indexable and purchasable — or it is retired, in which case the products and collections should be unpublished and removed from the sitemap. The current half-state delivers neither the revenue nor the clean SEO profile.
⏱ Estimated: 2 dev hours (consultation)
✅ Redirect destination is sensible
Sending dormant commerce URLs to /pages/restaurants at least lands visitors on a useful, conversion-relevant page rather than a 404 or the homepage.
✅ No broken checkout left exposed
The cart URL redirects rather than presenting a half-working checkout — a guest can never reach a payment flow that would fail. The decision to switch commerce off was executed consistently.
✅ Well-structured product data still intact
The 18 products retain proper titles, vendor attribution, product types (Stews, Rice dishes, Peppered meats, Sides & snacks) and prices — a clean foundation if catering commerce is ever switched back on.
✅ robots.txt correctly configured
The standard Shopify robots.txt is in place with no accidental blocking of important paths.
⚠️ Booking CTAs are 29px tall — below the 44px minimum
Measured directly: the sticky "Catering quote" and "Book a table" buttons render at 29px in height. Both Apple and Google specify 44px as the minimum reliable touch target. The two most valuable buttons on the site are the two that are hardest to tap — and mis-taps on a sticky header are especially costly because they usually trigger the wrong action.
⏱ Estimated: 2 dev hours
⚠️ No booking CTA in the header at the top of the page
At scroll position zero the mobile header shows only the hamburger and the logo; the booking buttons appear once the user begins scrolling. The first screen — the one every visitor from Google or Instagram lands on — has no persistent booking action, relying entirely on the hero buttons further down.
⏱ Estimated: 2 dev hours
⚠️ The mobile homepage is 13,760px long
That is roughly sixteen full screens. With most content requiring scroll and no jump navigation, key material — locations, hygiene ratings, the 2,288-review block — sits extremely deep on the device where the vast majority of restaurant discovery actually happens.
⏱ Estimated: 5 dev hours
⚠️ No click-to-call in the mobile header
Phone numbers exist deeper in the page, but the mobile header offers no direct call action. For restaurants, tap-to-call is a primary conversion — particularly for same-day bookings, and especially for Pershore Road where phoning is the only way to reserve.
⏱ Estimated: 2 dev hours
✅ Sticky header with both CTAs on scroll
Once scrolling begins, the header condenses and surfaces "Catering quote" and "Book a table" persistently — verified at 5,000px depth. The pattern is right; only the tap-target size needs correction.
✅ Hero CTAs above the fold on mobile
"Event catering" and "Book a table" render at roughly 513px in an 844px viewport — comfortably visible without scrolling.
✅ 16px base font size
Body text measures exactly 16px, meeting the accessibility standard and preventing iOS input zoom.
✅ No horizontal overflow
Document width 375px against a 390px viewport — no sideways scroll anywhere. The responsive implementation is clean.
✅ Standard hamburger menu
A conventional, correctly-labelled hamburger at a 44px touch target opens the full navigation — no unusual patterns to learn.
✅ No intrusive interstitial popups
No full-screen email popup interrupts the mobile experience — which also avoids Google's mobile interstitial penalty.
🔴 The off-site booking handoff is worst on mobile
The domain switch, the second cookie wall and the four-step external form all compound on a small screen. A guest booking from Instagram or Google Maps on a phone must cross two domains, dismiss two consent prompts and complete a form that was never designed to match the brand they just left.
⏱ Estimated: included in the unified booking layer
⚠️ The mobile menu page is a long, unbroken scroll
Seventy-nine dishes on a 390px-wide screen with almost no imagery makes for a punishing read. Collapsible category accordions would let a guest reach "Modern Mains" in one tap instead of a long scroll.
⏱ Estimated: 4 dev hours
⚠️ No mobile-specific booking bar
Mobile-first restaurant sites typically carry a persistent bottom bar with "Book" and "Call". Here the only route is the 29px header pill. A bottom action bar is the single highest-impact mobile change after the booking unification itself.
⏱ Estimated: 4 dev hours
⚠️ Location tabs are cramped on a 390px screen
Four location tabs — Kingstanding, Wolverhampton, New Cross, Pershore Road — compressed into 390px produce small, closely-spaced touch targets that invite mis-taps.
⏱ Estimated: 2 dev hours
✅ Trust block renders beautifully on mobile
The Google reviews and hygiene ratings cards reflow cleanly into a single column with no cramping or overflow — the responsive work here is genuinely good.
✅ Tap-to-call works throughout
Every phone number across all four locations is a functioning tel: link — the critical mobile restaurant interaction, correctly implemented everywhere.
✅ Typography holds up at small sizes
The serif menu styling remains legible and elegant on mobile rather than degrading — the type system was clearly designed responsively.
✅ Images lazy-load correctly on mobile
38 of 39 images use loading="lazy", keeping data usage down for mobile visitors on cellular connections.
✅ Zero layout shift
CLS measures 0 on mobile — nothing jumps as the page loads, which is a common and highly damaging fault on image-heavy restaurant sites.
🔴 Mobile LCP is 8.1 seconds
Google PageSpeed Insights, homepage, mobile: Performance 68/100, LCP 8.1s, FCP 3.2s, Speed Index 4.3s. Google's threshold for "good" LCP is 2.5s and anything above 4s is classified as poor — this is more than three times the target. Restaurant discovery is overwhelmingly mobile; an eight-second wait for the main content means a substantial share of visitors never see the hero at all. This also directly suppresses local search ranking.
⏱ Estimated: 10 dev hours
🔴 No structured data anywhere on the site
Verified across the homepage and restaurants page: zero JSON-LD. No Restaurant schema, no LocalBusiness, no AggregateRating, no Menu, no openingHoursSpecification. For a four-location restaurant group with a 4.5★ average from 2,288 reviews, this is the largest missed SEO opportunity on the site — star ratings, opening hours, price range and menu links could all be showing directly in Google results, and none of them are.
⏱ Estimated: 8 dev hours
🔴 The homepage has no H1 and no meta description
Confirmed by direct inspection: document.querySelectorAll('h1').length === 0 on the homepage, and no <meta name="description"> — the og:description is literally the string "ÉKO '77". The title tag is "ÉKO '77 – ÉKO '77", the brand name duplicated, with no cuisine and no location. For queries like "Nigerian restaurant Birmingham" the most important page on the site gives Google almost nothing to work with. Every interior page does have a proper H1 — the homepage is the exception.
⏱ Estimated: 3 dev hours
⚠️ Images are served as JPEG, not WebP or AVIF
Of 39 homepage images: 37 JPEG, 1 AVIF, 1 PNG, totalling 1.9 MB. The heaviest are x-catering-bg.jpg (299 KB) and x-hero-poster.jpg (242 KB) — and the hero poster is the likely LCP element. Converting to WebP/AVIF typically cuts image weight 30–50% with no visible quality loss, and would directly improve that 8.1s mobile LCP.
⏱ Estimated: 5 dev hours
⚠️ 272 requests and 1 MB of JavaScript across 147 files
Measured in-browser: 272 requests, 3.18 MB transferred (6.28 MB decompressed), with JavaScript at 1,022 KB across 147 separate files — including a 204 KB hydration bundle. Above 200 requests, connection overhead becomes material on mobile networks.
⏱ Estimated: 6 dev hours
⚠️ The booking page is slow too — LCP 4.8s
PageSpeed mobile for /pages/restaurants: 81/100, LCP 4.8s. Better than the homepage but still above Google's 4s "poor" threshold — and this is the page every booking journey must pass through.
⏱ Estimated: 4 dev hours
✅ Desktop performance is excellent
PageSpeed desktop: 96/100, FCP 0.5s, LCP 1.3s, Speed Index 0.8s, TBT 10ms. On desktop this site is genuinely fast — which confirms the mobile problem is image weight and delivery, not architecture.
✅ Cumulative Layout Shift effectively zero
CLS of 0 on mobile and 0.012 on desktop. Nothing shifts as the page loads — excellent, and rarer than it should be on image-led sites.
✅ Total Blocking Time near zero
TBT of 0ms on mobile and 10ms on desktop. Despite 147 JavaScript files, the main thread is not being blocked — the site stays responsive while loading.
✅ Lazy loading correctly implemented
38 of 39 images carry loading="lazy", with the hero correctly set to eager — exactly the right configuration.
✅ Fast server response
TTFB measured at 10–14ms on Shopify's infrastructure. Hosting and back-end response are not the bottleneck.
✅ Clean heading structure on interior pages
Restaurants, Menu, Event Catering, Our Story and Gallery each have exactly one H1 with a sensible H2 hierarchy beneath.
✅ No console errors
The homepage loads with zero JavaScript errors — only minor warnings. The build is clean.
🔴 No email marketing platform connected
No Klaviyo, Mailchimp, Omnisend or equivalent was detected anywhere. The "Join the club" form posts to Shopify's generic /contact endpoint with a tag. That means no welcome sequence, no booking confirmations or reminders, no post-visit review requests, no birthday or anniversary offers, no win-backs and no catering follow-ups. Every address collected sits in a list nobody can send from.
⏱ Estimated: 12 dev hours
⚠️ Newsletter signup offers no incentive
"Be the first to hear about new dishes, new rooms and the occasional very good reason to book a table" is charming copy, but there is no concrete reason to subscribe now. A specific offer — a free starter, a drink on arrival, priority access to bookings — typically multiplies signup rate several times over.
⏱ Estimated: 2 dev hours
⚠️ No live chat or AI assistant
No chat widget was found in the markup and none is visible in any screenshot. WhatsApp is offered as a fallback (good), but it requires leaving the site and opening another app. For questions like "do you have a table for six on Saturday?" an on-site chat converts materially better.
⏱ Estimated: 3 dev hours
⚠️ No loyalty or repeat-visit programme
No points, no rewards, no repeat-diner recognition. Restaurants live on repeat custom, and with 2,288 reviews there is clearly a substantial base of returning guests receiving no recognition for it.
⏱ Estimated: 8 dev hours
⚠️ No gift vouchers
Gift vouchers are a standard high-margin restaurant revenue line, concentrated around Christmas, Mother's Day and birthdays, and require no kitchen capacity to sell. There is no voucher option anywhere on the site.
⏱ Estimated: 6 dev hours
⚠️ The blog is effectively empty
A blog exists but the sitemap shows a single entry. For local SEO — "best Nigerian restaurant in Birmingham", "what is Egusi", "Nigerian wedding catering UK" — this is significant untapped ground, and the brand voice is already strong enough to carry it.
⏱ Estimated: 6 dev hours
✅ WhatsApp contact prominently offered
A "WhatsApp us" button with a pre-filled message sits in the footer — a low-friction channel that suits this audience and the hospitality context well.
✅ No intrusive popups
No email popup interrupts the visit. Newsletter capture is embedded naturally in the page flow instead — the right choice, and one that avoids Google's interstitial penalty.
✅ No fake urgency or countdown timers
Verified: no countdown elements, no artificial scarcity. For a restaurant brand built on warmth and hospitality, the absence of manipulative patterns is genuinely on-brand.
✅ Newsletter copy is well written
"No spam — only news, offers and the odd recipe" sets clear expectations in the brand's own voice — good practice and good writing.
✅ Cookie consent properly implemented
A working cookie banner with a persistent "Cookie preferences" control in the footer — UK GDPR handled correctly.
✅ Newsletter form asks only two fields
Name and email only — minimal friction on the signup itself.
🔴 Google Ads is running but cannot attribute a single booking
A Google Ads conversion tag is live (AW-16830630781) — so budget is being spent. But because bookings complete on resos.com and opentable.co.uk, the outbound click is the last event the tag can observe. No completed booking is attributable to any campaign, keyword or ad. Spend is therefore being optimised toward clicks rather than covers, which is the most expensive measurement gap a business can have. Unifying booking on-domain fixes this as a side effect.
⏱ Estimated: 8 dev hours
🔴 No Meta Pixel installed
No connect.facebook.net or fbq() anywhere on the site, despite Instagram being the brand's only linked social channel. That means no retargeting of visitors who browsed the menu but did not book, no lookalike audiences built from actual diners, and no measurement of Instagram-driven traffic. For a visually-led restaurant brand, Instagram is the most natural paid channel available — and it is currently untracked and unusable for retargeting.
⏱ Estimated: 5 dev hours
⚠️ No booking-funnel event tracking
No custom events fire on the steps that matter: "book button clicked", "location selected", "catering quote submitted", "phone number tapped". Without these there is no funnel data, so it is impossible to know whether guests drop at the location list, at the domain handoff or inside the external form.
⏱ Estimated: 5 dev hours
⚠️ No automated guest communications
With no email platform and booking data split across three systems, none of the standard hospitality automations exist: booking confirmation, day-before reminder (the single most effective no-show reduction available), post-visit review request, or lapsed-guest win-back.
⏱ Estimated: included in email platform setup
⚠️ No catering enquiry follow-up sequence
Catering enquiries are high-value and long-cycle — a wedding is often booked months ahead. Submissions land in an inbox with no automated acknowledgement and no nurture sequence, so every follow-up depends on someone remembering manually.
⏱ Estimated: 4 dev hours
⚠️ No TikTok pixel
No TikTok tracking is present. Food content performs exceptionally well on TikTok, and Nigerian cuisine has a strong, active audience there — a channel worth measuring before investing in it.
⏱ Estimated: 2 dev hours
✅ GA4 correctly installed
Google Analytics 4 is live (G-KCPG8L6089) with gtag and dataLayer both present and functioning — the analytics foundation is in place and just needs conversion events defined.
✅ Google Ads tag present and configured
The Ads conversion tag and Google Tag container (GT-5R89CMSP) are correctly deployed. The infrastructure is right; it simply cannot see off-domain conversions.
✅ Shopify web pixel active
Shopify's native web pixel is running, providing baseline behavioural data through the platform.
✅ Clean tag implementation
No duplicate GA4 properties, no conflicting containers and no orphaned legacy tags — the tracking setup is tidy, which makes extending it straightforward.
✅ Consent management in place
A cookie consent mechanism is deployed ahead of tracking, which matters for UK GDPR compliance and for Google Consent Mode.
Average dev hours and a fixed price at $40/hour. Suggested order: Critical → Medium → Low.
| Block | Task | Hours (avg) | Fixed Price |
|---|---|---|---|
| 07 | Unified on-site booking layer — one platform across all 4 restaurants, embedded on eko77.co.uk, location picker in header CTA, Pershore Road online for the first time | 48 | $1,920 |
| 07 | Migrate New Cross off OpenTable (remove per-cover commission, recover guest data) | 6 | $240 |
| 15 | Booking conversion tracking — GA4 + Google Ads conversions on completed bookings | 8 | $320 |
| 15 | Meta Pixel + Conversions API installation | 5 | $200 |
| 13 | Mobile LCP fix — hero poster/video optimisation, critical-path delivery (8.1s → target under 2.5s) | 10 | $400 |
| 13 | Structured data — Restaurant, LocalBusiness, Menu, AggregateRating & opening hours for all 4 sites | 8 | $320 |
| 13 | Homepage H1, meta descriptions and title tags site-wide | 3 | $120 |
| 10 | Dormant catalogue cleanup — sitemap, server-side 301s, unpublish or restore decision | 8 | $320 |
| 14 | Email platform setup (Klaviyo) + booking confirmation, reminder, review-request & win-back flows | 12 | $480 |
| 05 | Menu photography integration — dish cards and layout across 79 items (photography supplied separately) | 10 | $400 |
| 03 | Homepage "Bill of Fare" rebuild with food photography | 8 | $320 |
| 08 | Catering price guidance ("from £X per head") across all three packages | 4 | $160 |
| 04 | Move social proof above the fold + rating strip beside booking CTAs | 7 | $280 |
| Subtotal — Critical | 137 hrs | $5,480 | |
| Block | Task | Hours (avg) | Fixed Price |
|---|---|---|---|
| 01 | Header "Book a table" opens a booking widget instead of a location list | 4 | $160 |
| 01 | Announcement bar + predictive search | 5 | $200 |
| 02 | Hero tightening — CTAs safely above the fold, clearer value proposition | 9 | $360 |
| 04 | FAQ page + FAQ schema (parking, halal, vegan, groups, private hire, allergens) | 6 | $240 |
| 04 | Footer completion — allergens, terms, FAQ, Google review links, social channels | 4 | $160 |
| 05 | Dish descriptions + inline dietary, spice-level and allergen tagging | 9 | $360 |
| 06 | Embedded multi-location map + parking, transport and accessibility info | 6 | $240 |
| 08 | Catering form restructure (two-step) + automated confirmation email | 9 | $360 |
| 08 | Catering sample menus, event gallery and case studies | 6 | $240 |
| 09 | Review platform integration — live Google reviews with quoted testimonials | 8 | $320 |
| 11 | Mobile tap targets to 44px + click-to-call in header | 4 | $160 |
| 12 | Mobile bottom action bar (Book / Call) + menu category accordions | 8 | $320 |
| 13 | WebP/AVIF conversion + image compression across the site | 5 | $200 |
| 13 | Request reduction + JS bundle optimisation; booking page speed (LCP 4.8s) | 10 | $400 |
| 15 | Booking funnel event tracking + catering enquiry nurture sequence | 9 | $360 |
| 03 | Per-location "Book" buttons on homepage + signature dish tagging | 6 | $240 |
| Subtotal — Medium | 108 hrs | $4,320 | |
| Block | Task | Hours (avg) | Fixed Price |
|---|---|---|---|
| 14 | Live chat / AI booking assistant widget | 3 | $120 |
| 14 | Gift voucher system | 6 | $240 |
| 14 | Loyalty / repeat-diner programme | 8 | $320 |
| 14 | Blog structure + local SEO content templates | 6 | $240 |
| 09 | Instagram UGC feed + customer photo wall on homepage | 4 | $160 |
| 06 | Per-location review quotes and expanded room photography | 4 | $160 |
| 07 | Deposit / card-hold on large party bookings (no-show protection) | 4 | $160 |
| 15 | TikTok pixel installation | 2 | $80 |
| Subtotal — Low | 37 hrs | $1,480 | |
* Hours are averages and the price is fixed at $40/hour, for development implementation only. Content creation (food photography, catering case studies, blog copy) and third-party subscription costs (booking platform, Klaviyo, loyalty app) are not included. The optional guest-CRM phase (+40 hrs · $1,600) and a PWA layer (+60 hrs · $2,400) are quoted separately in the booking section above and are not counted in this total. Suggested order: Critical → Medium → Low.
Stores on our CRO approach grew Total Sales +19%
The fixes in this report aren't theory — they're the same conversion levers we implement for the stores we work with. Here's the Total Sales curve from a store running our approach versus the previous period:
Total Sales over the period: $168,636 — +19% vs the prior period. Solid line = current (our approach), dotted = before.