I was reviewing one of our client websites and found few issues which are considered to be SEO pitfalls. Would like to share this, I am assuming that most of us already know this, but, in this myriad of things we need to keep a tap on, it is almost necessary to remind ourselves just how important SEO aspect for the website you will build actually is. Sitemap is almost an inherent choice and much needed one to submit to the search engine giants in some way or choice.
But, it is essential to remember what not to push to sitemap as crawler is busy doing it’s thing and indexing every bit of your fresh content as much as it can. Few things to always remember –
- Ensure to not add any urls that either do not have any content or could lead to 404. This is very essential to make sure we are not asking crawler to even for a milli-second think about pages that are not important and this will help ensure you don’t set up your own pitfall towards having a red mark on Google for instance. You can do this by providing a way to either exclude content or templates when sitemap is being generated, easy enough. But, is often missed. 🙂
- Now, if you are using any folders or intermediate content for just solely organizational purpose, ensure you have proper redirects in play to make sure if some one is either being smart or received an improper url, your set up does a terrific job of placing the end user where you wish him/her to be looking at when they pull up your site. Magic, yeah. lol. For the other side of users which is your content authors, ensure you have proper insert options and templates filled in with beautiful presentation that would then take care of all in the background keeping content authoring simple and easy peasy.
You do not have such fancy sitemap generation on your sitecore instance? Look the following options which are my favorite. Setting these up should be real simple, but, as always tricky part is maintaining the solution and training some one who uses it to know these things that they can do to keep crawlers in check.
References / Suggestions
https://github.com/JimmieOverby/SitecoreSitemapXML — My Personal Favorite with more customization
Tons of other modules on market place, explore more:
Happy New year to one and all! It is always an awesome feeling to welcome the new year and leave behind what was done in previous year in memories. The beauty of memories, they can be good, bad or worse and everything in between, but, regardless, we are set to move forward to make new memories this year, new learning and potentially reach new heights. 🙂
I was waiting to find perfect topic for my first blog this new year. I think I just found one, so, I was working for one of our clients who wanted to see, how many options do they have to share content across multiple sites on a Multi site single sitecore instance. They currently use wildcard mechanism with multiple sites configured to have different root paths, but, the content resides in one area regardless of which site the piece of content belongs to.
Why would they want to see other options is that they strongly believed that content structure they use the problem for performance issues, which, well could be legit as a risk that comes with meddling any pipeline while not being cautious.
Below are the three options I could find from brainstorming, research and asking other folks to top off the wild card approach they already have in play. Do you all have any other options that you have used in the past, if yes, would love to hear more. Drop in a comment!
- Hybrid tree approach : This is basically going with shared root path approach if the page tree is consistent and is exactly similar. If the page content is going to be different, then, for that specific site configuration you will need to define a different root path and main content in a separate tree altogether.
- Clones: I have seen many old implementations that would go this route in shared content situations, but, struggled a lot with intuitive changes and workflow, publish issues faced by content authors.
- MVC Routing : If your application is using MVC, then, this could be one decent solve instead of wild card and ten other pipelines being affected to support wild card. Note though, when using some of this as an experiment the routing code was literally running for every module when a breakpoint was placed. Pay close attention to where this logic is being run and how performance efficient this is.