Listing issues resulting in long load times and SERP deindexing

For the past couple months, I’ve noticed that listings for retirementbeing.com will periodically take much longer to load (upwards of 8-10 seconds instead of the normal 2-3). When this happens, listing pages are also “unable to resolve” in Google PageSpeed Insights when a first attempt is made. A second (or sometimes third) attempt will usually succeed.

Moreover, Google’s average crawl response time is upwards of 3,000 ms (this number should be 800 ms at most). I’ve also noticed thousands of pages have been deindexed by Google over the last couple months, most likely due to the long crawl response times. As a side note, the site is optimized for SEO and has excellent scores in PageSpeed Insights and GTMetrix.

I’m using HivePress with a third party theme and have had no issues with other pages of the site, such as blog posts. HivePress category pages also consistently load quickly. This issue is solely with the listings of Retirement Being. It seems that something is intermittently causing the loading process to get hung up, resulting in substantial load time delays and poor performance.

Over the past few months, I’ve had this site hosted with three different companies, thinking at first that the issue had to do with the host, which no longer seems to be the case. I strongly believe this issue has to do with the HivePress plugin itself, more specifically with HivePress listings.

Can you please investigate this so as to discover the root cause?



Thanks for the detailed issue report. Please let me know if there’s the same delay when you view the listing page in the browser or it occurs for the Google crawler only? There are many listings on your website, but this shouldn’t cause performance issues when a single listing page is viewed (it can slow down search by multiple criteria though) since WordPress just fetches a single listing by ID, and HivePress then displays its details.

If you’re familiar with SQL basics, you can also use the Query Monitor plugin, it will indicate queries that slow down the page, and duplicated queries.

There’s a delay of 8-10 seconds when I view the page in a browser. I’ve tried multiple browsers and networks. I’m not familiar with SQL basics.

@ihor I installed Query Monitor and I’m seeing a load time of 6 seconds for listings, 1 slow query that’s accounting for over 5.5 seconds and 93 duplicate queries. The slow query looks to be related to Related Listings. Can I provide you admin access to look into this further?

@ihor I just removed Related Listings and it solved the issue, however, I need that section for SEO purposes. Please advise.

Yes, related listing query may be pretty expensive if there are many listings, especially if you use Geolocation - then there’s a query that also filters nearest listings only, making the query slower. Please try using a caching plugin that caches the listing page, so it’ll be a static HTML that will not run all the queries on every page refresh. Another solution is making the related listings query more simple (e.g. by disabling the location filter), but this requires code changes.

I’m already using W3 Total Cache. Can you provide assistance on setting up the plugin to cache the listing pages properly?

If you already use a caching plugin please make sure that it caches listing pages for non-registered users, search engine bots are recognized as non-registered visitors so they should be served with static HTML (instead of running all the scripts and queries). You can also try using WP Rocket or LiteSpeed plugin instead.

Can you recommend a WordPress developer who can correctly set this up?

All I’m seeing is this: Cache URIs with query string variables. Search result (and similar) pages will be cached if enabled.

But that doesn’t help anything.

If you use a premium version of their plugin please try contacting their support, they should help to enable caching for custom post types (listing is a custom post type “hp_listing”). If cache is enabled it should work by default, SQL queries shouldn’t run when the listing page is visited - there should be a static HTML.

You can hire someone for assistance via Fiverr (caching and optimization don’t require HivePress-specific knowledge) https://fvrr.co/32e7LvY or use another caching plugin (e.g. WP Rocket, a few customers reported that it works fine).

I’m now using WP Rocket but the same issue is occurring. I’ve spoken with WP Rocket’s team but haven’t received a solution. Is there anything that can be done on HivePress’s side to resolve this?

Please make sure that you’re logged out when you test the listing page. If so then no SQL queries should run on this page, it should be static HTML so it shouldn’t be slowed down. You can also check WP Rocket settings, maybe post types to be cached must be selected explicitly.

I’m testing it now but since re-enabling the “Related Listings” section, some of the listings have the correct CSS, while others don’t. See the below example URLs with corresponding screenshots.

Related Listings CSS is correct: Aberdeen Memory Care of Tulsa | Retirement Being

Related Listings CSS is incorrect: Accordius Health at Creekside Care | Retirement Being


Yes, for some reason WP Rocket doesn’t include these styles for this listing, please try to purge JS/CSS cache, it should be re-generated. This style in the source code includes listing styles when I check the first link, but it’s not for the second link:

<style id="wpr-usedcss">

That solve that issue. Thank you.

The other issue regarding the long load times when Related Listings is enabled is still occurring. I’m testing the listing pages from a private window while logged out. WP Rocket has informed me that nothing needs to be explicitly selected for a post type to be cached–it works automatically. Can you look further into this? I currently have Related Listings enabled.

Sorry, we can’t debug a caching issue because it’s not HivePress functionality but I can provide some guidance if this helps, you can enable caching for logged-in users and check the listing page while being logged in (with Query Monitor), to check again if the cache is server, or all the PHP scripts and queries still run (they shouldn’t if the whole page is cached).