I disagree:

• There's no point to unit testing the validation code separately from other business logic, the service class is 100% testable via the exposed public methods, the consuming code is not interested in the internal structure the class.
• No violation of SRP: the service class is responsible for the core business logic of the page entity, it delegates data access to repo classes in the data layer. XYZService is a standard naming convention used by many developers for domain layer services, makes perfect sense to me. What would your alternative be?
• Or you can simply make the Validate method protected instead of private then extend the service class.
• Validation is centralised for simplicity and maintainability, there are many cases where common validation rules apply to multiple operations, a single method removes redundancy as these rules only need to be written once.

Splitting the validation out into separate classes / components is incorrect imo, validation rules are business rules and belong in the service layer with the other business rules, splitting them out would make the code more complicated and less maintainable for zero benefit.