-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should we exclude rel=nofollow
by default?
#309
Comments
Relevant WordPress issue: WordPress/performance#1140 |
I like this idea in theory. But I can't think of how we would reasonably specify it or explain it. "You said to prerender 'all links matching the Maybe it's best to just take this as good advice for when we create examples and documentation? Not sure. |
Well I was thinking it would only be for document rules and wouldn't be overridden. In the same way that But we could add a |
It does match :) |
I'm confused. This example: https://prerender-demos.glitch.me/document-rules.html has this: <p><a href="next.html">This link should be eligible to be prerendered</a></p>
<p><a href="next2.html">This link should also be eligible to be prerendered</a></p>
<p><a href="https://www.example.com">This link is external and should not be eligible</a></p>
<script type="speculationrules">
{
"prerender": [
{
"where": {"href_matches":"*"},
"eagerness": "moderate"
}
]
}
</script> But shows this in devtools: So the external link is excluded from the list of potential speculations? And that makes sense to me as the URL pattern has a base of the document AFAIK. |
You're right, that's because |
We've discovered that WooCommerce "add to basket" buttons are regular links. Now of course that breaks all sorts of GETs should be idempotent but such is the web.
They do implement a
rel=nofollow
to prevent search engines following such links. We're going to add it to our WordPress plugin, but I wonder if that's something we should do by default since it seems like a good sign that it's unexpected to be followed by bots and only by real humans.Not sure if this is a spec question, or should be up to individual implementers so raising here first.
The text was updated successfully, but these errors were encountered: