When monitoring a website, Conductor Website Monitoring also audits all pages on the website for SEO issues and reports them to you. Thanks to our 24/7 monitoring you always have real-time data about all issues of your website at your disposal.
How Conductor Website Monitoring reports issues
The issues in Conductor Website Monitoring can be viewed on multiple levels:
- Issues detected on specific pages
- Issues detected on the platform level (domain, XML sitemap, and robots.txt)
- Issues detected across the entire website
Issues on the page level
If you are interested in issues that Conductor Website Monitoring detects on a specific page, go to the page detail screen.
On the right side of the screen, you will see all open issues on the page together with their impact on the page’s Health score:
Issues on the platform level
The Platform section in Conductor Website Monitoring contains data about the technical platform of your website, which consists of three parts:
- Domain
- XML sitemaps
- Robots.txt
On the right side of the screen, you can see the issues that Conductor Website Monitoring is detecting in relation with the technical platform.
Issues on the website level
You can always find a real-time overview of all issues that Conductor Website Monitoring is detecting on your website in the Issues section.
By default, you will see all issues reported for the whole website, but you can also filter the issues by status or by segment.
On the left side of the screen are the issue categories. When you click on one of the issue categories, you will see a breakdown of the individual issues within the category together with more details about each issue such as how many pages are affected.
If you want to know exactly which pages are affected by a certain issue, click the See affected pages button and you will get to a screen with all the affected pages, where you can use filters to zoom in further.
Apart from the issue categories, the Issues screen also contains two charts: Health per segment and Affected pages per category.
Health per segment
The Health per segment chart shows the Health score of each segment of your website. This can help you quickly determine which parts of the website are in the worst condition and should be prioritized for optimization.
For example, if you have a segment for the most important pages on the website, you can easily check how the segment is doing in terms of the Health score and take action if necessary.
Affected pages per category
The Affected pages per category chart shows how many percent of your website’s pages are affected by the different issue categories, so you can easily spot the widest-spread issues of the website.
You can also use the Segments filter to view the chart for a specific segment.
Issue states
An issue in Conductor Website Monitoring can be:
- Open
- Closed
- Ignored
- Still unknown
- Not required
- Not applicable
Open
- If an issue is open on the page level, it means that the page is affected by the issue.
- If an issue is open on the website level, it means that at least one page is affected by the issue.
The open issues are marked by a red exclamation mark icon.
Closed
- If an issue is closed on the page level, it means that the page is not affected by the issue and no action is needed.
- If an issue is closed on the website level, it means that no pages on the website are affected by the issue.
The closed issues are marked by a green checkmark icon.
Ignored
If an issue is ignored, it means that Conductor Website Monitoring is not evaluating the issue and you are awarded the Health score points as if the issue was closed.
Ignored issues are marked by a grey ban icon.
Still unknown
If an issue is still unknown, it means that Conductor Website Monitoring hasn’t yet finished the initial evaluation of the issue.
Still unknown issues are marked by a grey hourglass icon:
Not required
When an issue is not required, it means that Conductor Website Monitoring is only evaluating the issue on a specific part of a website (e.g. indexable pages). You can control this using Issue configuration.
Not applicable
When an issue is not applicable, it means that it’s not possible to evaluate it on a certain URL due to its nature. For example, page title length cannot be evaluated on pages where the page title is missing completely, or on redirected URLs which don’t have a page title by nature.
Built-in reference material
Whenever you’re not sure why Conductor Website Monitoring reports a certain issue, just look under the issue where you will find an explanation of why the issue is being reported.
If you want to know more, you can click the Learn why button which will provide you with additional information about the issue as well as with a link to an in-depth article on that topic in our Academy.
Issues and the Health score
The Health score in Conductor Website Monitoring is a metric to determine the degree to which a page, or a website overall, is optimized for SEO.
Same as with the issues, there are also three levels of the Health score that you can view:
- Page Health which can be viewed for each page on the page detail screen
- Platform Health which can be viewed in the Platform section
- Website Health which can be viewed in the Issues section
The maximum possible value of the Health score is 1,000 points and it is influenced by the Issues. Each issue is valued with a certain number of Health score points based on the impact it has on the SEO performance.
The Issues are always ordered by their impact on the Health score, which is represented by the number of Health score points on the right side of the issue category tab.
The impact of an issue on the Website Health is based on the number of affected pages as well as on the Importance of the pages. This means that issues on important pages have a bigger impact on the Health score than issues on less important pages.
This helps you quickly discover the most pressing SEO issues of your website and prioritize your efforts in resolving them.
When hovering over or clicking on an issue category tab, the potential improvement of the Health score in case of resolving all issues in the category is marked with blue color on the Health score bar:
Which issues does Conductor Website Monitoring check?
The individual issues that are part of Conductor Website Monitoring’s auditing suite are grouped into issue categories. Conductor Website Monitoring audits websites for the issues below.
Note that minimum and maximum lengths for issues below are the default values. You can also configure some of these values to reflect what you would like Conductor Website Monitoring an issue.
Domain
| Title | Instruction | Explanation |
| non_www variant is not redirected | Pages on the non-canonical domain variant should redirect to the canonical domain. | To consolidate links and traffic, it's important to redirect the non-canonical variant to the canonical hostname of your website. This means deciding which version is preferred (WWW or non-WWW) and redirecting the one. |
| Website not available via HTTPS | Websites should be accessible via HTTPS to secure their communication with visitors and potentially improve rankings. | Using HTTPS protects the communication between your website and visitors and is also a minor ranking factor for search engines. |
| HTTPS certificate is not valid | HTTPS certificates should be valid, cover the website's hostname and have a future expiry date. | Having an invalid HTTPS certificate causes the website to be inaccessible for visitors and search engines. Valid certificates cover the correct hostname (e.g. invalid URL removed), have a future expiry date and are correctly configured. |
| https variant is not redirected | Pages with a non-canonical protocol should redirect to the canonical variant. | To consolidate links and traffic, it's important to redirect the non-canonical variant to the canonical domain when your website is available on multiple protocols (HTTP and HTTPS). This is particular important when the HTTPS protocol is canonical, as it enforces the use of HTTPS for all communication. |
| Soft-404s present | Non-existing pages should return a 4xx status code. | Pages that don't exist should communicate that to search engines and browsers by using a 4xx status code (usually 404). If this is not the case, search engines may think there are far more pages on the website, which can cause duplicate content and crawl budget issues. Conductor Website Monitoring checks this by randomly requesting non-existing URLs. |
Robots.txt
| Issue | Instruction | Explanation |
| Some assets blocked from search engines | The robots.txt file should not block access to assets. | Assets are JavaScript and CSS files referenced in the HTML source which browsers use to display the page. Search engines may also rely on these files to render the page, so blocking access to these assets makes it hard for search engines to get the full picture of your website. |
| Crawl-delay directive present | The robots.txt file should not contain any crawl-delay directives. | The crawl-delay directive instructs some search engines to slow down their crawling, which causes new content and content updates to be picked up later. This is undesired, as you want search engines to pick up on changes to your website as quickly as possible. |
| Robots.txt is not accessible | Websites should have an accessible robots.txt file. | The robots.txt file tells search engines how to best crawl your website. This can be used for various things, such as keeping search engines out of unwanted parts of the website to avoid wasting crawl budget. |
| Invalid directives present | The robots.txt file should not contain invalid directives. | Directives are invalid when they have no impact on search engine behavior. A common example of this are directives that don't start with a forward slash or asterisk, as those directives can't match any URL. |
| Invalid syntax present | The robots.txt file should not contain invalid syntax. | Invalid syntax refers to lines that contain syntax not supported by the robots.txt protocol. A common example of this are lines not containing a colon. |
| Present on non-canonical variants | Only the canonical domain should have a robots.txt file. | Having robots.txt files also available on non-canonical domain variants causes problems when directives start to conflict. Unless you know what you're doing, it's best to only keep the robots.txt file on the canonical domain. |
| Referenced XML sitemap is not accessible | The robots.txt file should reference an accessible XML sitemap. | An accessible robots.txt file tells search engines how to best crawl your website. This can be used for various things, such as keeping search engines out of unwanted parts of the website to avoid wasting crawl budget. |
| XML sitemap reference is missing | The robots.txt file should reference an XML sitemap. | Referencing the XML sitemap in the robots.txt file makes it easier for search engines to find your XML sitemap. This is especially important if your XML sitemap is not in a default location. |
| XML sitemap referenced with relative URL | The robots.txt file should reference an XML sitemap using an absolute URL. | The XML sitemap reference in the robots.txt file should be done using an absolute URL, so make sure to include the domain name and protocol (HTTP or HTTPS). This avoids ambiguity over the exact location of the XML sitemap. |
Robot directives
| Issue | Instruction | Explanation |
| Robot directives give conflicting directives to search engines | Robot directives should provide clear, non-conflicting instructions to search engines. | When conflicting robot directives are present, search engines usually respect the more restrictive directive. Implementation of conflicting robot directives indicates that a specific directives were intended, but some of them are now being ignored by search engines due to the conflict. |
| Invalid robot directives present | All robot directives should be valid. | Invalid robot directives are most likely ignored by search engines. Implementation of invalid directives indicates that a specific directive was intended, but is now being ignored by search engines. |
| Valid but unsupported robot directives to a search engine present | All robot directives should be supported by the search engine they give instructions to. | If a search engine doesn't support an implemented robot directive, it will most likely ignore it. Implementation of such directives indicates that a specific directive was intended, but is now being ignored by the search engine.Make sure to use only directives supported by the search engine you're giving instructions to. |
XML sitemap
| Issue | Instruction | Explanation |
| XML sitemap is not accessible | The XML sitemap should be accessible. | An inaccessible XML sitemap can prevent search engines from discovering and indexing your website's content effectively. |
| XML sitemap is missing | Every website should have an XML sitemap. | An XML sitemap helps search engines understand the structure of your website and discover all your important pages. |
| XML sitemap contains broken URLs | The XML sitemap should not contain broken URLs. | Broken URLs in the XML sitemap can lead search engines to crawl non-existent pages, wasting crawl budget and potentially affecting indexing. |
| XML sitemap contains non-canonical URLs | The XML sitemap should only contain canonical URLs. | Including non-canonical URLs in the XML sitemap can confuse search engines about which version of a page is preferred. |
| XML sitemap is too large | The XML sitemap should be within size limits. | Large XML sitemaps may exceed file size limits or contain too many URLs, preventing search engines from processing them fully. |
| XML sitemap is not referenced in robots.txt | The XML sitemap should be referenced in the robots.txt file. | Referencing the XML sitemap in robots.txt helps search engines discover it easily, especially if it's not in a standard location. |
| XML sitemap is referenced with a relative URL in robots.txt | The XML sitemap should be referenced with an absolute URL in robots.txt. | Using an absolute URL ensures that search engines can locate the XML sitemap correctly, regardless of the referring page. |
Analytics
| Issue | Instruction | Explanation |
| Analytics are missing | Every page should contain analytics tracking (like Google Analytics or Adobe Analytics). | You can't improve what you don't measure. Analytics software helps you track the behaviour and goal conversions of your visitors to optimize for usability and conversions. |
| Visual analytics is missing | Every page should contain visual analytics tracking (like HotJar or Mouseflow). | You can't improve what you don't measure. Visual analytics software helps you track the interaction your visitors are having with your website to optimize for usability and conversions. |
Links
| Issue | Instruction | Explanation |
| Broken links present | Links should point to existing pages. | A broken link is a dead end for search engines and visitors which causes link authority flowing to these dead end pages to be lost, wastes crawl budget and negatively impacts user experience. |
| Links to redirects present | Links should point to the final targets, not to redirects. | Links to redirects slow down search engines and visitors, as their requests need to go through an additional location before the content is displayed. This extra hop also reduces the amount of link authority being passed on and wastes crawl budget. |
| Links to canonicalized pages present | Links on should point to pages with a self-referencing canonical. | Links to pages that in turn have a canonical link to a third page give mixed signals to search engines. To optimize your internal link flow, unifying your linking to pages with a self-referencing canonical is crucial. |
Canonical link
| Issue | Instruction | Explanation |
| Off-page canonical link on non-indexable page | Pages with robots directives preventing indexing should not contain a canonical link pointing to another page. | If the page prevents indexing via meta robots or X-Robots-Tag directives, it should not contain a canonical link pointing to another page, as this may pass the noindex directive on to the target of the canonical link. |
| Canonical link is missing | Every page should have a canonical link. | A canonical link prevents duplicate content issues by informing search engines to prefer one document over identical or similar documents. Every page should have a canonical link, either self-referencing or pointing to another indexable page, to tell search engines which page is the original. |
| Canonical link target is not indexable | Canonical link should be self-referencing or point to an indexable target. | A canonical link should either point to the same page (self-referencing) or to a third page, as long as that page is indexable. Pointing to a non-indexable page confuses search engines. |
| Multiple canonical links are present | Pages should have only one canonical link. | Having multiple canonical links on a page confuses search engines, as they don't know which canonical link to pick. To avoid this, make sure every page has exactly one canonical link. |
Images
| Issue | Instruction | Explanation |
| Images present without alt attribute | Images should have an alt attribute. | The alt attribute describes the contents of your images to search engines and screen readers used by visually impaired people. This improves the findability of your images and also helps people with vision problems understand what the image is about. |
| Images served over incorrect transport | Images on an HTTPS page should be served over HTTPS. | Pages served over HTTPS should have all assets served over HTTPS to prevent the unencrypted content from being accessed by man-in-the-middle attackers. |
Page title
| Issue | Instruction | Explanation |
| Title tag is missing | Every page should have a title tag. | Title tags are a crucial ranking factor for search engines and are also displayed in search engine result pages, browser tabs and when content is shared on social media. |
| Title tag is not unique | Title tags of pages that can cause duplicate content issues should be unique. | Indexable pages that are not part of a pagination sequence or hreflang group should have a unique title tag. Having unique title tags helps search engines distinguish pages, and increases your chances of search engines using the title tag. |
| Title tag length is incorrect | Title tags should be between 285 and 575 pixels (approx. 29 and 61 characters). | If a title tag is too short or too long, search engines may decide not to use it and generate their own title tag based on the page's contents. The result of their guesswork is generally quite poor, causing your page's listing in the result pages to be sub-optimal. |
Meta description
| Issue | Instruction | Explanation |
| Meta description is not unique | Meta descriptions of pages that can cause duplicate content issues should be unique. | Indexable pages that are not part of a pagination sequence or hreflang group should have a unique meta description. Doing so helps search engines distinguish pages, and increases your chances of search engines using the meta description. |
| Meta description length is incorrect | Meta descriptions should be between 430 and 920 pixels (approx. 71 and 153 characters). | If a meta description is too short or too long, search engines may decide not to use it and generate their own description based on the page's contents. The result of their guesswork is generally quite poor, causing your page's listing in the result pages to be sub-optimal. |
| Meta description is missing | Every page should have a meta description. | Meta descriptions are prominently featured in search engine result pages and thus are like advertising copy for your pages. A good meta description will increase the click-through rate of your website's listed pages. |
| Multiple meta descriptions are present | Pages should have only one meta description. | Having multiple meta descriptions on a page sends mixed signals to search engines. They won't know which meta description to use, and may choose to ignore your meta descriptions altogether, causing your page's listing in the result pages to be sub-optimal. |
Content headings
| Issue | Instruction | Explanation |
| H1 heading is not unique | H1 headings of pages that can cause duplicate content issues should be unique. | Indexable pages that are not part of a pagination sequence or hreflang group should have a unique H1 heading. This is to avoid confusing search engines in deciding which page to display for the keywords you incorporate. |
| H1 heading length is incorrect | H1 headings should be between 4 and 60 characters. | Having an H1 heading that is too short or too long makes it difficult for your visitors to quickly grasp the topic of the page. Keeping the H1 heading at the right length ensures optimal readability. |
| Heading level is skipped | Heading levels on should follow an ordered sequence. | Heading levels that follow an ordered sequence improve the navigation experience on the page and help your visitors understand the page structure faster. |
| H1 heading is missing | Every page should have an H1 heading. | H1 headings are a ranking factor for search engines as they use the H1 heading to determine what the page is about. On top of that, H1 headings help your visitors to quickly understand the topic of the page. |
| Multiple H1 headings are present | Pages should have only one H1 heading. | Having multiple H1 headings on a page makes it harder for search engines and visitors to quickly grasp the topic of the page. Having exactly one H1 heading per page avoids confusion for both. |
This is a highlight box. The borders that appear in the editor and this explainer will not appear in the published article. Use the Title and Body below for examples, best practices, or other information you'd like to call out.
When auditing duplicate content issues, Conductor Website Monitoring automatically takes into account hreflang and pagination relations.
This means that pages that are part of a pagination sequence or hreflang group will not be reported as duplicates in case they have identical content.
End of Highlight box
Open Graph
| Issue | Instruction | Explanation |
| Open Graph description length is incorrect | Open Graph descriptions should be 65 characters or less. | If the Open Graph description is too long Facebook will cut your description short, meaning that your page's snippet will be sub-optimal when someone shares it online. |
| Open Graph description is missing | Pages should have an Open Graph description. | Open Graph markup allows you to gain control of the snippets that are shown when your pages are shared on Facebook, WhatsApp, Slack and social media platforms. Having a great Open Graph description increases the click-through rate when your content is shared online. |
| Open Graph image is missing | Pages should have an Open Graph image definition. | The Open Graph image property defines which image is displayed when your content is shared online. If you don't define it, social media platforms will try to pick an image from the page by themselves. The result of their guesswork is generally quite poor, causing your page's snippet to be sub-optimal. |
| Open Graph title length is incorrect | Open Graph titles should be 60 characters or less. | If the Open Graph title is too long Facebook will not display your Open Graph description or cut your title short. Either way, your page's snippet will be sub-optimal when someone shares it. |
| Open Graph title is missing | Pages should have an Open Graph title. | Open Graph markup allows you to gain control of the snippets that are shown when your pages are shared on Facebook, WhatsApp, Slack and social media platforms. Having a great Open Graph title increases the click-through rate when your content is shared online. |
| Open Graph URL is missing | Pages should have an Open Graph URL definition. | The Open Graph URL property is a required property in the Open Graph standard and used to attribute Likes and Shares to the correct (canonical) URL. |
Twitter Cards
| Issue | Instruction | Explanation |
| Twitter Card type is missing | Every page should have a Twitter Card type defined. | The Twitter Card type defines how your page's snippet is displayed when shared on Twitter. Not defining it will cause Twitter to guess, which often leads to a sub-optimal snippet. |
| Twitter Card description length is incorrect | Twitter Card descriptions should be 125 characters or less. | If the Twitter Card description is too long Twitter will cut your description short, meaning that your page's snippet will be sub-optimal when someone shares it online. |
| Twitter Card description is missing | Pages should have a Twitter Card description. | Twitter Card markup allows you to gain control of the snippets that are shown when your pages are shared on Twitter. Having a great Twitter Card description increases the click-through rate when your content is shared online. |
| Twitter Card image is missing | Pages should have a Twitter Card image definition. | The Twitter Card image property defines which image is displayed when your content is shared on Twitter. If you don't define it, Twitter will try to pick an image from the page by themselves. The result of their guesswork is generally quite poor, causing your page's snippet to be sub-optimal. |
| Twitter Card title length is incorrect | Twitter Card titles should be 55 characters or less. | If the Twitter Card title is too long Twitter will not display your Twitter Card description or cut your title short. Either way, your page's snippet will be sub-optimal when someone shares it. |
| Twitter Card title is missing | Pages should have a Twitter Card title. | Twitter Card markup allows you to gain control of the snippets that are shown when your pages are shared on Twitter. Having a great Twitter Card title increases the click-through rate when your content is shared online. |
Schema.org
| Issue | Instruction | Explanation |
| Schema.org type is missing | Every page should have a Schema.org type defined. | Schema.org markup helps search engines understand the content of your pages better, which can lead to enhanced listings in search results (rich snippets). Not defining a Schema.org type means search engines have less context about your page's content. |
| Schema.org property is missing | Schema.org implementations should contain all required properties. | Each Schema.org type has a set of required properties that must be included for the markup to be valid. Missing required properties can prevent search engines from correctly interpreting the Schema.org data. |
| Schema.org property value is invalid | Schema.org properties should have valid values. | Invalid property values can confuse search engines and prevent them from properly understanding the Schema.org markup. Ensure values match the expected format and data type for each property. |
Hreflang
| Issue | Instruction | Explanation |
| Hreflang attribute value is pointed to multiple targets | Each audience specified in the hreflang implementation should have a single target. | To make it clear to search engines which variant of the page should be shown to a specific audience, the hreflang attributes specifying the same audience should have the same target. |
| Invalid hreflang target present | The target of the hreflang attribute should be an absolute URL. | When the hreflang attribute has a missing target, search engines won't know which variant of the page should be served to that specific audience. On top of that, to make sure that search engines interpret the target of the hreflang attribute correctly, it should be defined as an absolute URL. |
| Invalid hreflang attribute value present | An hreflang attribute should contain only a valid language and/or region, or an x-default value. | The hreflang attribute describes which localized variant of the page should be served to the various audiences you're targeting. For that, only the valid language and/or region combinations, or the x-default value can be used. |
| Self-referencing hreflang not present | Every hreflang implementation should contain a self-referencing hreflang. | The hreflang attribute describes which localized variant of the page should be served to the various audiences you're targeting. For that, the hreflang implementation needs to specify both the preferred audience for the page itself, and its translated variants. |
| Hreflang implementation does not contain any hreflang attribute specifying a language and/or region | Every hreflang implementation should contain at least one hreflang attribute that specifies a language and/or region. | The hreflang attribute describes which localized variant of the page should be served to the various audiences you're targeting. Therefore, each hreflang implementation should have at least one hreflang attribute specifying a language and/or region. |
| Hreflang attribute with x-default value is missing | Hreflang implementation should have an x-default fallback value. | The hreflang attribute describes which localized variant of the page should be served to the various audiences you're targeting. To make sure the audiences for which there's no specified variant are also served with the right version of the page, define the fallback page variant using the x-default value. |
Conductor Website Monitoring Lighthouse Web Vitals
| Issue | Instruction | Explanation |
| Cumulative Layout Shift is too large | Cumulative Layout Shift should be or less. | Cumulative Layout Shift (CLS) measures the cumulative score of all unexpected layout shifts within the viewport that occur during a page's lifecycle. A CLS of 0.1 or less indicates the page is providing a good user experience, and is considered "good" in Lighthouse. |
| First Contentful Paint takes too long | First Contentful Paint should occur within seconds since the page starts loading. | First Contentful Paint (FCP) measures the time from when the page starts loading to when any part of that page's content is rendered on the screen. An FCP of 1 second or less indicates the page is providing a good user experience, and is considered "good" in Lighthouse. |
| Largest Contentful Paint takes too long | Largest Contentful Paint should occur within seconds since the page starts loading. | Largest Contentful Paint (LCP) measures the time from when the page starts loading to when the largest text block or image element is rendered on the screen. An LCP of 2.5 seconds or less indicates the page is providing a good user experience, and is considered "good" in Lighthouse. |
| Performance score is too low | Pages should have the Performance score above 90. | Performance score is a weighted average of six performance web vitals. A Performance score above 90 indicates the page is providing a good user experience, and is considered "good" in Lighthouse. |
| Speed Index is too high | Speed Index should be seconds or less. | Speed Index (SI) measures how quickly the contents of a page are visibly populated during page load. An SI of 4.3 seconds or less indicates the page is providing a good user experience, and is considered "good" in Lighthouse. |
| Total Blocking Time is too long | Total Blocking Time should be milliseconds or less. | Total Blocking Time (TBT) measures the total time in milliseconds between First Contentful Paint (FCP) and Time to Interactive (TTI) where the main thread is blocked long enough to make it unresponsive to user input. A TBT of 300 milliseconds or less indicates the page is providing a good user experience, and is considered "good" in Lighthouse. |
| Time To Interactive is too long | Time To Interactive should be seconds or less. | Time To Interactive (TTI) measures the time from when the page starts loading to when it's fully interactive. A TTI of 3.8 seconds or less indicates the page is providing a good user experience, and is considered "good" in Lighthouse. |
Web Vitals Origin Summary
| Issue | Instruction | Explanation |
| Website does not pass the Core Web Vitals assessment | Websites should pass the Core Web Vitals Assessment. | Passing the Core Web Vitals Assessment indicates the website is providing a good user experience. From May 2021, passing the Core Web Vitals Assessment is also a ranking factor for Google Search on mobile. Each Core Web Vital from the Chrome User Experience Report needs to provide a good user experience for the website to pass the Core Web Vitals Assessment. |
| Cumulative Layout Shift is too large | Cumulative Layout Shift should be 0.1 or less. | Cumulative Layout Shift (CLS) reflects visual stability. It measures the cumulative score of all unexpected layout shifts within the viewport that occur during a page's lifecycle. Since it is a Core Web Vital metric, it has an impact on the Core Web Vitals Assessment which is a ranking factor for Google Search on mobile from May 2021. |
| First Contentful Paint takes too long | First Contentful Paint should occur within 1.8 second since the page starts loading. | First Contentful Paint (FCP) reflects loading performance. It measures the time from when a page starts loading to when any part of that page's content is rendered on the screen. While LCP measures when the page's all main contents have finished loading, FCP measures the time until any content is loaded at all. FCP is not a Core Web Vital metric, but having a fast FCP is important, as it reassures users that something is happening. |
| Interaction to Next Paint is too long | Interaction to Next Paint should be shorter than 200 milliseconds. | Interaction to Next Paint (INP) reflects interactivity and responsiveness. It measures responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user's visit to a page. Since it is a Core Web Vital metric, it has an impact on the Core Web Vitals Assessment which is a ranking factor for Google Search on mobile from May 2021. |
| Largest Contentful Paint takes too long | Largest Contentful Paint should occur within 2.5 seconds since the page starts loading. | Largest Contentful Paint (LCP) reflects a perceived load speed. It measures the time from when the page starts loading to when the largest text block or image element is rendered on the screen. Since it is a Core Web Vital metric, it has an impact on the Core Web Vitals Assessment which is a ranking factor for Google Search on mobile from May 2021. |
Are you missing an issue here? We're always thrilled to hear about your use cases, so feel free to contact us and suggest what else you would like Conductor Website Monitoring to audit on your website.
Customization of the auditing suite
Conductor Website Monitoring allows you to tailor the auditing suite to your specific needs to make sure you have the right insights for your team or your clients.
Issue ignoring
The issues for which Conductor Website Monitoring is auditing your website are based on SEO best practices and are universally valid for any website and any market.
However, it can happen that some of the reported issues or issue categories are not important or relevant for you.
For example, if your audience is not using Twitter and you are not focusing on this social media channel, you might not want Conductor Website Monitoring to report the Twitter Cards issues for your website.
In such cases you have the option to ignore an issue or a whole issue category. By doing that, Conductor Website Monitoring will stop actively reporting the issue and you will be awarded the Health score points as if the issue was closed.
Issue Configuration
Conductor Website Monitoring’s auditing suite comes with default test parameters for each issue, which are based on industry surveys and best practices within SEO, and are therefore universally valid.
However, you can also adjust these test parameters to your specific needs.
For example, Google enforces different meta description lengths in different markets, so if your website focuses on a specific market, you can change the length parameters which Conductor Website Monitoring uses to assess the meta description length.
For more information the Issue Configuration feature refer to this support article.
Tracked Changes in Issues
On top of real-time SEO auditing, Conductor Website Monitoring also keeps track of how the issues on your website develop in time and provides you with the data about all the tracked changes in Issues.
For more information about this feature continue to this support article.
Issues and Alerts
The Issues section in Conductor Website Monitoring always provides you with real-time data about all issues that Conductor Website Monitoring is detecting across your website.
On top of that, for some of the issues you can also get alerts if the issue opens. You can read more about our alert types in this support article.