After checking with our team -
Head tags are a bit tricky, not only for DTM, but all tag managers. Head tags need to be present immediately because the browser loads them very first. Using a tag manager in general to update tags in the head especially meta tags can be problematic. Basically, tag managers aren’t able to get the tag added before the browser reads them. You can read a bit more about it here:
There is no such API. I could imagine that this approach helps you to implement this requirement:
* write the HTML <head> section but with empty tags
* collect the values for these tags while rendering the page and store it as RequestAttribute
* Implement a Sling Output Rewriter  and rewrite the tags in the <head> section with the data store in the Request attribute.
Another (not so nice) approach (instead of using the Rewriter) could be a filter, which renders all output into a temporary buffer (String) and then does a search and replace of certain placeholders.
Your authors do not have access to the page properties? Because if they do, you might be able to have a "Heading" tab, where an author can simply add some values, which are being displayed in your <head> section of the page, by overlaying the head.html file in a custom page component
Thank you for the suggestion dylanr46798176. Can you describe what do you mean by "overlaying"? Can an individual component have it's own head.html and/or extend the top level head.html content?
Or do you mean having a single instance of a component present on effectively a master template that renders the text/String content of the respective dialog tab page property input that's available on every page?
Looking at an Adobe Marketing Cloud head.html example it looks like it's rendering various <meta> properties by targeting currentPage. If that new property/input for custom <head> code is available on every page it could perhaps be added to head.html such as currentPage.someNewProperty.
The Sling Output Rewriter could be really useful in this case. We will definitely give it a try. Thanks!
Well, when using the power of Sling, you can have the following situation:
Pages beneath the /content/<SITE> path have a sling:resourceType that refers to the component that is used to render the page. You can have your own custom component (e.g. /apps/<SITE>/components/structure/page), that has a sling:resourceSuperType to the component that was originally used to render your pages (e.g. /libs/wcm/foundation/components/page) and have its own custom head.html file. You will have to make sure that the pages beneath the /content/<SITE> path will use your custom component for rendering the page by making the sling:resourceType refer to your custom component.
When the page gets rendered, it will see that the resourceType is /apps/<SITE>/components/structure/page, which has a resourceSuperType to /libs/wcm/foundation/components/page. It will render your page as if it were a /libs/wcm/foundation/components/page component, BUT with the exception of the head.html file, because that is the only file that is beneath the path of /apps/<SITE>/components/structure/page!
Some more info on this feature called "Sling Resource Merger" can be found here: