So I’ve been trying to read up on this and while some seem to have had some success, I’m at somewhat of a loss on how to do it. We are building a (v9.4.7) multisite of two sibling domains, sharing a custom theme developed at the same time (so page types and templates are added as needed, the theme doesn’t have an existing blueprint for this).
The site building has been started with the theme on the primary domain and now that we want to start fleshing out the structures of each site, we’re finding we can’t use the page types created on the default site on the other one, that Concrete guided us through creating as a whole another type of site. The existing page types also can’t be duplicated on the secondary site’s side through copying or adding manually using the same handles, because those handles are taken by the originals.
I tried setting the secondary site’s siteTypeID to 1 in the Sites table as described here and that does enable adding pages of primary site’s types to the secondary site but that still doesn’t make the page types list properly for both sites in Dashboard > Pages & Themes > Page Types and also there’s the fear that hacks circumventing what the UI is guiding you to do like this might have some adverse effects down the line.
I also had the idea of duplicating the site types with prefixed handles on the secondary site’s side but I would like to avoid actual duplication if at all possible.
So, shared page types between two peas in a multisite pod. How do?
I think there might be some miscommunication here. By setting sitetypeID to 1 for the second site, you’re making it so that the second site adopts the page types of the first (default) site type. At that point, none of the page types used in the second site type that you made would be used for the second site, because it is no longer of that type.
In general, the “type of site” you’re building is what you should use to determine whether you want a second site type or not. So if the two sites you’re building are very similar, it makes sense that you would want them to use the same ‘site type’ which would cause them to share page types, skeletons, etc… So you’re on the right track by setting the site type to the initial default type, because you’ve already started building your default site out with this site type.
In a perfect world, you’d probably keep the original site mostly empty, and create a second site type entirely, and use that site type for both sites, which would be new - sibling site a and sibling site b. However, since content build-out has already started I would recommend proceeding with updating the secondary site’s siteTypeID to 1 and proceed from there. I’m really not sure what “still doesn’t make the page types list properly for both sites in Dashboard > Pages & Themes > Page Types” means. The way you’re describing it, this update is working properly. Additionally, don’t worry about having to set this field by a slightly hacky way: you’re right that it isn’t ideal, but this is mostly as confusing as it is because we have to support both complex multisite setups and making site types and skeletons, etc… understandable and mostly hidden out of the box
Thanks so much for the reply and clarification, Andrew. Any inconsistencies in my explanation can probably be put down to sheer confusion around the sparsely documented topic, the layers involved and blindly testing whether hacking it like this would work. (Still a little unsure about the skeletons’ function but maybe I don’t need to dig into that with this project.)
I took your advice of not worrying about the method of achieving it, dared to make the db change in Staging and it looks like I have the page types now working across the two very samey sites. Right on time for content sprint.
Great! Glad to hear it. Yeah, you’re not wrong about it being sparsely documented: the differences between sites and site types and how to use them is pretty in the weeds. Glad to hear it’s working in time to be useful.
You’re running into one of the less obvious parts of how Concrete CMS multisite is structured what you’re seeing is actually expected behavior, not a bug.
In Concrete, page types belong to a site type, not directly to a site. When you created the second site, it was assigned its own site type, so it got its own isolated set of page types. That’s why:
You can’t see the primary site’s page types on the secondary site
You can’t recreate them with the same handles (they already exist globally)
Changing siteTypeID in the DB “kind of works” but breaks consistency (and yeah… that’s definitely not a safe long-term solution)
The clean way to handle this
If you want both sibling domains to share the same page types, they need to share the same Site Type.
So instead of trying to sync or duplicate page types, the correct approach is:
Assign both sites to the same Site Type from the start
Unfortunately, once content is already built under a different site type, there’s no clean UI-based way to merge them. That’s why your DB tweak partially worked it forced both sites to reference the same definitions but it bypasses important internal mappings.
Recommended options
Option 1 (Best, if still early in development):
Recreate the secondary site using the same Site Type as the primary
This ensures:
Shared page types
Shared templates
Consistent structure
Option 2 (If you already built a lot on the secondary site):
Keep both site types separate
Move shared logic into:
Your custom theme
Reusable blocks / block types
Single pages or packages
Then manually recreate only the necessary page types per site
Not ideal, but safer than forcing DB-level changes.
Important clarification
Page type handles are global, but their configuration is scoped by site type. That’s why you’re hitting the “handle already exists” issue—it’s one of those design decisions that makes sense internally but feels restrictive in multisite setups.
What not to do
Avoid editing siteTypeID in the database going forward
Don’t try to “clone” page types by duplicating records manually
Don’t rely on prefixed handles unless you’re okay maintaining two separate systems
Practical takeaway
Think of Site Type as the blueprint layer.
If two sites should behave the same structurally → they must share the same blueprint.
