Since Scrivener is designed around a single-document system, exporting an interlinked site will require post processing. What you could do is use the Content pane to select different folders or groups of documents that you intend to have on a single page, and compile each of those to HTML individually. Then create a master page with the cross-links using your web design tool of choice that links to each of these individual files. You should be getting images though. When you compile to HTML with embedded images, a folder will be created for the whole compile, with an HTML file and all of the graphics it needs to display the page. These graphics will be placed in an Images sub-folder, which works very well for web sites. This means everything is already linked up to use the same Images folder, you’ll just need to make sure to upload all of the individual contents of these folders into the same unified Images folder on the web server, and keep the sub-pages on the same level, otherwise the links to the images will break without further editing. On the web server, you should see something like this:
Say chapter one links to one of those, and chapter two to the other. When you first compile, you’ll have two separate folders, so it is just a matter of consolidating these separate folders into one structure on the web server. Hopefully that all made sense.
For revisions, all you need to do is update the HTML file that contains the changes. Compile that portion of the Draft that was used to create the file, again, and upload the HTML replacing the old one on the server. If no images were added, you can get away with not doing anything with images. Image removal can be ignored unless you have a pressing desire to keep the web server clean of unused material, and images that have been moved around will just have their new placement updated when the HTML is uploaded. So the nice thing about this workflow is that you only need to compile out and post-process everything once. From that point on, you can just compile out the individual sections (pages) you need to revise, and perhaps periodically update the master page with the table of contents, if titles or placements change.
You could use the MultiMarkdown one as well, but that will probably only be better if you’ve actually used MultiMarkdown markup in your document. The regular HTML one will attempt to convert all of your rich text formatting to HTML equivalents. The MMD stuff uses its own system and completely ignores any italics, indents, and other things you may have done in your text. It’s a great system, but by and large you need to be working with it in mind to take advantage of it. It will have the same issues that the regular HTML compile does in that it is designed to create one single document, so you’ll need to compile multiple times to get multiple pages. The way it organises embedded images in a little different, but using the above guidelines you can probably sort this out. The approach I would take with it is to have sub-folders on the web server for each sub-page, so that you don’t have a huge mess of images and pages in the same folder, since MMD exports and links the images in the same directory, rather than an Images sub-directory.