The majority of the time, software developers create amazing applications that cannot be properly indexed by search engines because they are overly complex and have very complicated routing schemes. This helps to obscure the true breadth of the software's capabilities.
Therefore, it all but guarantees that the only method to acquire organic traffic to the software's website without strong saas technical seo will be through paid search marketing.
Search architecture summary
When you attempt to apply the traditional search checklist to software, you will find that it does not work. A traditional website consists of a collection of static web pages, whereas software products are built using dynamic URLs created on-the-fly based on what the user has done up to that point in time in the application or based upon what data the user requests.
There are two major challenges for a search engine concerning software products: First, the engine needs to know what pages to crawl and second, the search engine has a finite budget as to how many resources it will allocate to crawl each website.
There are many thousands of pages created automatically by the software (through the creation of user profiles, internal search results, and so on). Consequently, the search engine is wasting a lot of time finding those pages. The search engine will never be able to rank the commercial pages of your software product due to the combination of how many irrelevant and repetitive pages are available for the search engine to crawl.
To properly address this problem, technical teams must develop a search visibility strategy as a traditional engineering standard. You cannot treat organic search visibility as an afterthought; it requires an extensive plan of action for rendering JavaScript, utilizing clear server response parameters, and placing limits on what the search engine can access. Create a clean and well-defined path for search engines that leads directly to the most profitable pages.
SaaS technical SEO: How engineering works
SaaS companies spend a lot of time and money developing software but very little time developing the marketing of their software. A common mistake among these companies is mixing their marketing site and their main app into one combined site.
By separating these two sites into their own unique sections (marketing, docs, product, and developer APIs), you can prevent half of all potential mistakes before you begin coding.
A common structure that achieves this separation is to use a primary URL for the marketing site, a second URL for the docs, and a third URL for the application. Furthermore, do not use a simple text file as a way to hide confidential information.
When a bot attempts to crawl a page behind a login, it should receive a 401 Unauthorized response. By doing this, you let search engines know that the page is private and will prevent them from guessing the content behind the wall.
Establishing URL ownership
Every URL should have an owner who is responsible for making sure that URLs have clear ownership. When there is no clear ownership, developers may push out software updates that accidentally break search rules, while marketing teams may request changes that slow down the application.
In order to avoid this problem, it is important to map out every URL statically (such as feature pages, comparison pages, resource pages, and documentation pages) and to define an owner for each URL across the search, content, and engineering teams.
Marketing should be responsible for all core product and feature comparison pages, engineering for the application routes and API endpoints, and tech support for the help center.
By establishing a monitoring system and developing a procedure for detecting and correcting errors at the earliest possible time, including when to add or remove features, will help prevent problems with searching through content (and therefore inconsistently present information in search results).
How to fix the JavaScript rendering problem
Executing JavaScript on the server or client side
When crawling pages containing JavaScript, search engines crawl the underlying HTML only first (if any), and then crawl-and-render the actual JavaScript after (if any) execution of that JavaScript.
When your images, user's images, hyperlinks, and content are loaded via JavaScript executing on the client-side browser via JavaScript execution, you delay the search bots crawling. Most of the time, they do not wait to see your content before leaving your site.
The general practice of executing JavaScript on the server side provides a quick and readable page for both bot and human users immediately upon request.
When you send an already rendered page to a user from the server-side, you completely eliminate the risk of content being hidden by a broken script.
Validating the rendered output
There must be a way to demonstrate that your page is rendering properly, even if it is only through the use of basic code review and the code that is provided from the JavaScript code after running the JavaScript.
One of the most effective methods to do this is to view the raw source of your page in plain text. If the title of your page, your main content heading(s), and your hyperlinks are present in your raw source code, yet they do not appear once the JavaScript code is executed, you have a real structural issue on your page.
If there is an error with one of the scripts on your page, it will never hide the core meaning of the page. You can see exactly what the search engines see using the search engine's inspection tool.
If you notice that the rendered version appears to be very different from the raw version, you should revise your development workflow so that users can access the priority content without waiting for all the external scripts to load.
Indexing control for SaaS technical SEO
Dynamic route generation
The automation of the development process results in the creation of thousands of additional pages of content. The dynamic routes generated using filters, search options, workspaces, or integrations will only result in creating endless replications of the same content.
As a result, this leads to a bloated index and cannot be fixed with just one rule. You will need to assess each page's value to the user and the business; therefore, create a classification based on the pages' value.
If a page created from a filter has high search demand, then keep it open for indexing and ranking. For instance, a page that demonstrates how to integrate your software with a dominant email service provider would be very beneficial, and therefore you should keep it unblocked and indexable.
However, if the pages show endless replications of calendar dates or user parameters that do not provide public value, then you should block them completely and channel the search engine's indexing towards pages that have value.
Canonical tags
The canonical tag is intended to provide the search engines with a strong indicator of which version of a page should be treated as the authoritative version. If you have five different URLs for the same pricing chart, you should use canonical tags to consolidate the duplicate URLs into a single authoritative version.
Do not block duplicate content using standard block files. While blocking the URL will halt crawling, search engines will continue to index the URL without having read its content.
Due to this issue, there will be many broken links that will remain permanently in the indexes of Google and other major search engines. By using properly placed canonical tags on your website pages, you can provide a natural grouping for all of the various versions of a page together.
Managing technical documents and API hubs
The technical documents and API hubs section of your software website will likely be the largest portion of your site (most web sites contain a vast amount of technical documentation) and will contain an enormous amount of valuable content for your customers.
However, this section will also contain many very specific low-value API reference documentation that will not be useful or relevant to many end users. It will be very important for you to manage the technical documents and API hubs section very carefully.
You want to prevent search engines from crawling through and indexing thousands of out-of-date code samples (from several years ago) and customer references that are private to your company and/or to a very specific customer.
You should properly group your technical documents and API hubs; the top-level groupings will contain all of the main setup guides (for setting up and configuring your product), along with high visibility feature explanation (for explaining how to use and integrate the various features of your product) and popular integration steps (for guiding customers through the most common integration steps).
For the deep, automated code references that nobody ever searches for, you should restrict their access and/or remove them from your main site maps (sitemaps). By doing this, you will ensure that all of your helpful guides will rank at the top of the search engines when your customers have questions about your product, which is the ultimate goal of saas technical seo.
Core Web Vitals and performance strategy
Real world field data vs. lab test scores
Performance is an important ranking factor for both organic results and paid results. However, lab scores do not account for the actual experience of real end-users on older mobile devices, which can be significantly different than what you see on your high-end computer in your lab.
Therefore, do not focus on achieving perfect lab scores on the high-end machines. Focus instead on actual user measurements that have been collected in the field.
The following are the expected basic performance health requirements from all search engines:
Largest Contentful Paint should load in 2.5 seconds or less.
Interaction to Next Paint should occur within 200 milliseconds.
Cumulative Layout Shift must remain at or less than 0.1.
Common speed blockers
Common causes for software sites missing the above performance checks are related to the usage of third-party scripts. Multiple tracking, chat box, and "consent managers" can prevent the main text from loading properly.
Additionally, large video headers and unoptimized web fonts can cause page jumps while loading.
To avoid all these problems, try to move as much processing away from the initial load sequence as possible and delay loading chat widgets until they are actually activated by a user or when the user scrolls down on the webpage.
Use "placeholders" for where images will be displayed prior to their loading to prevent the text from jumping around the page as items load. Fast-loading pages are key to keeping users satisfied and proving to search engines that your website has solid architecture.
Structuring internal link authority
The authority of an internal link moves from the strongest pages of your site to the pages that contain your newest content. Don't simply connect everything from your main menu. Create a logical hierarchy of connections based on the information architecture of your website.
Your homepage links to your category pages. Your category pages link to the features within that category. Your feature pages link to the appropriate guides and integrations.
Having this clean link structure makes it easy for search engines to determine which pages of your website are the most important. It’s vital that you check at least once per week to see if you have any orphan (isolated) pages, specifically any new blog entries and deep technical documentation, to make sure that you are not creating any orphaned pages.
An orphaned page does not have any internal links leading to it so search engines assume that it holds no value. Be sure to connect your orphaned pages back into your main information architecture naturally.
Creating growth for your SaaS technical SEO
Evidence-based priority setting
With so many technical SEO issues to address, don’t rely on guesswork. Instead, obtain clear and concise evidence of which technical SEO issues need to be fixed first to have the greatest impact on your business.
There are many software tools that can identify thousands of missing tags, but few software solutions provide insight into which specific tags are responsible for delivering the most business value.
In order to utilize your engineering time most effectively, you should concentrate on the pages that generate the most revenue or enroll the highest number of customers in your products.
The basis of any technical decisions you make should rely on the following four strong data sources:
Crawl data from diagnostic tools - These are tools that crawl through all of your web pages and report on any hidden link errors.
Server logs - These allow you to check the actual behavior of the search bots and how often they crawl your site.
Real user performance data - This is the data that validates how fast a webpage loads when accessed from a mobile device.
Business analytics - This is used to connect organic traffic to active trial subscriptions.
The use of strategic structured data
Structured data provides a clear way to let search engines know what your webpages are about within saas technical seo. Rather than trying to guess whether a particular webpage is a blog post, a software application, or an ecommerce site, you are giving them the proper coded definition of the content in question by using structured data markup.
Common forms of structured data include the following: software applications, organizations, and basic article markups.
Note, however, that you should not use structured data to conceal poor site structure, loading speeds, or poor writing. Structured data is not a replacement for these core requirements.
You must ensure that you write quality code that exactly matches the site's text as it is read by humans. If you are designating a section of your site as a frequently asked questions section, the actual questions and answers must be visible to the human reader.
30-day implementation plan
To begin implementing the above plan, start with an immediate inventory of the types of landing pages on your website. The first three days of this 30-day plan should be spent mapping the various URL types of the professional network.
You will also be checking all the standard index rules of your marketing website and application. Organize your landing pages into categories based on business purposes/benefits and their current organic performance levels.
The remainder of the first week is dedicated to resolving issues that can be fixed today. You will remove "dead" hyperlinks (links that were not followed), correct canonical issues (links that point to two different places), and set up authentication walls to restrict visitors from accessing staging sites.
The last two weeks of a month have specific, concrete goals for all websites (and company sites in general) that can help the company to be better at increasing its search visibility.
Week 2 should validate that the rendering of the website works properly (i.e., does the initial HTML response correctly show the message of the feature pages and the complex integration list(s), or does it render appropriately for search engines?).
Week 3 should work on improving indexing bloat on the websites. This means fixing infinite loop problems, fixing isolated documentation pages, and creating internal connections between guides/website pages and commercial pages.
Week 4 should continue improving the performance metrics of the websites with structured data where needed, compressing large files (i.e., images) and establishing automated checks so that future deployments do not break the hard work done for web traffic and organic search.
The final view of growing search organically
To ultimately be successful in the internet search space over time, you need to view organic search visibility as a hard engineering standard for how your website works.
The leading software companies do not rely on periodic audits to determine how well a website is functioning or to identify problems; rather, they incorporate search practices and saas technical seo into their daily deployment workflow and systems.
If you control exactly what search engines see, request and process on your website, your website will grow and develop alongside your company as it continues to innovate and grow.
Avoiding major errors requires maintaining clear boundaries between publicly visible marketing material, and privately held application data, error reports to search engines and providing specific responsibility by team in the implementation of each incremental URL within the implementation of the SEO.
The only way to truly experience scale is when the system recognizes when it is producing your best features; eliminating the "noise" produced by flawed implementation or downtime due to areas of improvement; and properly framing the "awareness" of those features.
Questions about search engineering and deployment
How do preview deployments have an impact on organic visibility?
When testing is performed, staging sites often become publicly available through search engines. Search engines view these "testing" sites as duplicate content and penalize the main site by "wasting valuable crawl time".
Anything that is referred to and is available in a staging area should have strict logins required for any access to that site. Text blocks alone are not sufficient to prevent search engines from indexing this area.
Strict authentication requirements should be enforced for all non-production environments. This ensures search robots do not waste time trying to crawl an un-indexed page or leave before they have completed the indexing process.
All forms of content should require a login (authentication) before search robots can access them. Any content that is staged or in the test environment will not appear in a public index unless it is forced to be remembered by being entered into an indexed storage by a search robot.
Why does the application shell outrank the actual text description?
An additional reason our application's "shell" may receive a higher ranking than the actual text description of our application's features is that the initial response to a request for that feature does not contain the full text description of the features.
Many times, all that is returned in the response is a very basic frame containing the bare layout of the application. All of the application features and descriptions may be provided to search engines through the use of a client-side script.
Usually, search engines will index the empty frame before the text appears on the screen. You can remedy this situation by rendering all text descriptions on the server to allow them to be included in the responses before they are sent back to search engines.
If your initial code does not contain the same words as what you are trying to rank for in search engines, it will not rank high in the index. Therefore all text descriptions should be included in your initial code in order to appear in the index.
Can robots.txt files control endless loops of duplicate content?
No, you cannot use your robots.txt file to control endless loops due to duplicate content. The robots.txt file can stop the crawl of a given page; however, if that page is linked to by other pages, the robots will still index the link, and the search engine will eventually lose the information regarding that specific page if it was indexed and later deleted.
Therefore, the correct way to handle duplicate content is to create correct canonical tags or remove the page completely.
How should discontinued feature pages be handled?
When dealing with discontinued feature pages, it is important to never leave a discontinued feature page active. If a feature has been discontinued and has no direct replacement, you should return a permanent removal status code so that search engines can quickly delete the page from their servers.
If the feature has been renamed/merged into a new tool, you should use a permanent redirect to redirect the user to that new tool.
