Route one is copy and paste
Select the table, copy, paste into the sheet, fix the columns. It takes two minutes and it is the right answer for a task you will do once.
It fails the moment the task repeats. Twenty pages becomes forty minutes of clicking, the formatting arrives differently every time, prices come in as text with a currency symbol attached, and nobody can tell you afterwards which day the numbers were taken.
Route two is the built in web query
Excel can pull a table from a URL directly, and for a simple static page with a real HTML table it works well. Refresh the sheet and the numbers update.
It breaks on the pages people actually want. Anything rendered by JavaScript arrives empty, because the query reads the document as served rather than as displayed. Anything that requires a country, a postcode or a session returns the wrong version. Anything defended returns a challenge page, and you get a sheet full of nothing with no error explaining why.
Route three is a browser extension
Extensions that point and click at fields are genuinely good at collecting a list from a page you are already looking at. For a one afternoon research task, they are the fastest option available.
The limits are structural rather than about quality. It runs on one laptop, in one browser session, which means it runs when that laptop is open and that person is available. There is no schedule, no history, no second person who can run it, and nothing your other systems can call. Data collection that matters ends up depending on somebody's browser being open, which is fine until the week they are on holiday.
Route four is a scheduled job that writes the sheet
The version that survives contact with a recurring deadline: the job is defined once, runs on a schedule on somebody else's machine, and the spreadsheet is the destination rather than the tool.
- The fields are chosen by clicking on the page in the no code web scraper builder, so nobody writes a selector.
- The job runs every morning, or hourly, whether or not anyone is awake.
- The output lands as a file, or as a link that always holds the latest run, or straight into a system through a webhook.
- Every run is kept as its own set of rows, so the change between Monday and Tuesday is data rather than a memory.
- Pages that need a browser get one, and pages that need a specific country are read from that country.
The columns that decide whether the sheet is usable
A spreadsheet from a page is only as good as its typing. Three things are worth getting right at the start, because they are painful to fix over a year of history.
- Numbers as numbers. A price of 24.90 in a cell is arithmetic. The text 24,90 EUR is a cleaning job, repeated forever.
- A timestamp on every row. Without the moment of collection, a price history is a pile of numbers in no order.
- A stable identifier per item. Product names change and get truncated. An identifier lets Monday and Tuesday refer to the same thing.
Typed extraction handles all three at collection time, which is the difference between a sheet you analyse and a sheet you repair.
When to graduate from the spreadsheet
A spreadsheet is the right home for tens of thousands of rows a person reads. It stops being the right home when the rows feed a system rather than a reader: pricing rules, a dashboard, a model, an alert. At that point the same job points its webhook at a database and the sheet becomes one of the outputs rather than the only one.
That transition is why building the first version on an API rather than on a laptop extension matters: the job does not have to be rebuilt when it outgrows the sheet. The same account, the same schema and the same schedule serve the web scraping api your engineers call.
The short version
Copy and paste for once. The web query for a simple static table. An extension for an afternoon of research. A scheduled job for anything with the word weekly in it, because that is the only one that does not quietly become somebody's recurring chore.