How to: Troubleshoot Common Errors in Deployment Monitoring

If you're seeing emails for Deployment Monitoring flagging URLs with 'Markup from this source is missing', follow these steps to troubleshoot possible common causes.

TABLE OF CONTENTS

• Step 1: Review Status Codes
  • 200 Status Code with "Markup from Source is Missing"
  • 300 series Status Codes indicate URLs are redirecting & URL patterns need to be reviewed.
  • 400 Series Status Codes codes indicate the URL is not accessible or does not exist
  • 500 Series Status Codes indicate server errors
• Step 2: Investigate "Markup from Source is Missing" Errors 
  • Step 2.1: Confirm URL is meant to receive markup
  • Step 2.2 Confirm markup appears on page in your browser and in the RRT.
  • Step 2.3 Confirm this is a persistent problem

Step 1: Review Status Codes

Status codes are the "easiest" errors to resolve, in that the status code provides immediate insight into what the issue may be. For a complete list of Status Codes review our Status Codes and Mitigations list for descriptions of specific errors & how to address them.

Note: These recommendations describe a generalized approach for broad error code categories. Specific error codes may require more specific troubleshooting actions. When in doubt, consult our Status Codes and Mitigations List.

200 Status Code with "Markup from Source is Missing"

Action: Visit URL & confirm markup is present

Resolutions

• If markup is present: consider this a "False Negative". Document this false negative in a GitHub (either net new, or adding to an existing ticket)
• If markup is not present: proceed to Step 2: Investigate "Markup from Source is Missing" Errors

300 series Status Codes indicate URLs are redirecting & URL patterns need to be reviewed.

Action: Visit the URL & confirm it is redirecting

Resolutions

• For Editor markup: Update the data item URI
• For Highlighter markup: Review the deployment pattern(s)

400 Series Status Codes codes indicate the URL is not accessible or does not exist

Action: Visit the URL and to assess whether it is accessible to your standard browser user agent

Resolutions

•  If it is inaccessible within the browser contact the client to confirm the intended status of the page. 
• If it is accessible proceed to the next Action.

Action: Visit the URL and confirm it is inaccessible to our SchemaBot user agent.

Resolutions

• If you recive an "Access Denied" status code: the page is likely blocked by the client's configuration. You will need to follow up with whitelisting instructions: Whitelist Schema App IP Address & Endpoints for Full Functionality

500 Series Status Codes indicate server errors

Action: Visit the URL and confirm it is inaccessible to your standard browser user agent

Resolution

• If it is inaccessible within the browser contact the client to confirm the intended status of the page.  If it is not inaccessible, proceed to the next Action. 

Action: Visit the URL and confirm it is inaccessible to our SchemaBot user agent.

Resolution

• If you recive an "Access Denied" status code, the page is likely blocked by the client's configuration. You will need to follow up with whitelisting instructions: Whitelist Schema App IP Address & Endpoints for Full Functionality

Step 2: Investigate "Markup from Source is Missing" Errors 

Select 1-3 URLs to review and follow this process for each URL.

Step 2.1: Confirm URL is meant to receive markup

Action: Is this a URL from Step 3 that no longer exists or was used as an exclusion check?

Resolutions

• Remove the URL and/or exclude it from deployment monitoring 

Step 2.2 Confirm markup appears on page in your browser and in the RRT.

Action: Confirm markup is accessible to necessary bots

Resolutions 

•  If it is not showing up in GSC assess whether our is bot blocked. Use Dev Tools, and set the user agent under Network Conditions as SchemaBot. 
  • If you see Access Denied instead of the normal HTML content, the page may be blocked by a client configuration; you can find our SchemaBot user agent here to test with.
    Follow-up action: Review Robots.txt and Robots Only project settings with client to ensure all important bots have access to our markup.

Step 2.3 Confirm this is a persistent problem

Action: Use the single URL check report and set the date range back a few weeks

Resolutions

• If deployment is mostly successful over the last few weeks, then this is likely an intermittent false result.
• If you see that deployment is frequently failing when testing over the span of a few weeks, the client potentially has a deployment issue to investigate further.

If anything seems very unusual for a given client, please contact the engineering team to investigate further.