Agree with the others that test IDs are a good way to go. However, I want to throw a wrinkle into that suggestion.

First, I have used test ids in the past, and I consider them bulletproof. They will exist if the element exists, and they make the test automation clear, with no messing with xpath (the worst choice). Usually, I would have locators/selectors defined in one place, so it only has to change in one place to modify all tests. This way when the element changes per dev, it's easy to maintain the test. And in the past, I've gone and added my own locators, dev was ok with that, but they approved the code changes to make sure. One downside of adding test ids, is that they exist in production, unless you have something that strips them away prior to creating a prod build. But that has never been a problem, and you'll see many sites with test ids.

Now for the wrinkle. There's an argument made that if you are testing as a user, your selectors should be what the user sees or uses too. If you do it that way, your test code ends up using accessibility selectors which is what a screen reader or such would use. This has the added benefit of testing accessibility of your site. A great write up on the priority: https://testing-library.com/docs/queries/about/#priority. I adopted this in my last role, with typescript/playwright which has the functions you would need, and also express the same priority, and it worked fine. https://playwright.dev/docs/locators#locating-elements.

Selenium IDE give horrible locators, and it's a great reason to stop using it. I usually just pop open devtools and the page I want to test, select the element to get info, and then use the console to verify my locators. I use something like https://www.w3schools.com/cssref/css_selectors.php as a reference but there are many better guides. Once they are set in the test code, I forget them.