all page scraping starts with "view source". then a target and, possibly, a pattern.
a big problem nowadays involves dynamically created pages (actually, it's always been an issue). a case in point would be where the the petrol prices were not originally part of the html source, but, rather, were loaded into an html template via an ajax call. viewing the source, and even downloading it with okhttputils would have you scratching your head since you wouldn't see the prices.
if you looked at the source in such a case, you wouldn't see the prices as they are generated at runtime with javascript. in that case, you need to use "inspect element" along with view source. i assume we're talking about chrome's so-called developer's tools. you would probably also have to look at the network activity tab (the prices might have been loaded in a .json file with ajax. that would have made things even easier, as you could skip all the page scraping and simply download the .json directly.)
in the case at hand, i could see the prices with view source, so page scraping would point to the target.
in this case, the pattern was flex-table - a glorified <table></table> construct. instead of a standard table's <tr> and <td> tags, flex-table uses <div> tags
with a "role=" attribute. for example, a flex-table's "cell" has - guess what? - a "role=cell" attribute. all i had to do was match what was inside "<div></div>" blocks where the div's role was a cell. regex to the rescue. matching the rows would have been a lot harder. thankfully, it didn't occur to the op to ask for that.