First up I have not installed or used this yet, but...
I'll definitely check it out. In the description you say that you are not writing out items that are hidden from nav. This seems a bit counterintuitive as the sitemap file should show all pages in the site. I could understand if it does not show unpublished ones, that definitely makes sense, but a site can have many more pages that can be accessed that are not show in nav controls.
Thanks for taking the time to comment and let me know what you think, I'll add a setting in the config file to choose if the hidden pages show in the sitemap then, I'll also add the same sort of support for pages with restricted access.
Content creators will definetly want all their hard work indexed by search engines no matter what the nav is :) Interested to see what you mean by and what you do with "pages with restricted access"?
Just because a page is referenced in the sitemap it doesn't mean search engines are going to care, or 'index' it better. To be sure, if they don't know about it at all (because it's not referenced in the content OR the sitemap) then it can't be indexed, but to say that ALL pages *should* be in the sitemap is a misconception.
There are truths in what you say, but it's not a hard and fast line that one can take on "this is the way it is", it's not always the way you want it to be.
Google doesn't guarantee that we'll crawl or index all of your URLs. However, we use the data in your Sitemap to learn about your site's structure, which will allow us to improve our crawler schedule and do a better job crawling your site in the future. In most cases, webmasters will benefit from Sitemap submission, and in no case will you be penalized for it.
Often there are pages on a website you explicitly don't want in the sitemap, for other reasons, so the counter argument can be made. I don't think there is any relation whatsoever with any kind of property you might have on a document type that isn't explicitly set up as a discriminator for this purpose (and especially not using built-in magic properties that many people actively try to avoid!). A better idea, in my little opinion, would be to rely on a property named for this purpose, such as 'HideFromSitemap'.
Yes I can see where you're coming from and totaly agree, but that might not always be the case so an option to enable/disable hidden pages would be best and what I mean by a restricted access page is a page that requires the user to log in before the content can be viewed because I can't imagine everyone wanting search engines crawling pages that just display "please log in".
Thanks for the info grant, I cant remember if there's an umbraco property already available that's like 'HideFromSitemap', but it's definatly something I've already looked into doing and wanted to add in soon!
No, there's not an 'Umbraco conventional property', to provide a term, and I'm glad. Your package should support an optional property, but it should be well defined as part of the project what it should be, (with an unique-as-possible alias, just as if you were naming assemblies and namespaces, to minimise conflict with other projects).
Not showing hidden from menu items seems inappropriate for this package
First up I have not installed or used this yet, but...
I'll definitely check it out. In the description you say that you are not writing out items that are hidden from nav. This seems a bit counterintuitive as the sitemap file should show all pages in the site. I could understand if it does not show unpublished ones, that definitely makes sense, but a site can have many more pages that can be accessed that are not show in nav controls.
I'll be sure to check thos out though.
Hi Mark,
Thanks for taking the time to comment and let me know what you think, I'll add a setting in the config file to choose if the hidden pages show in the sitemap then, I'll also add the same sort of support for pages with restricted access.
Luke
Content creators will definetly want all their hard work indexed by search engines no matter what the nav is :) Interested to see what you mean by and what you do with "pages with restricted access"?
Just because a page is referenced in the sitemap it doesn't mean search engines are going to care, or 'index' it better. To be sure, if they don't know about it at all (because it's not referenced in the content OR the sitemap) then it can't be indexed, but to say that ALL pages *should* be in the sitemap is a misconception.
There are truths in what you say, but it's not a hard and fast line that one can take on "this is the way it is", it's not always the way you want it to be.
From Google:
Google doesn't guarantee that we'll crawl or index all of your URLs. However, we use the data in your Sitemap to learn about your site's structure, which will allow us to improve our crawler schedule and do a better job crawling your site in the future. In most cases, webmasters will benefit from Sitemap submission, and in no case will you be penalized for it.Often there are pages on a website you explicitly don't want in the sitemap, for other reasons, so the counter argument can be made. I don't think there is any relation whatsoever with any kind of property you might have on a document type that isn't explicitly set up as a discriminator for this purpose (and especially not using built-in magic properties that many people actively try to avoid!). A better idea, in my little opinion, would be to rely on a property named for this purpose, such as 'HideFromSitemap'.
Yes I can see where you're coming from and totaly agree, but that might not always be the case so an option to enable/disable hidden pages would be best and what I mean by a restricted access page is a page that requires the user to log in before the content can be viewed because I can't imagine everyone wanting search engines crawling pages that just display "please log in".
Thanks for the info grant, I cant remember if there's an umbraco property already available that's like 'HideFromSitemap', but it's definatly something I've already looked into doing and wanted to add in soon!
No, there's not an 'Umbraco conventional property', to provide a term, and I'm glad. Your package should support an optional property, but it should be well defined as part of the project what it should be, (with an unique-as-possible alias, just as if you were naming assemblies and namespaces, to minimise conflict with other projects).
Yes, I've already taken that under consideration, thank you anyway. :)
is working on a reply...