jhm

Hey Chris,

there was no intention to argue ?? was just telling to rise awareness, that a single plugin can not validate the final output of the whole engine (influence of other plugins). that was an issue in the past, because people assumed that just by installing the plugin “everything is fine”. reality is, that other plugins (or template) sets noindex flags, etc. so an external check makes sense to prevent the owner from harm (aka de-indexation).

Hope you see that the intention was good – but it’s a valid feature-request to opt-out of these checks, if someone does not appreciate this kind of monitoring.

Hi Chris,

we released an more detailed FAQ page covering your questions – you can find it here:
https://en.onpage.org/lp/yoast/faq/

Quick summary: No data is stored at all.

All in all this coop was intended to give people the security, that their page is really indexable. Especially because additional plugins might be deleting the optimizations done by yoast, which is not “detectable” from the inside of the WP Plugin world.

So all in all: the whole service is for free and no data is stored.

Best, Merlin
(CTO // OnPage.org)

Hey M,

yap, Wordfence seems to be the cause. We already reached out to them to get this out of the way.

They seem to block all our crawlers and return a 403 error … thats why we report “not indexable” because it looks like your webserver generally tells bots to go away.

Looks like nothing you or we could do at this moment. We will try to convince the Wordfence guys to whitelist our crawlers, so these “false positive” Warnings do not confuse users of both plugins.

thanks for the feedeback and sorry again for the confusion!

Hey M,

to investigate in that case i need your domain. is it https://www.mediasinfo.ro/ ?

Best, Merlin

PS: Sounds like your hoster blocks requests based on useragents, but i need to validate

Hey Wendihihihi – sorry to hear that you faced these issues.

Can you provide the domain name (via mail -> jhm (at) onpage.org), so we can have a look, if there is bug on our end or if the message is valid?

in the end the idea behind the widget is to make an indexability check from the outside, not just WP-internal. On a small set of users there are problems caused by security settings of the hosting-provider – as they block our crawler and this can cause “false positives”.

So would be great if you could send us the domain name so we can do some investigations.

guess i agree – gave it a try the last couple of days but it seems that doesn’t even fetch main shorteners as tr.im or bit.ly. too sad ??

If it still matters – you can fix your problem in wp-includes/media.php in line #596 (WordPress 2.8 – maybe in another line in other WP Versions):

return '<div ' . $id . 'class="wp-caption ' . $align . '" style="width: ' . ($width) . 'px">'
	. do_shortcode( $content ) . '<p class="wp-caption-text">' . $caption . '</p></div>';

(In the original Code there is a (10 + (int) $width) in the style:width definition.

regards,
jhm

CSS wont help you, unless your images have always the same width, then you could force a width with
width:300px !important;

but this 10 extra pixels are actually added by wordpress and its get done by some sort of hardcoded way (-> into the html tag) – that way you can’t make the box “10 pixel smaller” via css. i think the only solution is to find that section in the WP code and disable the addition.

regards

Yeah i have noticed the same Problem as ihatemornings – bit.ly seems to create multiple short urls for the same permalink ??

Oh, i just realized that the problem is caused by my ISP – i am surfing via an UMTS connection (“surf stick”) and there seems to be a proxy which does the described compressions – probably in order to reduce load.

thanks for reading anyway ??