Reading more of the web at once

Over the last few weeks we changed how Researchly searches the web and reads what it finds. Two things will feel different. Sources begin appearing in the chat while your search is still going, one at a time, instead of all together at the end. And answers can now draw on facts buried deep inside long pages, facts that used to be missed even when the right page had been found.

Answers start sooner

Researchly used to work in strict order. Every search finished, then reading began, then the answer was written. Now those steps overlap. As soon as one search returns, we start reading its best matching pages while the other searches are still running. The preparation at the start of a turn, like recognizing a company name you mentioned and planning the research, also runs at the same time rather than one step after another. Writing starts earlier too. Researchly begins drafting the answer while it is still checking whether the evidence covers your question, and if that check finds a gap, the extra research still happens exactly as before. And if you paste a specific web address into your question, we go straight to reading that page instead of first checking whether it belongs to a company we know about.

You can watch sources arrive

Each page now shows its own progress in the chat. A row reads "Reading…" while that page is being read, and it completes on its own the moment the page is done, so you can watch sources arrive one by one instead of waiting for the whole batch. Several searches and page reads run at the same time, and the evidence from each search is kept separate, so a source from one search never gets mixed into another. When a page was already read earlier in the same turn, we reuse it rather than fetch it again.

Researchly mid-turn: the search block lists each query as it runs while the answer starts writing below

The figure at the bottom of the report

Here is a concrete case. You ask about a specific figure in a long annual report, a number that sits far down the document. Previously, Researchly kept only the first part of a long page, so that figure often never reached the answer, even though the right report had been found. Now we pick the passages most relevant to your question from anywhere in the page, and a fact near the end of a long report can finally make it into the answer. Pages with no clear match to the question are still read from the top, so nothing changes for ordinary pages. While this happens, you see the report's row at "Reading…" in the chat and the other sources land around it one after another, with the searches that fed them still running.

A Researchly turn rechecking a funding round: three queries running and two pages in the Fetching pages list, each row reading "Reading…" with its site beside it

Heavy pages read much faster

Some pages need a full browser to render, mostly sites heavy on JavaScript. We replaced that rendering path with a faster one. In a benchmark on the same set of static, documentation, and JavaScript-heavy pages, the new path took roughly a third of the wall time of the old one, about 1 to 2 seconds per page instead of 4 to 7. It also pulls out the parts of the page that match your question. Every attempt to read a page is bounded by a time limit for the whole turn, so one slow site cannot stall your answer.

When a source cannot be read, we say so

Two fixes make answers more honest. When Researchly hits its limit on the number of searches for a turn partway through a batch, the pages already read in that batch are now kept and shown. Before, they were discarded, and the answer could wrongly say it could not verify something it had in fact read. And when a source cannot be read at all, the answer now tells you with a warning instead of quietly leaving it out. Sources are still cited, and the searches and pages Researchly read still appear in the chat, so you can check every claim against the original page.