I think you're confusing the role of source control with the role of software architecture and proper dependency management.
If you've got a templating system, or just a template, that you want to be able to roll out to multiple sites, then you design it as a standalone framework which can be customized in certain predictable ways. This is how CMSes like WordPress already work. If you need to change the template and want that change to propagate to all sites, then you simply release a new version of the framework and update the sites that are based on it.
Cloning a repository is primarily meant as a tool to get multiple developers working on the same project. I think you're going to run into many headaches in the more distant future if you try to use that model for working on several completely different projects. Without the encapsulation provided by a real framework, it's almost certain that changes will be made to the templated sites that essentially rev-lock them, and while that's always a risk, it's exacerbated here by the ambiguity between modification and extension, a clear violation of the Open-Closed Principle. While that principle is specific to OOP, the general concept applies to all software.
Branches would probably make for a model that's easier to understand, although technically in Git you can still do all of the same things with multiple repositories, albeit more awkwardly, by simply adding local ones as remotes. I'm not sure why you'd want to, but it's possible.
It's not good design, though. In order to keep the sites maintainable, you want a clear separation of concerns between framework/templates, content/customization, and site deployment. It sounds like you're conflating them all and I'd urge you to reconsider before adopting a risky and bug-prone approach that depends entirely on source control. Git is great but it's not perfect, and even when a merge has 0 conflicts it can still break your site if the changes in both repositories are significant.