Tools that record XPaths tend to generate extremely specific XPaths. As you have realized, this makes for brittle locators. The challenge with identifying elements in a dynamic structured document, like HTML, is to make the xpath specific enough so unrelated elements are not captured, but general enough so minor changes to the page don't break your application.
Simply put: less is more.
Use HTML attributes to help filter the elements captured by your xpath expression. The tool might give you:
/html/body/div[2]/main/section[4]/aside/div[1]
How many aside tags exist on any given page? Probably not many. We can simplify the xpath:
//main//aside/div[1]
And then what about that div inside the aside? It has a class name that is pretty unique: sidebar-ad
//aside/div[contains(@class, "sidebar-ad")]
As long as that div tag has that class and resides inside an aside tag you should be fine.
Better yet, tell them they need to add specific attributes that your code looks for. Custom data attributes will work fine and validate as HTML:
<div data-yourproduct-sidebar-ad="something useful for your code">
Your xpath can simply be:
//*[@data-yourproduct-sidebar-ad]
That will be just about bullet proof.
You need to get creative and understand xpath expressions. Learn that the tool will give you a brittle expression and that you need to optimize it. Or give your clients some tokens your code looks for in order to do something.
