SEO in the context of Sitecore is only one (very important) part of the successful planning, development and launch of a web presence. Companies using Sitecore are large and are likely already considered "reputable" or "trusted" by search engines due to their age, traffic, and size. Therefore, these sites have a greater ability to rank new content simply by producing it. As a result of the high traffic, it is also more likely that published content will be shared on various social platforms. For this reason, proper on-page SEO is particularly important for these sites.
Sitecore ships with virtually no SEO functionality (with the exception of SXA which includes some basics). The responsibility is therefore left to the customer and implementation partner. If the implementation partner lacks the skill or expertise in this area the project runs a risk of experiencing various issues, not limited to SEO.
The sections below cover the most impactful areas with the greatest ROI. These apply to various stages (and stakeholders) of the project lifecycle:
Stage 1: Planning
URLs & Canonicalization
Selected URLs should be carefully planned to leverage any existing search engine "trust" and "authority" associated with domains, subdomains, and inner pages.
Let's kick off the project by referring to the site with its true name (AKA canonical). What is the final production URL of the website you are building? URLs are structured as follows:
- https://www.companyname.com (most basic example)
- https://companyname.com (no subdomain, or rather that if anyone requests the www subdomain, they are redirected straight to the domain)
Your scheme should always be HTTPS, and all HTTP requests should force redirect to HTTPS. Search engines are beginning to favour secure websites over non-secure websites. Having a non-secure site is no longer a viable option in most cases.
Lastly, one of Sitecore's most powerful features is that content can be shared across many different sites. Therefore it's important to consider which site should be given credit for that content. For example,
main-site.com has the same blog post as
microsite.mainsite.com. In all likelihood,
microsite.mainsite.com should have in the
<head> tag a link to the canonical version of the blog post:
<link rel="canonical" href="https://main-site.com/blog/post-name/" />. The
<link> tag is powerful and can be used for other purposes such as language information.
Www Vs. Non-www
Some companies possess internal IT infrastructure that uses the non-www URL and thus they MUST use www as the public website canonical. Otherwise, www or non-www is a matter of preference. If your organization prefers having www, the non-www should force redirect to the www and vice versa.
Decide on the subdomains for your various environments. For example:
- qa.companyname.com (quality assurance)
- uat.companyname.com (user acceptance testing)
- staging.companyname.com (staging)
- cm.companyname.com (content management)
- companyname.com (content delivery)
Requirements and infrastructure will vary among companies and will dictate which environment subdomains may be required. This will also be influenced by which Sitecore license and services / infrastructure the customer has purchased.
Company Sites Vs. "Branded Verticals" Vs. "Microsites"
Before starting a website project, an organization should be clear about the purpose of the website. Examples:
- https://companyname.com - A main corporate website.
- https://campaignname.companyname.com - A "branded vertical" in which you make it clear to the visitor that this website is closely related to the company but is distinct or specific enough to warrant having a subdomain rather than existing direcly on the main corporate website.
- https://randomsitename.com - Also known as a microsite that is contextually "separate" or distanced from the company's brand.
In addition to the above, one must also consider how Sitecore can serve up websites. If you have a single instance of sitecore but need to serve up multiple sites, you must use separate domains / subdomains for each site. Serving up seprate sites under inner pages "/other-site" can cause unexpected behaviour. Plan your websites and domains accordingly, starting with your organizational goals. Then, explore these technical considerations.
Analysis of Existing and New Information Architecture
- Audit the existing backlink profile and URL structure to determine which 301 redirects may be required, with the goal of nurturing and recovering all authoritative sources (ensure existing backlinks continue to function -- they are an important component in maintaining your own authority).
- Get a spreadsheet dump of all of the current page URLs, titles, and descriptions. Various free website scrapers exist for this purpose such as Screaming Frog.
- Map out how the existing pages will redirect to the new IA.
- Identify pages and URLs that are being referenced by your various marketing campaigns, including PPC landing pages.
- Determine what the URL, meta title, and description should be for the new content.
Stage 2: Development & Setup
Pages & Components
- Ensure that components have proper heading tags (h1, h2, h3) in relation to the pages and sections that they will exist in. Heading hierarchies should be well understood and implemented when building pages and components.
- Enclose rich text fields in elements, or an element that supports nesting of any element type.
- Avoid hardcoding readable text in favour of editable fields to take advantage of customization and multilingualism.
- Build all pages / components with "mobile first" in mind. Ensure your designers are providing adequate comps with this in mind.
- Validate the HTML of pages and components once completed.
- Implementation partners must work with the customer to determine which SSL certificates need to be purchased or accessed.
- Carefully determine the certificate type(s) that suits the customer's needs: single domain, wildcard, single subdomain, multiple subdomains, etc.
- Have a plan in place to update the SSL certs as they expire. Automate if possible!
- Set up calendar reminders around critical certificate expiry dates. Many companies, even the Googles and Apples of the world have failed to do this in the past, leading to critical service disruptions.
Page Load Speed
- Images should be resized and compressed as they are added during development.
- Media Library items in Sitecore should always have their "alt" text field descriptively filled and it should always display when rendering images.
- Consider using a fast DNS solution such as CloudFlare to decrease page load time.
- Consider using a CDN solution such as CloudFlare to decrease page load time.
- Optimize front end assets by consolidating and minifying CSS/JS files. Use as few as possible. Avoid including large open source libraries when possible.
- Prioritize display and loading of "above the fold" content (content that is immediately in view on page load).
Build out navigation HTML in a flat and simple manner (avoid excessive nesting and lists) so that crawlers can easily consume the HTML. SERP results can benefit from this by displaying direct links to popular / important pages derived from navigation code.
<a> Tags (Links) & Anchortext
- External links should specify the target attribute as "_blank" to open the links in a new tab so that the user is not directed away from the site.
- Inner page links (links to other pages on your site) should specify the target attribute as "_self".
- The rel attribute is an important consideration. Important values include "nofollow", "noreferrer", and "external", all of which should be added during initial development where appropriate.
- Anchortext should be descriptive (avoid "click here").
- <a> tags should have descriptive title="" attributes.
Unfurling (Sharing the Site on Third Party Websites / Apps)
The most popular method of sharing a website is to simply post a link to it on social networks, apps, and so on. Display results will vary on different platforms. One should have an understanding of how the most popular platforms display shared websites and structure HTML and content accordingly. We like to use tools such as unfurls.co as part of the analysis. Standards such as Open Graph (http://ogp.me/) are also worth exploring.
Page Template Fields (Meta Fields)
- Page templates should include "Meta Title" and "Meta Description".
- Include fields as necessary for schema / Open Graph.
Plug In To The "Google Grid"
Implementation partners should ensure that the following is integrated before golive:
- Google Search Console
- Google Analytics
- Google Tag Manager
- "Soft" 404s that don't return the proper error code can be intepreted by crawlers, but by leaving it open to interpretation you are giving up control and power to an algorithm rather than being able to dictate your own outcomes through proper implementation.
- At the very least, have a human readable 404 page even if it isn't perfect rather than redirecting 404s to other pages.
Page and Content Structure for "Google Knowledge Graph"
If the site has enough authority and the proper HTML / content structure in "answering" specific queries, these pages will be given priority over other SERP results. This is also known as "position zero".
This is especially important for larger websites with thousands of pages. This document tells search engines which web pages you have created and decreases the consumption of your "crawling budget".
Robots & Indexing Options
Content authors should be able to specify which pages and directories should be crawled and indexed via added page fields and an ability to modify their robots.txt file.
Stage 3: Pre Launch
DNS Flipping & Coordination
Implementation partners should work with clients to create a plan of action to "turn the website on" by updating the DNS. Careful planning and execution is key because DNS changes are difficult or impossible to test before golive. Additionally, if mistakes are made, confirming the changes is difficult due to the time that must pass while DNS changes are propagated throughout the internet. Having an excellent DNS provider such as CloudFlare will help in quickly propagating DNS changes for faster verification.
Using the analysis and documentation from the SEO planning phase, implementation partners must carefully apply the necessary changes to ensure proper redirection for the following cases:
- Secure Canonicalization redirects.
- Old pages redirecting to new pages.
- Old directories / paths to new directories / paths.
- Handle redirects at the web.config level so that you can properly accept and redirect secure connections. Redirects at the DNS level cannot happen if the initial request is secure (HTTPS).
- Handle redirects for URLs with file extensions if necessary (ex. /resource.txt to /updated-resource.txt).
Redirects are difficult to test until after golive. All redirect rules should be concise and not overly lenient, else you will risk unexpected redirects. ALWAYS test regex redirect checks. Avoid using regex examples from the internet that you do not fully understand.
Pre Launch Checklist:
- Run page speed tests (desktop & mobile) -- simulate 3G connections if necessary
- Test for mobile friendliness
- Ensure analytics and all third party integrations are included in page layouts
- Check for console errors on all pages
- Review page titles, descriptions, alt-text, open graph, pagination, and structured data
- Review robots.txt and index / follow declarations on required pages
- Confirm that all content has been migrated
- Check for mixed content warnings (when non-secure resources are referenced on a secure page)
Stage 4: Post Launch
Post Launch Checklist:
- Confirm all SSL certificates are functioning as expected
- Monitor site migration and changes pre and post launch to ensure authority/ranking is maintained and growing
- Monitor analytics to ensure traffic / authority / backlinks are preserved
- Do all redirects work as expected?
- Is your publishing workflow set up for success in SEO, security, and ease of use?
- Are SEO best practices built into the content approval / publishing workflow?
- Are content authors trained on best practices for linking to other websites? Inner page linking? Links in general?
- Is image size optimization a part of your workflow?
- Confirm Google Search Console integration
- Confirm Google Analytics setup integration
- Confirm Google Tag Manager integration
- Ensure that all business locations / branches have set up and are properly managing and updating their Google My Business & Google Maps assets
- Submit new sitemaps to Google Search Console and Bing Webmaster Tools
The tips above provide a solid foundation for SEO success. During a Sitecore project buildout, the highest priority should be to plan aspects of SEO into the work, and to ensure that nothing is majorly broken in terms of on-page SEO.
If more sophistication is required, explore schema / JSON-LD, AMP, on page social sharing, and more. However, these aspects of SEO often have a poor ROI as compared to the foundational aspects such as proper URL planning, meta titles, descriptions, page load speed, canonicalization, mobile friendliness, earned authority via relevant backlinks, valuable and easy to read content, proper categorization of headings, and a simple HTML structure.
If your organization lacks the in house expertise to properly plan and execute these aspects of your Sitecore project, contact us. Fishtank offers full lifecycle SEO planning and implementation.
All the best,
We're on the look out for talented developers to join our team.
Think you have what it takes?