URL in question: https://www.halleonard.com/viewpressreleasedetail.action?releaseid=10261
When you view the source in a browser and in Developer Tools, you can see all of the meta tags for Open Graph and Twitter. I have checked the Facebook Debugger and, aside from a few canonical issues, I'm fairly happy with the results.
I also plugged the above URL into a third-party Open Graph Debugger:
http://debug.iframely.com/
and all of the tags for Open Graph, Twitter and even other all come back positive.
Why is is that Twitter's Card Validator is coming back with a
INFO: Page fetched successfully
INFO: 9 metatags were found
ERROR: No card found (Card error)
Any insight on how I get Twitter to display properly?
I think you may either be blocking or redirecting the Twitterbot agent.
I faked a Twitterbot agent with curl:
curl -A 'Twitterbot' https://www.halleonard.com/viewpressreleasedetail.action?releaseid=10261 -o ~/Desktop/what-twitterbot-sees.html
And this is what your server returns:
As you can see there are 10 meta tags (if you exclude the <meta charset> one) which is what the card validator indicates and there are no <meta name="twitter:*"> tags at all.
You can reproduce with your browser if you can set a custom user agent string. This is possible with Google Chrome:
I'm pretty sure there's some sort of redirection rule going on either at your web server level or in your application code.
According to developer.twitter.com, the user agent string I have used is correct:
Twitter uses the User-Agent of Twitterbot (with version, such as Twitterbot/1.0)
I checked your source code with w3c validator.
https://validator.w3.org/
it seems that google tag manager is not installed properly: you have to move the google tag manager (noscript) (line 10:13) on top of the body section and absolutely remove it from head section.
You can find here some information
https://support.google.com/tagmanager/answer/6103696?hl=en
and also (more specific) in your tag manager page (like this attached)
The error is coming because of the twitter:card type you have selected. You forgot to add the twitter:image content. These both should be added.
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:image" content="ADD IMAGE URL">
Reference Link
Related
I'm trying to set up Open Graph meta tags for a website. When I access the site normally using a browser and inspect the source, the tags are there. However, they don't show up when I use the OG debugger.
The site that I'm developing is here spurafrika-org.vercel.app (Next.js site). It's replacing the original site here: spurafrika.org (WordPress site).
When I use the See exactly what our scraper sees for your URL feature, I get this:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head>
<body><p>ÿþ</p></body>
</html>
See for yourself here. Vastly different from my actual source for my websites.
I originally thought it might have been a Vercel/Next.js issue, but when I discovered it also happening on the WordPress site, I was very confused: see this. I've checked other sites developed with Next.js and WordPress - the meta tags work fine on the debugger.
Another point of confusion is that the debugger tool seems to be able to pick up that on my Next.js site I've listed https://spurafrika.org as its canonical URL, which it can only tell through my og:url tag. Yet when I view what the debugger supposedly sees, it shows the above empty HTML snippet.
I thought perhaps it might have been an encoding or parsing issue, but I've validated my HTML source using several tools and there are no problems.
I'm stumped. Anyone know why this is happening?
I copied your code against a code sandbox - https://developers.facebook.com/tools/debug/?q=https%3A%2F%2Fkzi2c.csb.app%2F
Initially keeping the og:url as https://spurafrika.org/ caused warnings and og:description not getting picked up, once i pointed it to the actual url it all got fixed
Change the og:url to the right url may fix it, give it a shot and let us know.
Hopefully I can explain this correctly. I have recently been moved to a Windows 10 VM from Windows 7 and I'm trying to get a site for my team at work to display properly in Edge. I have a WebPart linking to CSS that is displaying everything as one large list instead of a table with dropdowns. When I open the HTML page on its own in Edge it displays fine, but with code in SharePoint it is not working correctly. Any ideas of why this could happen?
What should display
What is displaying in SharePoint
EDIT
After opening developer tools I find that I am receiving a SEC7111 error code on my CSS file that is being linked. Looking other places for solutions to this too, but any help is greatly appreciated!
FINAL EDIT
With the SEC7111 error I found out that the "file://" links I used for the CSS weren't going to work because they weren't considered "secure" (Although I got the same error in IE, but never had this display issue..?) So, I moved my linked CSS file to a secure folder in another SharePoint site I have, linked the CSS from there, and now it's working!
There are some ways that you can use to solve your problem (It's better to share your code within your question to get a better answer). So, I offer you below solutions:
Solution 1
Please don't use file:// for the published site in the webserver. HTML rendered on the client so you cannot access the local files. so you should not use the file://. you can read more about security concerns and more details on the file protocol here: (https://en.wikipedia.org/wiki/File_URI_scheme)
Instead of using local file protocol, you can use the Absolute/Relative path to your CSS on the HTTP/HTTPS protocols
Solution 2
Add X-UA-Compatible meta tag or HTTP response header to force IE to run with legacy document mode: 5, 7, 8.
X-UA-Compatible meta tag:
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=8" />
...
</head>
<body>
</body>
</html>
X-UA-Compatible HTTP response header:
I have a website that triggers a warning when clicked through a link shared on Facebook. The warning says:
Possible problem with this link
We have detected that this link: http://www.example.online/ may be malicious.
To keep your account and device secure, only follow links you trust."
I ran the Facebook debug tool and I get the following error message:
Inferred Property
The og:image property should be explicitly provided, even if a value can be inferred from other tags.
I Googled this issue and I understand it is caused by some lack of meta information in the site header, but my site's code has the following in the header:
<meta http-equiv="etag" content="2efdc27c8967f14e2c829e601f7a1228"/>
<meta property="og:title" content="South Jersey Aerial Photograpahy"/>
<meta property="og:type" content="website"/>
<meta property="og:url" content="http://www.example.online/"/>
<meta property="og:image" content="https://static.example.com/media/56a444_9273e80a60684dc8b38e56025059f356%7Emv2_d_3200_1800_s_2.png"/>
<meta property="og:site_name" content="South Jersey Aerial Photograpahy"/>
<meta property="og:description" content="South Jersey Aerial Photography is South Jersey's premier aerial photography and aerial videography company. Fully licensed and insured. Contact us today!"/>
<meta name="SKYPE_TOOLBAR" content="SKYPE_TOOLBAR_PARSER_COMPATIBLE"/>
I have no idea how to fix this error message. The property metatag is clearly there.
In short, you should re-fetch your website information using this tool:
https://developers.facebook.com/tools/debug/
Paste your URL and press Debug. Then either do Fetch, or press Scrape Again.
This will refresh Facebook cache, and your html-page will be reloaded.
Some additional info: https://stackoverflow.com/a/44453472/4899346
Following the already mentioned link to the Facebook object debugger, make sure that your og tags are written RIGHT AFTER the opening <head> tag.
Not sure why this happens but I used to run into the exact same issue until I moved them right after it and then clicked once again on "Fetch new scrape information".
Hope this helps!
Check for og:url tag and see whether the url is correct or not. In my case the url was not correct and so it was causing this type of error.
Ran into the same issue today. It would appear that it's a bug on Facebook's end.
Just by refreshing the Sharing Debugger will show me different error messages after each reload, including "Image Too Big", which clearly was not the case, and "Meta Tags In Body" which also was not correct.
As long as the correct image shows up in the Link Preview, I think you're good to go.
Had same issue today
'og:image' property should be explicitly provided, even if a value can
be inferred from other tags
somehow my linter replaced "(quotation mark) to ”(right double quotation mark), therefore https://developers.facebook.com/tools/debug/sharing/ was showing issue,
cause of that, these meta properties were not visible to fb-bot. After this correction it works fine
Even if you have a proper OG tag on a page, can Facebook still ignored og:image value.
On my Magento 2 website, I use Magento 2 Facebook Open Graph by Magefan and had this issue too even all OG tags look good :-(
After I contacted them (magefan), they fixed the issue and released the module update v2.0.12
It turned out that Facebook only looks for og:image in the first 50Kbs of the page source.
So if you are using inline CSS, or some JS in the the og:image will not be seen by Facebook. That was the reason in my case.
The solution is to put OG tags as high as possible in the node.
Added the
<meta property="og:image:secure_url" content="https://abc/image.jpg" />
in order for the facebook debug to actually show my issue that the image was not 200x200. Corrected that and had to completely refresh the debug to resolve.
OG tags should be property instead of name for those of you who copy/paste from other tags like twitter, who uses name.
Eg
<meta property="og:image" content="..." />
<meta name="twitter:image" content="..." />
If you're using a plugin like W3 Total Cache, Just purge your cache and go back to Facebook object debugger page mentioned by #Alex C and then click on Fetch new scrape information.
This solved the issue for me
`<meta property="og:image" content="https://static.wixstatic.com/media/56a444_9273e80a60684dc8b38e56025059f356%7Emv2_d_3200_1800_s_2.png"/>`
<meta property="og:image:width" content="2500"/>
<meta property="og:image:height" content="1330"/>
1200 pixels x 627 pixels
The most frequently recommended resolution for an OG image is 1200 pixels x 627 pixels (1.91/1 ratio). At this size, your thumbnail will be big and stand out from the crowd. Just don't exceed the 5MB size limit.
Double check your img file size.
Remember you need to add og:image:secure for "https"
2.og:image only works with "http".
Try
<meta property="og:image" content="http://example.com/image">
<meta property="og:image:secure" content="https://example.com/image">
I had og:url content as http://... when my site always redirected to https://.... Updating this fixed the issue for me.
I have had success by using https://developers.facebook.com/tools/debug/sharing/batch/ to invalidate the FB cache, then using https://developers.facebook.com/tools/debug/ to refresh it.
This seems to help if a page/post has been previously shared, say, and then an og image or other og element was added.
I am using OpenGraph tags so when I share my page on Facebook or Google+, those services will know what image should be displayed in the share dialog.
<meta property="og:title" content="Best Site Ever" />
<meta property="og:description" content="This website rules" />
<meta property="og:image" content="http://example.com/image.png" />
Both services were displaying the correct image, but I changed the image (and filename) in og:image. Only Facebook is showing the new image, after running it through their URL debugger. Google+ is showing the old image, I also ran my URL through their debugger, but the image will not update. Anyone know why?
Use the structured data tool to check what metadata / schema Google is parsing out. Also, sometimes the service is caching data, try appending an anchor or parameter to your URL while testing (e.g. https://foo.com becomes https://foo.com/#test1 https://foo.com?bar=1). The time it takes for the cache to invalidate is not known, so the only consistent way to force the crawler to recalculate the snippet that appears for your page is to change the url.
You might want to try generating schema using the Google+ snippet tool. Also, note that article rendering has requirements that you can follow to control how images appear in the stream. Note that if you want your content to render with a large image, you must specify article, blog, or blog posting for the schema type.
I have a page using something along the lines of
<meta http-equiv="refresh" content="0;url=http://example.com/" />
but for certain users on a certain workstation this doesn't work. The is in IE. Is there something wrong with cookies or a setting somewhere which would cause this to fail? I never heard of such a thing.
The problem is that when IE sees this:
<meta http-equiv="refresh" content="0;http://www.example.com" />
it expects the contents attribute to contain a number. The only time IE will check for a URL is if the content attribute contains "URL=" so the redirect that is most usable in all browsers is this:
<meta http-equiv="refresh" content="0;URL=http://www.example.com" />
The above example would redirect immdetiately but if you changed the 0 for another number it would wait that many seconds. Hope this all makes sense, it should work just fine but I still think my first idea was the better one.
There is a security setting in internet explorer that does not allow meta tag refresh. It is under the Security tab, then choose Custom Level and the Meta Tag Refresh under Miscellaneous. If that is disabled, it would stop the meta refresh from working.
Aside from being able to disable it selectively, it is automatically disabled if you set IE's security level to 'High' [observed in IE9].
is it a really old version of IE? if so, try:
<meta http-equiv="refresh" content="0;url=http://example.com/"> </meta>
It needs a white space. HTML editor will complain, but just ignore it.
Check out this solution. It handles both javascript and meta-refresh at the same time:
Meta-refresh and javascript
The META tag is not an empty tag and does not have a closing tag in HTML, only in XHTML. (If you are really are sending XHTML, it may not work right on older versions of IE anyway, there are only workarounds to send XHTML to older IE versions.)
Try:
<meta http-equiv="refresh" content="0;url=http://example.com/">
W3 Schools META Tag Description
You might also try:
Checking the major and minor versions of IE. You can do this on the help->about menu option.
IE has historically gotten all confused by filenames and MIMEtypes. Make sure that you are sending your HTML as an htm or html extension file, and that those filetypes are set up on your server to send text/html mimetype.
Make sure your server isn't sending a conflicting meta refresh http header.
In case anyone tries to use meta refresh to redirect to new URL in Facebook applications ( either Page Tab app or IFRAME app ), the tag is disabled by Facebook somehow.
Workaround is:
<script>
top.window.location = 'http://example.com';
</script>
Remember to target "top", as Facebook applications are in IFRAME.
Just a wild guess: maybe there are some adblockers installed on those machines where the redirect does not work.
Can't think of any other reason why this common technique works on some machines while it fails on others for you.