Restaurant Menu Parsing and Food Delivery Price Scraping: Bypassing Aggregator Blocks Without Data Loss

```html

Yandex.Eda, Delivery Club, SberMarket, and dozens of regional delivery aggregators are a real goldmine of data for marketers, analysts, and restaurant business owners. However, as soon as you start systematically collecting prices and menu items, the services begin to block requests. In this article, we will discuss how to properly organize the parsing of menus and delivery prices, what tools to use, and how proxies help avoid blocks.

Why parse restaurant menus and delivery prices

The food delivery market in Russia is one of the most dynamic segments of e-commerce. Prices for dishes, menu compositions, and delivery conditions change literally every day. Manually tracking these changes is impossible when it comes to dozens of competitors or hundreds of items. This is where automatic data collection is needed.

Here are who uses menu and price parsing in practice:

• Restaurant and café owners — track competitors' prices in their area to quickly adjust their own pricing.
• Marketers of restaurant chains — analyze which menu items competitors promote through promotions and special offers.
• HoReCa market analysts — build reports on average prices for categories of dishes in different cities and regions.
• Aggregator startups — collect a database of restaurants with menus and prices for their own catalog.
• Investors and consultants — assess the competitive environment before opening a new establishment or franchise.
• App developers — create databases of dishes for calorie counting or meal planning applications.

If you work in the restaurant business or analyze it, regular monitoring of competitors' prices is not a luxury but a necessity. A difference of 30–50 rubles on a popular dish can directly affect the conversion to orders. Without automation, you will always be one step behind those who have already set up data collection.

What data is collected from delivery aggregators

Before setting up a parser, it is important to understand what specific data you need. Delivery aggregators contain several layers of information, and each of them is useful for different tasks.

Monitoring prices over time is particularly valuable: if you collect data once a day for several months, you can see patterns in competitors' pricing — when they raise prices, when they launch promotions, and how they react to external events (holidays, sporting events, bad weather).

Features of protection for Yandex.Eda, Delivery Club, and other aggregators

Major delivery aggregators actively protect their data from automated collection. This is understandable: their database of restaurants and current prices is their competitive advantage. Before setting up a parser, you need to understand what specific protections you will encounter.

Yandex.Eda

It uses several levels of protection simultaneously. First, geolocation is actively employed: menu content and prices are displayed depending on your IP address — if the IP is from Moscow, you see Moscow restaurants. Second, the site operates as a SPA (Single Page Application) on React, meaning that data is loaded via API requests rather than embedded in HTML. Third, suspicious activity triggers Yandex SmartCaptcha. If there are frequent requests from one IP, you are simply blocked from accessing the site.

Delivery Club (SberMarket)

Similar architecture: data is delivered via an internal API rather than through static HTML. The service analyzes behavioral patterns: if requests come too quickly or without pauses — blocking occurs. User-Agent and request header analysis is also used. Non-standard headers immediately raise suspicion.

Regional aggregators

Services like Chibbis, Goloso, and local aggregators in regions typically have weaker protection. Some of them use simple HTML pages that can be parsed with standard tools. However, IP blocking for frequent requests is standard practice here as well.

Tools for parsing without code and with code

The good news is that you don’t need to know how to program to parse restaurant menus. There are ready-made no-code solutions that handle most tasks. However, for working with SPA sites like Yandex.Eda, more serious tools will be needed.

No-code tools (without programming)

Octoparse — one of the most popular visual parsers. It allows you to click on page elements and build a data collection scenario without writing code. There is a cloud mode with IP rotation. Suitable for collecting menus from sites with a simple structure.

ParseHub — a similar tool with a visual interface. It can work with JavaScript pages, making it applicable for modern aggregators. It supports proxies.

Apify — a platform with ready-made "actors" (ready-made parsers for popular sites). For some delivery aggregators, there are already ready-made solutions in their marketplace. You can run it through a web interface without code.

Code-based tools (for developers)

Python + Requests + BeautifulSoup — a classic combination for parsing static pages. Fast, easy, but does not handle JavaScript rendering.

Python + Selenium or Playwright — controls a real browser (Chrome/Firefox), so it handles SPA sites, JavaScript, and even some captchas. Playwright is considered a more modern and faster solution. This combination works with Yandex.Eda and Delivery Club.

Scrapy — a professional framework for large-scale parsing in Python. It supports request queues, middleware for proxies, and export to various formats. For large projects collecting restaurant data, it is the optimal choice.

Why parsing doesn’t work without proxies

This is a key question. Many novice analysts try to run a parser directly from their IP and immediately encounter blocking. The reason is simple: delivery aggregators see hundreds of requests from one address in a short time and automatically block it. Restoring access can take from several hours to several days.

Proxies solve this problem by distributing requests among many different IP addresses. From the server's perspective, requests look like regular traffic from different users in different locations. However, not all proxies are equally effective for this task.

Residential proxies

Residential proxies use IP addresses of real home users. From the perspective of Yandex.Eda or Delivery Club — this is an ordinary person who logged in to view a restaurant's menu. Such proxies are virtually never blocked when used correctly. They are the ideal choice for collecting data from major aggregators with serious protection.

Mobile proxies

Mobile proxies are IP addresses from mobile operators (MTS, Beeline, MegaFon, etc.). Their feature is that one mobile IP can be used by thousands of real users simultaneously (through NAT), so sites rarely block mobile addresses. This makes them one of the most reliable options for high-frequency parsing.

Datacenter proxies

Datacenter proxies are the fastest and cheapest, but their IPs are easily identified as "non-human." They are suitable for regional aggregators with simple protection, but Yandex.Eda and Delivery Club block them quite quickly. Nevertheless, datacenter proxies work well for initially bypassing the site structure and testing the parser before the production launch.

Step-by-step setup of the parser with proxies

Let's consider a practical scenario: you want to collect pizza prices from 20 competitors in your city from Yandex.Eda daily. Here’s how to set it up step by step.

Step 1. Study the aggregator's API structure

Open Yandex.Eda in your browser, press F12 (DevTools), go to the Network tab, and filter requests by XHR/Fetch. Find the restaurant page and see what API requests are sent when loading the menu. Usually, it looks like api/v1/menu?restaurantId=.... Note the headers of these requests — you will need them for simulation.

Step 2. Choose a tool

If you don’t write code — use Apify or ParseHub. If you code in Python — Playwright will be the optimal choice for working with JavaScript sites. Install the necessary tool and ensure it supports connecting external proxies.

Step 3. Get proxies with geotargeting

This is an important point. Yandex.Eda shows different restaurants depending on the city. If you are parsing menus of restaurants in Yekaterinburg — you need proxies with IPs from Yekaterinburg. Residential proxies with geotargeting by city allow you to get exactly the content that a local user sees. Specify the required region when setting up proxies.

Step 4. Set up proxy rotation

Do not use one proxy for all requests. Set up rotation: change IP every 5–10 requests. In Apify, this is done through the proxy pool settings. In Scrapy — through middleware. In Playwright — by passing a new proxy when creating each browser context. The more frequently the IP changes, the lower the risk of blocking.

Step 5. Set up delays between requests

Add random pauses between requests — from 2 to 8 seconds. This simulates the behavior of a real user. Never make requests with an interval of less than 1 second — this is a sure way to get banned. In Scrapy, use the DOWNLOAD_DELAY parameter and enable AUTOTHROTTLE_ENABLED.

Step 6. Set up correct request headers

Always pass a realistic User-Agent (browser string), the Accept-Language header (for example, ru-RU,ru;q=0.9), and Referer. Requests without these headers look like a bot and are blocked first. Use current User-Agent strings from Chrome or Firefox.

Step 7. Set up scheduling and data storage

Run the parser at night (from 2:00 to 6:00) — the load on the aggregators' servers is minimal, and suspicious traffic is less noticeable. Save data to a database (PostgreSQL, MySQL) or at least in CSV with timestamps. This will allow you to build a history of price changes.

# Example of setting up proxies in Playwright (Python)
from playwright.sync_api import sync_playwright
import random
import time

proxies = [
    {"server": "http://proxy1.example.com:8080", "username": "user", "password": "pass"},
    {"server": "http://proxy2.example.com:8080", "username": "user", "password": "pass"},
    # ... more proxies
]

def parse_restaurant_menu(url):
    proxy = random.choice(proxies)
    
    with sync_playwright() as p:
        browser = p.chromium.launch()
        context = browser.new_context(
            proxy=proxy,
            user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
        )
        page = context.new_page()
        
        # Random delay 2-8 seconds
        time.sleep(random.uniform(2, 8))
        
        page.goto(url)
        page.wait_for_selector('.menu-item')  # wait for menu to load
        
        # Collect data about dishes
        items = page.query_selector_all('.menu-item')
        menu_data = []
        for item in items:
            name = item.query_selector('.item-name').inner_text()
            price = item.query_selector('.item-price').inner_text()
            menu_data.append({'name': name, 'price': price})
        
        browser.close()
        return menu_data

Common mistakes and how to avoid them

Even with the correct setup of tools, many encounter problems when parsing food delivery data. Here are the most common mistakes and how to fix them.

Mistake 1: Using one proxy for all requests

Even the highest quality residential proxy will be blocked if hundreds of requests per day are made to one site through it. Always use a pool of at least 10–20 proxies with rotation. The more restaurants you parse, the more proxies you need.

Mistake 2: Ignoring geotargeting

Yandex.Eda and Delivery Club show different content depending on the user's city. If you want to collect data on restaurants in Novosibirsk but use Moscow proxies — you will get Moscow data. Always check that the proxy corresponds to the required region.

Mistake 3: Parsing HTML instead of API

Beginner parsers try to collect data from the HTML code of pages. But on SPA sites (and Yandex.Eda is one), data is not embedded in HTML — it is loaded via API. It is much more efficient to find the required API endpoint through DevTools and call it directly. This is faster, more stable, and requires fewer resources.

Mistake 4: Too high request frequency

The desire to collect data faster is understandable, but it leads to immediate blocking. For daily price monitoring at 50 restaurants, it is sufficient to run the parser once a day with pauses of 3–5 seconds between requests. Do not try to speed up the process by reducing delays.

Mistake 5: Lack of monitoring proxy functionality

Proxies can "die" — they get blocked, or their validity expires. If the parser continues to work with a blocked proxy, you receive empty data or errors without noticing the problem. Set up a check for proxy functionality before each run and automatically replace non-working addresses.

Mistake 6: Ignoring changes in site structure

Aggregators regularly update their sites and APIs. A parser that worked a month ago may stop working after the next update. Set up error notifications and check the parser's functionality at least once a week. Keep documentation on the data structure you are collecting handy.

Conclusion

Parsing restaurant menus and delivery prices is a real tool for competitive advantage in the restaurant business and HoReCa market analytics. Yandex.Eda, Delivery Club, and other aggregators actively protect their data, but with the right approach — a competent choice of tools, setting up delays, and using quality proxies — data collection works stably and without blocks.

Key takeaways from this article: use tools that support JavaScript rendering (Playwright, Apify), set up proxy rotation, remember about geotargeting, and always add random pauses between requests. These are the three pillars of stable parsing.

If you plan to regularly collect data from Yandex.Eda, Delivery Club, or regional delivery aggregators, we recommend paying attention to residential proxies — they provide maximum resistance to blocks and support geotargeting by Russian cities, which is critically important for correct data collection on prices in specific regions.