Ah that’s right, I was thinking of item-level slugs, not field-level-slugs.
If you read the thread here, @bart laid out a general approach, however I think that it
will not work if you have already used the field name you want in the past. You’d have to create something new, e.g. name it
Sticky Heading 1 and get
sticky-heading-1 as a slug.
The reason for this is two specific behaviors in how field keys are generated;
- Every new field you create gets a unique field key generated, e.g.
Field 1 becomes
field-1. That key is permanent internally, and appears in the API, even if you rename that field later.
- Even if you delete a field, Webflow remembers the key you used, and prevents you from using it again. Instead, it appends a suffix like
-1 to make it unique.
Here’s a simplified view of how field-key generation appears to work in Webflow.
In my case, I “fixed” it by completely exporting the collection as CSV, deleted the collection, recreated it carefully, and then reloaded the CSV. If you really need that field name in your JSON, I think that’s the only way to go, and I’ll explain why that is, later.
However that Collection rebuild can be painful. If this is a live site, with a big collection, and lots of refs into it, and is bound to a lot of collection lists… then this is going to be a bit like 3am open-heart surgery.
If the site draws visitors globally 24/7, you’ll be doing that surgery on a moving train.
I happen to do that kind of thing much too often, so if you need to, here’s how I’d approach this;
[ OC = old collection, and NC = new collection ]
- Back up your site, in case of emergency.
- Pause any external systems or automations that are reading/writing data from OC.
- Block any FORMs or user actions that trigger those external automations.
- If this is a busy site at 3am, consider taking it “offline for maintenance.”
- Export your CMS Collection content as CSV
Phase 1- Move the old Collection
- Rename your OC’s Collection slug. I’d append an
-x, to differentiate. There’s a chance users could see this, so you don’t want e.g.
- To your OC’s Collection Page, add a
<meta name="robots" content="noindex"> to the
</head> custom code. We don’t want Google indexing this page at the temporary path.
- Publish live, to make sure everything is sync’d at Webflow’s back end.
- The site will still be 100% functional, just with that
-x in Collection Page URLs.
Phase 2- Create the new Collection
- Create NC, your new CMS collection at the same slug OC was originally at.
- Be very careful to name the fields correctly, once, and to never rename them ever.
- Create one record in your CMS
- Verify the JSON through the API, to make sure you have exactly what you want
- Load the CSV into the new Collection
Phase 3- Switchover
- Fix any Ref fields in other collections that are referring to OC, they now need to refer to NC, and you’ll have to update that data.
- You can find these in part by deleting all of the items in OC. Any that are linked to from other Collections will throw errors, and help you find that linked item.
- Build out your NC Collection Page. On your OC Collection Page, you can unlink OC-bound items, and then copy those elements over to NC, and re-bind them. Yeah, I know. Agonizing.
- Finding these OC connections is made much easier by Webflow’s “View Connections” tool, which you can find at the bottom of OC’s Collection Settings page in the CMS.
- Copy over your custom HTML Head and Body code, but obviously not the
noindex meta we created above.
- Publish to Staging (
webflow.io ) only. Verify that the new Collection Page is functioning properly, and the data looks good.
Phase 4- Switchover Cleanup & Validation
- Delete OC
- If anything is still bound, you’ll get errors… fix those bindings
- If any other collections reference OC, change those to reference NC.
- Publish to Staging, retest your changes
- Publish to Prod
It’s 6am now, go celebrate with a beer.
Note that Webflow’s rich text fields have a link-builder with the ability to link to a specific CMS item- however that link is not tracked. If you rename that collection, or change the item slug, that link will not be updated and users clicking that link in your blog / press release / uni course will get a 404. However, in this particular workflow, your NC will end up at the same slug, and with the same item paths that OC had - so at the end of the operation, all of those links will work fine again.
So why is this insanity needed?
Interesting stuff, but that part got too long, so I’ve done a blog post here.