This can a tricky situation with a lot of possible soltuions, and I have had to work through this several times before, myself. SXA definitely isn't right for this solution, but one of the below might be.
- Will the client want/need to modify the HTML in the Content Editor, i.e. will they need to modify it on their own
- Does the client have experience with HTML, where they can control their HTML as needed, or will an RTE be required?
- Will you need to content manage any of the page around the HTML, i.e. will you be using a Sitecore controlled header or footer, etc.
To RTE or Not to RTE
Sitecore Rich Text Editor is great...until it isn't. First off, you should only consider using it if you are going to manage other content on the page. Don't use an RTE for the entire page. From the standpoint of content entry and formatting rich text content, Sitecore's implementation of the Telerik editor does a pretty decent job and even lets you add your own HTML. If you client will need to modify the HTML on their own but doesn't have the HTML knowledge to do this without a GUI then the RTE is going to have to suffice.
However, Sitecore's RTE also has many problems for managing HTML content. First off, the RTE will change your HTML as it sees fit, in order to best approximate what it thinks your editors want. This means that if you have scripts that are dependent on the HTML then you risk those scripts breaking, you could risk your styles being broken or CSS bugs being introduced, and so on. Basically, this works well for a well-defined and bounded section of content being managed for a page with a consistent overall design and structure, but it doesn't work all that well for an entire page being managed.
To @TamasTarnok's point, yes, disabling scripts in your RTE field is a possibility, but it wouldn't be my recommended approach since you can't disable scripts for just those fields that you want to use to store the HTML content of a page. Rather, you have to disable the scripts for all fields. There is a reason why Sitecore disables scripts in this field by default. If you can avoid it, I wouldn't change it. If, however, your client does need the ability to modify the HTML content on their own and cannot do so without an RTE GUI then this option is worth consideration.
The Multiline Text Field Type
The Multiline Text field type would be my recommended approach, if you plan to content manage other components on the page. As with the RTE, don't use an MLT for an entire page. It is meant specifically for what you are looking to do: managing raw HTML/script markup. This field will work great OOTB with no additional modifications, so long as your client either doesn't need to modify the HTML content on their own or else knows HTML well enough to modify the content without a GUI.
With this approach, you are guaranteed that the HTML content you enter in the field will not be modified or manipulated and will be exactly what renders out on the front-end. Additionally, you don't have to make a solution wide change that affects all of your site's RTE fields.
File-System Based Solutions
If you aren't going to be content managing (i.e. controlling components, like the header, footer, etc.) any of the page around the HTML (which I think is the case for your solution) then I would go with a file-system based solution. The idea here is that you already have the HTML files and all you really need to do is upload them to your web root.
I would create a custom admin tool for your Content Authors to upload the files and store them at the desired path. You could even manage the unzipping of the files for only a few minutes (or seconds, if you don't need to look up the
System.IO.Compression namespace) of additional effort.
Be sure to keep the following in mind:
- If they need to be able to delete HTML files, they should have a mechanism to do that (can simply allow them to specify a path to an HTML file in the root and delete the file at that path)
- You may want to have a warning display if they try to overwrite an existing file
- If they need to be able to modify the HTML/content at will themselves, and uploading new files to overwrite the old ones isn't a feasible option then this might not be the way to go
- If you have scaled environment with separated CM and CD servers, you will need to set up a sync process or have your file upload copy the files to the CD server(s) as well (or something similar)
- If you want to support publishing, you will also need a custom mechanism to do so, as well