The SEO page has a default option to not include hidden pages in the SiteMap.aspx file. The default option of off is still including these hidden pages in the sitemap.aspx
List the precise steps to reproduce the bug:
If the default option to exclude hidden pages is checked, then these pages should not be shown in the Sitemap.aspx file.
SEO page setting default
https://bfb30d4aa283201c8ae6-fa4f287ec88b082f34d8962c0b5f36f7.ssl.cf2.rackcdn.com/assets/SEO.png
Example Sitemap.aspx return
https://bfb30d4aa283201c8ae6-fa4f287ec88b082f34d8962c0b5f36f7.ssl.cf2.rackcdn.com/assets/sitemap.png
Provide any error information (console errors, error logs, etc.) related to this bug.
Provide any additional context that may be helpful in understanding and/or resolving the bug.
I have additional details on this that should help in debugging as well as provide a workaround. Since the workaround is easy, it is my very-humble opinion that this is minor and should not hold up the release of 9.07.00 (currently at RC2). These details/steps should make it fairly easy to devise a fix for this. I believe this problem has existed for a while.
In brief:
After an install, PortalSettings does not have the 5 records for SiteMap* settings. The image below shows the settings after they have been written/created.

In this state, Sitemap Clear Cache and the SiteMap generator do not do their job properly, you just get a default spew of the 6 or so initial pages including the Activity-Feed pages which should not be showing.
The workaround is to go to Settings, SEO, Sitemap Settings tab, change any setting under GENERAL SITEMAP SETTINGS and Save (then change it back and hit Save again). This writes the 5 settings to the PortalSettings table and after that, you must go to Settings, Servers and Restart Application (and wait a few seconds). Then everything works as expected. e.g. change a setting on a page (set Display in Menu to false), go to SiteMap Settings and Clear Cache, then reload SiteMap.aspx and you should see changes and all page (and SiteMap) settings respected in the output.
To drive the point home,
I have confirmed the work around solves the issue on my production and test installs.
We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!
This issue has been closed automatically due to inactivity (as mentioned 14 days ago). Feel free to re-open the issue if you believe it is still relevant.
This is still an issue. Exists in 9.8.
This really should not be closed.
I can confirm it's still an issue in 9.8.0
I'll take this one, just wanting to confirm @jeremy-farrance that after doing the above of saving settings all is good, it is simply the missing values that are the issue?