Social Media Tags Guide Part 4 – Debugging pages (Verifying problems with social media cards)

When creating OG tags, we may encounter problems displaying them. Fortunately, social media sites have so-called "debugging pages" dedicated to verifying and fixing issues with them. But how to use them?

Larger social media portals have prepared “debugging” pages, that allow free verification of the way in which a social media business card was created and why certain data may or may not be visible.

Debugging pages should be used when:

  • We want to verify the correctness of the card’s appearance, and we don’t want to publish it anywhere
  • There have been changes to the OG tags on our site and we want to update the card’s appearance with new information
  • After sharing the card on social media, it displays inappropriate information

Below we present pages that can be used to solve any problems with cards.

List of debugging pages

Facebook

Facebook sharing debugger
A site dedicated to verifying links shared on FB. It contains general information about the business card and links to pages that will help you understand how the business card was created.

Facebook debugger site preview
Facebook Object Debugger
One of the subpages of the Sharing Debugger, which is mainly focused on verifying OG objects.

Facebook og debugger site preview

Warning! Currently (December 2019) there is a bug on the FB Object Debugger which provides a notification that all the OG tags used are Extraneous Property. It’s an error on the FB side, not ours – so we can ignore it.

Twitter

Card Validator

A site dedicated to verifying links shared on Twitter contains general information about the business card.

Twitter debugger site preview

LinkedIn

Post Inspector
A website dedicated to verifying links shared on LinkedIn. It contains general information about the business card and information on how specific data was generated on it.

Twitter debugger site preview

Using debugging pages

Due to the fact that the Twitter debugger only tells us that something is not working, and the LinkedIn debugger gives only information why the certain data is used and not a different data, initial verifications should always be carried out on the Facebook debugger.

The Facebook debugger, unlike the rest of the debugging sites, has many advanced sections devoted to the real verification of why something did not work and where a possible problem may lie. Hence, any verification of cards should always start with Facebook Sharing Debugger and if everything is OK in it, then go forward to check site’s card looks on other social media

Let’s go through the process of verifying a single page step by step.

1. We enter the Facebook Sharing Debugger page

https://developers.facebook.com/tools/debug/sharing/

Facebook debugger link

2. We provide the address of the page that we want to verify (remember that each separate address and the separate addresses of subpages should be verified separately) and click the ‘debug’ button.

Facebook link search

3. At this point we will see the following sections in order:

a. The section of the errors found related to the card

Facebook debugger warnings section

b. General information section

Facebook debugger info section

c. All detected tags section

Facebook debugger raw tags section

d. A section of links to other tools

Facebook debugger links section

From this moment we can start the verification. Assuming that we want to proceed to the verification of possible problems, we start it from step 0.

Verification step 0 – extracting new information

We should always refresh the page details before any verification. We use the ‘Scrape Again’ button on the Facebook Sharing Debugger page.

Getting new data in FB Debugger

Thanks to this, we can be sure that we are not looking for an error that has already been accidentally resolved by a recent change of the page configuration or changes in OG tags and we will not waste time looking for a solution to an error that does not exist.

We can move on to real verification

Verification step 1 – checking GENERAL INFORMATION (section B)

Assuming that a problem has occurred and no OG tags have been downloaded at all, our card will be heuristically generated anyway.

We must be certain that the information on our business card is relevant and does not threaten the public image of our site/ company or ourselves.

Now we move on to the ‘Link preview’ section, where you can see a preview of the card generated for us.

FB Debugger base info check

We verify:

  • Is the image shown in the business card (if any) appropriate?
    • Does the image refer to the content of the page or to its general content?
    • Does the image contain any third-party content?
    • Is the image appropriate for users?
  • Is the visible page title appropriate?
    • Does the title refer to the content of the page?
    • Does the title contain any inappropriate words or characters?
    • Is the title incorrectly trimmed?
  • Is the content of the card description correct?
    • Does the description refer to the content of the page?
    • Does the description contain any inappropriate words or characters?
    • Is the description incorrectly trimmed?

If we do not see a problem with the appearance of our business card, we can go to the next sections and verify that the data is extracted in the right way (despite the seemingly correct presentation, there may still be problems with extracting the correct data).

If we see problems with our business card, it’s time for a mini-panic 😱 and quick editing with the help of debugging tools – let’s move straight to the next section, which should help you quickly find problems.

Read also: Design combined with technology: what are the latest trends?

Verification step 2 – checking the error section

FB Debugger base info check

In the example of the Efigence page, there is one error related to a missing fb:app_id tag.

In this case, there’s no need to worry – the fb:app_id tag is a dedicated tag for connecting the page with Facebook tools such as Facebook Insights (a site that allows you to track traffic from FB).

If there is an fb: app_id error on your page, you can ignore it.

However, any other errors, especially those directly related to OG tags, should be repaired.

Suppose the errors we see are:

Facebook debugger errors
  • The first error suggests that the og: image value is not given correctlyInferred Property – The ‘og:image’ property should be explicitly provided, even if a value can be inferred from other tags.

     

  • The second error suggests that some necessary tags are missing from the pageMissing Properties – The following required properties are missing: og:url, og:type, og:image, fb:app_id

Error number 1 results from error number 2 – if the og:image tag is not given, then its value is definitely not given in the right way.

So we have to correct error number 2 – there are no tags, we should add them to the page.

Most of the errors that the error section will point out are easy to understand – usually, a tag value is incorrect or simply missing.

What if the tags we have in our page source are correct but are still not visible on the page?

Verification step 3 – verification of generated tags

Facebook debugger raw tags check

Regardless of whether we found any errors in step 2, before proceeding to further verify the causes of problems, it is worth checking the generated tags sections and making sure that all the values match our expectations.

Usually, tags that have been generated incorrectly are easy to verify and correct. Most often these are incorrectly constructed HTML tags, incorrectly used characters, no tag closing, typos etc.

However, if everything indicates that the tags on our site are constructed correctly, and there is still a problem with their download or display on debugging pages, we should use the next section for further verification.

Verification step 4 – using the scraper’s website to ascertain what the robot is seeing

When the tags on the page are created in the right way, and a problem with displaying them still occurs, we should verify what the scraper sees.

Facebook debugger see scraper data link

This page shows us what information Facebook crawler sees after trying to connect.

After opening, it is worth looking for OG tags – if they are visible, they should also be included in our business card.

Facebook debugger scraper data
  • If information about the page appears on the scraper’s page, but the OG tags are not visible, we should verify that they are not generated incorrectly, e.g. after user action or after loading scripts.
  • If no data is visible on the scraper’s website, we should verify whether access to the site is possible for external users and whether the site is not password-protected.
  • If the visible data on the scraper’s page is for the wrong page, we should verify that there are no invalid redirects for the address provided.

If the problems are directly related to finding the right OG tags, then the scraper’s website should lead us to what went wrong.

If everything looks correct on the scraper’s page, then it can be assumed that the problem lies directly in the way tags are implemented, leading us to the next verification step …

Verification step 5 –using the Object Debugger page to verify the validity of implemented tags

The Object Debugger page is targeted to directly verifying problems with OG tags.

Unlike the Sharing Debugger page, which provides general information about where the problem arose, the Object Debugger page contains information about exact tags that cause problems along with why these problems are happening.

Facebook debugger full og site

Warning! Currently (December 2019), the Object Debugger page returns an excessive usage error for OG tags.
Extraneous Property | Objects of this type do not allow properties named ‘og:image:height’.
This is an FB verification page error – it should be ignored.

In the event of a real error, it is on the debugger page that we can expect more specific information about why something went wrong.

Facebook OG debugger info Facebook OG debugger info

There may be a lot of errors. In the following section, we will indicate some of the most common, but due to the specificity and number of errors that can occur for your site, we are not able to indicate what to do next.

From this moment further verification and corrections remain in your hands.

Verification step 6 –verification of the card’s appearance on Twitter and LinkedIn

When we are sure that the extensive Facebook debugger does not see any problems, we should proceed to verify the page on Twitter and Linkedin.

There may be errors that were not apparent to us on the Facebook debugger. This can be especially true on Twitter, which uses separate tags.

The process looks similar, with the difference that the Twitter card validator page does not have too many tools for real verification of problems – it just gives us information about the problem in the ‘log’ field.

Twitter card verification

In this situation, the verification of where the problem comes from remains in our hands – the main thing is to ensure (referring to step 1) that the card’s appearance is not off-putting on Twitter.

If not, we can ignore the problems occurring in the Twitter Log or take care of them in due course.

If it is so, it’s time to quickly move on to verify what went wrong. Our article on Twitter cards can be helpful in this case.

Common problems with OG tags

An image that doesn’t load

We should verify:

  • If the correct path is being used, the so-called ABSOLUTE (beginning with https:// or http://)
  • If we can access the image by copying the path from the page source and entering it in the browser
  • Whether the photo is the right size (not too small or too large)
  • If the data on the page has been refreshed since the last change
  • Whether the image has been renamed, if the image has recently been changed

Go to this page for more information about images:

Creating the perfect image for social media

No OG tags at all

We should verify:

    • If the site can be accessed from a different/ external network
    • If the site is protected by passwords or other information that could be stored on our computer
    • Whether the tags are visible on the scraper’s website or are not dynamically generated after downloading the scripts
    • Whether there are incorrect redirects on the page (e.g. a canonical address leading to a page with an html ending, or an .html redirecting 301 to a page without an .html, which would cause an infinite loop of redirects)

Some OG tags do not match those on the page

We should verify:

    • Whether, after entering the debugger site, the scraper sees new tags
    • If the page has been refreshed with the ‘Scrape again’ button since the last change

Summary

If you’re familiar with debugging pages then troubleshooting card issues shouldn’t be a problem. Unfortunately, as it so often is with problems, some can be very complicated and go beyond our competence. So do not be afraid to ask experts on forums, or to write to Facebook or Twitter for help.

Good luck!


Read also: The Future Of Frontend Frameworks

Let's make a great project together

Estimate project
Our website uses cookies. You can change the rules for their use or block cookies in the settings of your browser. More information can be found in the Privacy Policy. By continuing to use the website, you agree to the use of cookies.