If the root page has less than a full page of items, I would also have it load the full next page, and the "next" link would go to page 3. So your first page might have from 10 up to 19 results, then every page after that would have 10.
The other option is to use a "start" parameter which is the offset of the first item to load, and you always load that item + the next 9. However this means you have N cached pages instead of N/10.
Assume that an incrementing id is assigned to blog posts. The first page would always have the 10 most recent items. The "next" link would look like "/blog?offset=500". So when you click that, you get the items numbered 500-491, and the "next" link on that page is "/blog?offset=490". Admittedly the URLs are ugly, but the advantage is that the contents don't change when items are added, only when they are deleted (the same can't be said for the page=N scheme).
In this scenario up to 9 items on second page may overlap with items on the first page, right?
That would be confusing to users.
Besides, I still see no business advantage of making content hardwired to certain page. If anything, it's better to change page content from SEO perspective.
Say it had 10 items (full page size). But then 1 new item was posted. Should we create new root page with just 1 item?
Should we ask users to click on pager after viewing just one item in search results?