OK, so answering your question literally, You don't need to make any changes.
The volume of data on the database isn't usually a scaling issue for webpages. Any given webpage will only be looking at a small part of the data and databases are designed to retrieve subsets of data from large sets very quickly.
What you need to take account of is how quickly you can generate a page. This is usually limited the number of requests per second for webpages that your server is receiving. Each one takes up a chunk of CPU time and your server has a limited amount. Once you hit 100% every page request will get slower and slower.
So its not the million rows you have to worry about, its the million users.
Website servers are cheap to scale, you and fire up webserver2, copy your website to it and double your capacity with no major technical hurdles.
However, both websites will now be using the same database server. and once that hits capacity you do have some significant techincal problems to solve.
The underlying problem is that you want all the database requests to be looking at the same data. If you simply copy it across to a second db the databases will quickly go out of sync.
If you continually update each with data from the other, the each server is doing twice as much work and you haven't solved your scalablity problem.
MongoDB and other nosql databases are designed to combat this by ignoring it. instead of having a number of tables which must all be consistent, you put all your data into one blob. so its always consistent with itself.
This allows you to spin up multiple instances and just copy the data without too much of an issue. It then solves the problem of the blobs being updated with some clever tricks you don't have to worry about too much.
So in summary: You current php + mongodb website, assuming you haven't made any 'gothcha' errors should scale up to any number of users by just throwing more servers at the problem. If you are cloud hosting that just means clicking a button or two and putting your credit card in.