Invalid priority “default”

Hey ! I faced the same issue.

Open the AIOSEO Dashboard > Sitemaps > Scroll towards down and Check Advanced Settings > Remove Default settings and change to 0.0 to 1.0 basis your requirement. Load the sitemap again and submit to Google Search Console, it works !!

• This reply was modified 1 year, 5 months ago by funnychickdoon.

Even after setting the priorities manually in the Advanced Settings, many URLs in the category sitemap are still assigned a priority of “default”. Which is weird, because why would some category URLs be assigned the manually set priority (0.8) and others “default”, when they ought to use the same setting?

<url>
<loc><![CDATA[https://www.example.com/A]]></loc>
<lastmod><![CDATA[2023-06-09T07:17:22+00:00]]></lastmod>
<changefreq><![CDATA[monthly]]></changefreq>
<priority><![CDATA[0.8]]></priority>
</url>
<url>
<loc><![CDATA[https://www.example.com/B]]></loc>
<lastmod><![CDATA[2023-05-30T12:46:38+00:00]]></lastmod>
<changefreq><![CDATA[monthly]]></changefreq>
<priority><![CDATA[default]]></priority>
</url>
<url>
<loc><![CDATA[https://www.example.com/C]]></loc>
<lastmod><![CDATA[2023-06-01T12:14:48+00:00]]></lastmod>
<changefreq><![CDATA[monthly]]></changefreq>
<priority><![CDATA[default]]></priority>
</url>
<url>
<loc><![CDATA[https://www.example.com/D]]></loc>
<lastmod><![CDATA[2023-06-09T10:04:44+00:00]]></lastmod>
<changefreq><![CDATA[monthly]]></changefreq>
<priority><![CDATA[0.8]]></priority>
</url>

This happens even after I ungroup the taxonomy priority score settings and set a value for each one of them individually.

• This reply was modified 1 year, 5 months ago by robzy.
• This reply was modified 1 year, 5 months ago by robzy.
• This reply was modified 1 year, 5 months ago by robzy.
• This reply was modified 1 year, 5 months ago by robzy.
• This reply was modified 1 year, 5 months ago by robzy.

Hey @robzy, @funnychickdoon

I hope you’re both doing well and had a great weekend. I’m sorry to hear that you’re running into this issue.

In our latest update we modified the data type of our priority column in the database to significantly speed up loading times for the sitemap. It looks like the relevant database queries didn’t run for you when you updated. This happens occasionally for a few select users.

I’m not sure if you’re familiar and have access to your site’s database using PhpMyAdmin or Adminer, but if you do, then you can easily resolve this issue by running these two queries:

UPDATE wp_aioseo_posts SET priority = NULL WHERE priority = 'default';

ALTER TABLE wp_aioseo_posts MODIFY priority float;

You’ll need to replace the wp_ prefix for the table names in the queries with the relevant table prefix for your own site.

If you’re not familiar with any of this, please let me know and I’ll see if our support team can resolve this for you.

Thanks, Arnaud. The ALTER TABLE seems to have run OK (or had successfully run while updating), but the UPDATE query gets stuck:

Truncated incorrect DOUBLE value: ‘default’

A SELECT shows that those rows currently have a priority value of 0, so it probably gets hung up on that not being a float (or that ‘default’ cannot possibly be a value of a FLOAT field). It’s only 12 rows so I updated those manually.

That only affects posts, though. After clearing caches I still see a ‘default’ priority for about 2/3 of the URLs in the category sitemap.

Do I also need to update wp_aioseo_terms? Any other places?

• This reply was modified 1 year, 5 months ago by robzy.

Hey @robzy,

Yes, you’ll need to run the same queries for the terms table. Simply replacing the table names should do the trick.

Can you let me know whether you ran then UPDATE statement before the ALTER statement, or after? The order is important. The UPDATE statement should have succeeded as long as you ran it before and not after the ALTER statement.

I ran them as you posted them here, so the UPDATE first, followed immediately by the ALTER. But it’s possible that the ALTER still ran after the UPDATE failed because I ran them as one command (separated by semi-colon), I’m not sure.

Just updated the _terms table and everything seems to be working again.

Thanks for your assistance!

No problem, I’m glad we were able to sort that out.