You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[x] bug report => check the README and search github for a similar issue or PR before submitting
[ ] support request => check the README and search github for a similar issue or PR before submitting
[ ] feature request
Current behavior
So this is a bit of a weird one, but it appears that any metas set via the router definition does not get crawled, despite them being set and appearing in the html. If I set them programmatically, they work.
Expected/desired behavior
Regardless of how you define the metas the crawler should be able to read them properly.
Minimal reproduction of the problem with instructions
Define title and description in router, while having a p tag with a text in that same router component template. Then use https://developers.facebook.com/tools/debug/sharing/ to crawl it (cannot be localhost) and you will see that the p tag acts as the description instead of the og:description tag for example. This is down to facebook picking the first p tag when it cannot find a description meta.
What is the motivation / use case for changing the behavior?
Please tell us about your environment:
Angular version: 2.0.X
2.3.1
Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
all
Language: [all | TypeScript X.X | ES6/7 | ES5]
all
Node (for AoT issues):node --version =
6.7
The text was updated successfully, but these errors were encountered:
fulls1z3
changed the title
Metas set only via the router definition does not get crawled correctly by facebook, while the programmatically set does
[duplicate] metas set only via the router definition does not get crawled correctly by facebook, while the programmatically set does
Mar 16, 2017
As mentioned in #4, cannot be solved with client-side techniques.
Generated metadata is not currently accessible by bots except Google crawler. For now, the only method to generate meta tags at the server-side in order to be crawl-able by bots such as facebook.
However, I'm keeping track of developments with those crawlers/bots and will publish updates as things become available.
It is aimed in rc.5 to use @angular/universal to dynamically re-render each request. You can track the status on #20.
I'm closing this issue both the reasons it's a duplicate and tracked on #20.
fulls1z3
changed the title
[duplicate] metas set only via the router definition does not get crawled correctly by facebook, while the programmatically set does
metas set only via the router definition does not get crawled correctly by facebook, while the programmatically set does
Sep 16, 2017
I'm submitting a ... (check one with "x")
Current behavior
So this is a bit of a weird one, but it appears that any metas set via the router definition does not get crawled, despite them being set and appearing in the html. If I set them programmatically, they work.
Expected/desired behavior
Regardless of how you define the metas the crawler should be able to read them properly.
Minimal reproduction of the problem with instructions
Define title and description in router, while having a
p
tag with a text in that same router component template. Then use https://developers.facebook.com/tools/debug/sharing/ to crawl it (cannot be localhost) and you will see that thep
tag acts as the description instead of theog:description
tag for example. This is down to facebook picking the firstp
tag when it cannot find a description meta.What is the motivation / use case for changing the behavior?
Please tell us about your environment:
Angular version: 2.0.X
2.3.1
Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
all
Language: [all | TypeScript X.X | ES6/7 | ES5]
all
Node (for AoT issues):
node --version
=6.7
The text was updated successfully, but these errors were encountered: