Digital & SEO

I think I have found the problem.
I have been able to verify that the theme I use (BeTheme) does not update the modification date, but if I do it from the WP editor itself, it works perfectly.
So I understand that it is not your fault.
I have reported the problem to the theme but they are not paying much attention to me (the theme is dipo divi, Elementor, etc…).
I don’t know if you have contact with them internally so that they can pay more attention, because all the clients that use that theme with your Yoast SEO plugin, the sitemaps “are useless” if they don’t update the date.
Thank you.

Hi,

Natively, as far as I know, from the page listing I can’t see the page modification date. or yes?

I had to install a plugin and that leads me to confusion, because you asked me for the modification date as if it were something that the WP incorporates.

I would appreciate if it can be done, tell me how without having to have a plugin.

On the other hand, yes, this date that you tell me appears in the WP PAGE LIST

Thanks.

Hi,
The problem is not that the date is incorrectly configured in the settings.

The problem is that even if you update the HOME PAGE (it really happens with any page), the modification date in the sitemaps does not change.

Thanks

I update adding the question of whether it is compatible with WP 5.9, since currently, from WordPress it indicates that it is compatible up to 5.7.5.
At the same time, it would be good to know about the PHP that the @noubba1982 comments to know until what version is compatible.

It seems great to me and to all users ??

Regards.

Any news on the subject?
The problem persists in many forums with CF7 and Google Recaptcha 3.
Thanks.

I already did all the “typical” tests such as changing the theme or deactivating plugins and everything remains the same.
It only occurs in responsive (or emulating a mobile device with a browser).
On the desktop it works perfect.
It shouldn’t be that way because there is no PHP change between one device or another, just CSS.
But it is what happens, and it is the strangest.
I have been able to verify that there are many cases of people that the same thing happens from version 5.1. Before that version there was already a bug that “in principle” was fixed. But it’s not like that. There are still problems with CF7 and Recaptcha v3.

Even if there is a noindex (just like when in the robots file you disqualify a directory) google can index it the same. So, if for a remote case it is indexed, it is interesting that it has a canonical URL.
I do not know why the plugin was programmed according to the deactivation of the canonical url, I think it is better to have a canonical url than not, no?
Also, I think that if a user “forces” a canonical url to come out the plugin should allow to use that canonical without problems, right?
I mention it because maybe I only have this perspective of this functionality and I would like to know if I am wrong or not (on the subject that if someone “forces” the url that can be used)