вопрос в том, как удобно организовать обновление эталонов

Что значит удобно в данном случае? Мне вот удобно.
Таска которая пробегается, и сохраняет все урлы проекта, которые я в конфиге указал.

И другая таска которой можно например в csv файле скормить те урлы и/или селекторы по которым надо пробежатся

Хотя с селекторами уже сложнее.
Надо какое-то условие придумывать, тип если зашли на страницу х то один набор, страницу у другой набор

Думать для какой страницы какое значение допустимых расхождений

Тестируйте компоненты UI отдельно. Если у вас они организваны вот так, то при помощи одного из этих инструментов вы сможете устанавливать свои компоненты в нужные состояния.

Привет! Какие именно у Вас проблемы с вариативностью?
Из опыта
1) Какой то кусочек экрана нельзя контролировать (например часики тикают)
- ищем решения чтобы исключить (вырезать) его из проверок
2) Анимация играет в цикле
- ищем решения чтобы перемотать ее на определенное состояние (последний кадр) - можно через CSS
3) В целом полезно замораживать состояние данных на экране для такого тестирование (mocks, тестовые данные)

и да - на уровне тестирования отдельных компонентов (как пишут выше) эта проблема решается легче - всякие сторибуки очень помогают

да проблема на самом деле на поверхности, только решение я найти пока не смогла сама, может оно конечно тоже на поверхности...Ну самый простой пример - есть страница с набором разных карточек, допустим портфолио, оно естественно периодически обновляется, порядок карточек меняется, то есть если я допустим сделаю и сохраню скрин первой карточки в списке, то при следующем тесте первой может оказаться другая карточка (с другим текстом, бэкграундом) и хотя состояние у нее будет норм, но фреймворк посчитает это как дифф и выплюнет fail.

вот по п3 - В целом полезно замораживать состояние данных на экране для такого тестирование (mocks, тестовые данные) - вы могли бы подсказать куда копать?

я с таким еще не работала, или это зависит от реализации проекта?

Один мой товарищ очень хороший Javascript'ер сделал хорошее решение
https://github.com/zaqqaz/visual-unit-tests
идея в том что регенерация эталонов происходит на стороне CI - когда эталоны не совпадают то  разработчики могут попросить CI их перегенирировать в Pull Request'е

его презентация про это
https://denis.by/visual-tests/#/

да, кастомные решения есть, много кто их делает, я про это и написал. а вот готовых "коробочных" решений я пока не встречал

из готовых коробочных - applitools

Ну я же про это и писал выше. Делается плейбук, в нём все компоненты UI. Затем берём инструмент под свой любимый фронтенд-фреймворк, через него устанавливаем компонент в нужное состояние и сравниваем с эталоном.
Гляньте статейки-то )

зависит от проекта и технологий

пожалуй, да. но он сервис, локально не развернёшь...

@FindBy(xpath = "")
List<WebElement> menuLinks;

здесь один общий xpath на список. мне надо 5 элементов списка для каждого свой путь

просто решение со скриншотами жталонными цепляет несколько компонентов и его как селенид одним махом не воткнешь
1) нужна механика снимать эти скриншоты
2) нужна среда чтобы они были одинковые (docker)
3) нужна штука которая будет гонять тесты рендерить новые скрины и проверять их против эталона (проверки могут быть как в лоб так и что то умное (вырезка регионов, итд)
4) нужен репортинг чтобы красиво показывать разницу
5) нужен CI pipeline который гоняет 3-4
6) нужен CI pipeline который регенирирует эталоны и запускает 5

про селенид то же самое можно сказать — нужны браузеры, нужна инфраструктура для их запуска, нужен репортинг, нужен пайплайн, чтобы все это запускалось

просто пока никто не сделал :)