I’ve done this sort of thing myself in the past (back in the v2 days), when the L&L website had a wiki. As it was intended to be collaborative where users could help contribute, I had a need for easily incorporating updates from the server.
To get one thing out of the way, how such content would be exported is going to be along the lines of wiki markup in .txt files which can then be somehow brought into the actual wiki itself. One big exception are the rare wikis that are file-based for their content rather than solely using a database. DokuWiki is one such system that works that way, and it is in fact what I used for our website because of that advantage.
That aside, I think it is best to set your expectations more toward copying and pasting out of a text editor and into a website, though, as most wikis will not be able to do much with a bunch of .txt files (to the extent that making that a goal seems secondary to me).
Broadly speaking there seems to me three different approaches for maintaining a wiki from Scrivener source, with different pros and cons.
Pure syntax workflow
This is most often what I recommend to those looking to use Scrivener to maintain an external repository, using some kind of markup system, where the most important factor is round-tripping the data back into the software at some point. It is the method I used the past (before Markdown had effective WikiMedia conversion).
The main question this approach answers is: why build an elaborate conversion workflow when it is so easy to just write directly in WikiMedia or whatever? It was after all designed to be written with, like Markdown.
Details...
Pros
It is simple and effective, with no complex and potentially lossy conversion required, which means very little setup, if any. It’s so basic you can copy and paste out of Scrivener itself and into the website—that’s exactly what we do from our project used to maintain the knowledge base. There’s a lot to be said for having a level of simplicity and transparency like that, and Document Bookmarks can greatly ease the workflow since in some systems you can store a URL to the edit function of the page that binder item corresponds with online, as well as the read-only copy.
It also means the External Folder Sync feature, which is Scrivener’s take on the watch folder concept, is a viable part of the workflow. That may be convenient in some cases where additional tools are desired in the workflow, or if your wiki uses file based content, it could even theoretically be used to sync via FTP semi-automatically (I just used export and FTP though, as one has more up-front control over the file names that way).
Cons
The first downside with this approach is that it does limit some of what you might think to use Scrivener to do—but perhaps not as much as you think. I would say the main downside to me is the binder item = page limitation, i.e. being unable to use the outliner to organise longer articles more effectively. I suppose you could still do that, with the intention of only updating parts of a page on a regular basis (as many wikis make it easy to do).
Another impactful downside with a stricter round-trip protocol: it would limit how much you do with the compiler, if you choose to go that route instead of export/file-sync/copy-and-paste. For example, one might think to use styles to help generate wiki markup—you could certainly do that with ease, but it would be a somewhat one-shot in that there is no “decompiler” that could be configured to turn that markup back into styles. The same would be true of using the outliner to generate article heading depth with section layouts. Without some intermediary conversion to a format Scrivener can split on import back into hierarchy, you’d “lose” that capability after one generation and would have to turn it all off.
That’s just a general truth for the most part, applicable to almost everyone that uses Scrivener. We call it compile for a reason. It’s taking source data and turning it fundamentally into something else, that generally cannot be used to “reverse compile” back into source. That is not a practical reality in most cases, especially given the breadth of what can be done with it.
Wiki syntax production
This alternative builds off of the downsides in the previous and leans into them. Obviously, for this approach it is only one you would want to take if round-tripping is completely undesired, and more of a would-be-nice factor.
Details...
Pros
This is a capability that we put a lot of design thought and development into, when coming up with the various tools in the compiler and their integration with how a project can be structured, both at the outline and text level. A good practical example of that can be found in the Non-Fiction template category, when creating a new project, with the “General Non-Fiction (LaTeX)” template. Obviously the exact implementation here isn’t to produce wiki page data, but all of what that is doing to generate .tex files is a matter of configuration. Scrivener itself has no knowledge of LaTeX. By extension of that principal, one could build a complete wiki syntax exporter using the same methods it uses.
All around I would say this is the best way of using Scrivener in a markup oriented environment, if you don’t need round-trip. It’s extremely powerful, to the point that you could program the compiler to interact with the wiki’s API and even have Scrivener publish the updates directly for you, as noted above.
Plus, with a suitably style-based approach where little markup if any is found in the editor, one source could generate Markdown, WikiMedia, LaTeX, XML or any other plain-text output you might desire, and maybe even some rich-text stuff as well if you plan ahead for it.
Cons
An approach like this is very powerful and for some it will be more comfortable than the above, but it’s definitely premised upon the basis that the material is being written from scratch in Scrivener and is being produced outward only; not coming back into the software. That does not at all mean that’s the end of the line for the project of course, one can continue to create new updates from it indefinitely.
One downside is that by depending upon the compiler to produce page data it will in most cases mean compiling page per page rather than dumping the whole thing out into individual files per pages. There are of course some ways around that which involve scripting to split a single file into many, but that does increase the overhead of what you’d need to do to make your project functional for this workflow.
I don’t consider this a major downside though in practice, because it is worth considering that in most cases compiling a single page’s data from a portion of the draft will be fine, as you won’t be updating many articles at once offline. It’s probably only the initial export where there would be a degree of manual labour, and unless you are using something like DokuWiki, no matter how you slice it (or don’t slice it), it’ll result in about the same amount of copying and pasting. Doesn’t matter if you’re doing that from one file with obvious separators, or 30 files.
Pandoc aided conversion
The next alternative is to use Markdown on the writing side, which Scrivener has more extended native support for than the above. With this it would be possible to use Pandoc to convert Markdown that you write (or generate) with Scrivener to wiki syntax. This is the method I would use today, if I were maintaining a wiki server.
Details...
One advantage to using Markdown as your basis is that Scrivener does parse headings optionally, and can split a document back up into a nested outline. I have never been a fan of that workflow since it means dropping nearly everything Scrivener does outside of the text editor—snapshots, keywords, bookmarks, internal links… you lose all of that if you essentially start from scratch with every round-trip cycle. But for some it might be worth the sacrifice, particularly if they do not use much of those to begin with.
One could even convert wiki syntax back to Markdown and import it into Scrivener, to create a round-trip friendly environment. However this is going to be necessarily a bit “lossy” and may require some tuning to get a truly symmetrical conversion. All around if this were a priority, I would consider the “purist” approach first.
Something else to consider is that some wikis run on Markdown, or have mods that make them capable of taking Markdown source instead of wiki syntax. Prioritising a server that can provide that capability might make a round-trip Markdown approach much more viable as you are no longer hoping the conversion does what you want (or spending time fiddling with Pandoc templates to make it do so).
Where there is a stronger argument for using Markdown at the source is if you intend to publish to a variety of forms. If the wiki is just one possible avenue for getting this material out there, I’d stick with wiki syntax, but if you want to have a downloadable PDF or an eBook, then Pandoc is a good choice.