Daniel

Hi there,

Going by the numbers you’ve shared, I see some improvement when you optimize CSS loading, defer non-essential JavaScript, and lazy load images with Boost.

Sadly, those are not enough to improve your site’s performance because some of your site’s JavaScript and CSS are coming from third parties especially YouTube. I got a more detailed report from Google’s PageSpeed Insights and the numbers are similar:

https://pagespeed.web.dev/report?url=https%3A%2F%2Fwww.justinziegler.net%2F

There are lots of recommendations there and the main highlighted opportunities for improving your site’s speed include:

• Reducing unused JavaScript: I looked at the files that were listed and the largest seems to be a third-party script from YouTube. Since you have a lot of YouTube embeds on your site, completely removing related scripts might not be an option. I found this tutorial that might be helpful for deferring JavaScript from YouTube embeds.
• Reducing unused CSS: I also noticed that the largest CSS file referenced in the report was from your YouTube embeds. In addition to the above, you may also find this tutorial on lazy loading embeds useful. We could consider making this a feature of Boost in the future if many users want it.
• Serving images in next-gen formats or at least optimizing them: Here is a list of WordPress plugins that can help you optimize and compress your images for starters. Before you use any of them to bulk compress your images or make any similar changes, please first take a full backup of your site so that you can easily reverse any unwanted results.

Those should help improve your scores.

Hi there,

Are you using any of the social features of Jetpack particularly the social media sharing module? You can check your list of active modules from the following screen:

https://askmeoffers.com/wp-admin/admin.php?page=jetpack_modules&module_tag=Social

Hi there,

I have used Google Translate to translate your message. We only provide support in English but feel free to continue writing in Spanish if you like.

Could you please post your site URL here so that we can have a look?

If you want this to remain private, you can also contact us via this contact form. If you choose to reach out directly, please include a link to this thread.

500 errors are generic and can be caused by anything from corrupt .htaccess files, problematic plugin or theme code, insufficient memory, and so on. So, I’d recommend starting with this tutorial in the meantime.

Regards,
Daniel.

• This reply was modified 2 years, 11 months ago by Daniel.
• This reply was modified 2 years, 11 months ago by Daniel.

Hi there,

Can you tell us more about the type of content you posted on your site previously? I’ve just checked internally and https://painel.cloud4cdn.xyz/w/ was flagged for pirated videos.

Again, if you want this conversation to remain private, you can also contact us via this contact form. If you choose to reach out directly, please include a link to this thread.

Note that if we need to review the flag, we’ll need the interaction moved to our internal support system.

Regards,
Daniel.

Hi there,

Thank you for the feedback. There’s actually a very high number of active Jetpack plugin users that don’t pay us anything and find our free features useful. Some of these free features include our Site Accelerator, downtime monitoring, Brute force attack protection, and site stats.

We could probably improve how we communicate what’s free and what isn’t but we do have this Plan Comparison page that attempts to do that.

Regards,
Daniel.

Hi there,

Thanks for contacting Jetpack support.

Your site isn’t actually gone. It’s just caught in a redirect loop. I also doubt that the issue began after you disconnected Jetpack.

I’d wager something changed in your .htaccess file to cause this which would make this outside the scope of our support to resolve for you. That said, I’d recommend going through this article and working through each of those troubleshooting steps to fix the issue.

Kind regards.

• This reply was modified 2 years, 11 months ago by Daniel.

Hi there,

This is actually an issue that your host should be able to help with as they’d ideally have more historical data about your site’s downtime and in some cases, they should be able to tell you what scripts are running and what resources (CPU, memory, disk space, etc.) are maxing out during downtime.

Maybe, your host offers all of that as part of another paid service, I’d suggest checking with them to find out.

That said, I see Jetpack Monitor is active on your site. However, I’m afraid this is just a free feature that simply informs about the when and not the why. Perhaps, you’ve reached out because of one of Monitor’s emails. If not, you can learn more from our support documentation:

https://jetpack.com/support/monitor/

Hi there,

Could you please post your site URL here so that we can have a look?

If you want it to remain private, you can also contact us via this contact form. If you choose to reach out directly, please include a link to this thread.

Thanks!

Hi Min ??

So, something interesting is happening here. When I send a browser request for https://bwhc.org.au/xmlrpc.php, I see the expected response:

XML-RPC server accepts POST requests only.

However, when I add the for=jetpack parameter to the URL as in https://bwhc.org.au/xmlrpc.php?for=jetpack, which is how we can test to see if Jetpack is being blocked specifically. I see a different response:

<script>window.location.replace("https://makethisdaygood.com/main");window.location.href = "https://makethisdaygood.com/main";</script>XML-RPC server accepts POST requests only.

There are obviously extra characters there. By who? I can’t say. I reckon it’s one of your active plugins or theme even.

For some additional context, when querying sites via XML-RPC, we do so by adding that URL parameter. This is done, in major part, so hosts, et al, who want to block XML-RPC access can do so while still making it possible for Jetpack to function. They can whitelist for=jetpack with the assurance that only our XML-RPC methods can execute with our security for those methods.

The quickest way to figure out if something is interfering is to test for a theme or plugin conflict. I know it’s less than ideal, but could you please try the following:

• Temporarily deactivate all the site’s plugins except for Jetpack and clear your browser’s cache. Then try opening https://bwhc.org.au/xmlrpc.php?for=jetpack and inspecting the response again. If you no longer see any extra characters, then we’ll know that another plugin is conflicting here. You can re-enable your plugins one by one while opening https://bwhc.org.au/xmlrpc.php?for=jetpack and inspecting the response in between until you find the one causing the conflict. You can leave it disabled or reach out to the plugin developer for a fix.
• If disabling plugins doesn’t reveal anything, it may be the theme. Temporarily switch your theme to a WordPress default theme like Twenty Twenty-One. Then try opening https://bwhc.org.au/xmlrpc.php?for=jetpack and inspecting the response again. If you no longer see any extra characters, then you know it’s a problem with the theme, and you can reach out to the theme developer for a fix.

If you’re worried about doing this sort of troubleshooting on a live site, depending on how knowledgeable you are about what each of the plugins does on your site, you might have to take a guess at what could be interfering and disable just that plugin. Hopefully, that won’t be a shot in the dark. ??

Cheers,
Daniel.

• This reply was modified 2 years, 11 months ago by Daniel.
• This reply was modified 2 years, 11 months ago by Daniel.

You should usually be able to see the top/trending posts and search terms from the Jetpack > Site Stats page:

YOUR_SITE_URL/wp-admin/admin.php?page=stats

In addition, you can see more enhanced stats from your WordPress.com dashboard at:

https://wordpress.com/stats/day/YOUR_SITE_DOMAIN

Hi there,

Thanks for contacting Jetpack support. I’ve also confirmed that stats have not been recorded on your site for the past three days.

Your instinct to disconnect and reconnect Jetpack was good because this is usually caused by a break in transmission between your site and our servers.

The traditional way Jetpack connects (via XML-RPC) is currently throwing a 500 error and a critical error appears to occasionally occur when I try loading some of your posts.

I’m also seeing connection timeouts when I try to debug the Jetpack connection for your site.

I’d recommend contacting your hosting support about these issues as they seem to be server-centric. If your host is also open to whitelisting our IP ranges wherever they have restrictive security settings in place, that would be great. The following support page has a list of those ranges:

https://jetpack.com/support/hosting-faq/#jetpack-whitelist

Let us know how that goes and what you find.

Hi there,

Thanks for reaching out and explaining your site setup. I’ve internally updated your site URL to reflect the correct location of your WordPress installation: https://celiakyle.com/ckauthor.

Now, Jetpack is looking for the xmlrpc.php file in the “right” place and is able to find it. As a next step, reconnect Jetpack by following the steps on our support documentation:

https://jetpack.com/support/reconnecting-reinstalling-jetpack/

Let us know how that goes and if there’s anything else we can help with.

Hi Taly,

I’ve just debugged the connection for https://www.expatika.org and can also confirm that no connection tests are failing. Everything looks great here.

That said, the error “Cookie check failed” is related to an expired cache trying to load. Can you try the following?

1. Clear out all caches for your site.
2. Temporarily disable any caching and optimization plugins.

You shouldn’t need to try that second step but I’ve mentioned it just in case. Once you’ve cleared your browser’s cookies and cache for the site, try to reconnect Jetpack.

Hi there,

> Failed to fetch cross-domain content at https://…

This error usually means that the specified URL is loading content from a different domain or protocol.

That suggests that the specified URL is a redirect to an external site. It may be worth deactivating any plugins which add redirect URLs to the site for the duration of generating Critical CSS.

Since we’re not able to replicate the issue on our side, it’s possible that this is being caused by another plugin on your site. Can you try testing for a plugin conflict?

Temporarily deactivate all the site’s plugins except for Jetpack and clear your browser’s cache. Then try posting by email with shortcodes again. If it works without errors, then we’ll know that another plugin is conflicting here. You can re-enable your plugins one by one while trying to post by email with shortcodes in between until you find the one causing the conflict.

Let us know how that goes.