Jelena

Hi,

Thanks for sharing your experience, even though it was clearly a difficult one.

We’d like to offer some context that we hope brings some clarity, not just in this case, but for anyone reading this.

Shield Security is built around one core principle: prevention. It works continuously to block attackers, malicious bots, and suspicious traffic at the WordPress application level, stopping the vast majority of threats before they can cause any harm. The free version already provides solid, meaningful protection every single day. It’s also worth considering that a site can arrive already compromised before any security plugin is installed, in which case no plugin ever had the chance to prevent anything. Calling Shield useless overlooks everything it had already blocked.

Without knowing what actually happened on this site, all we can honestly say is this:

Security is an ongoing process, and even the most advanced solutions have limits. Compromises that originate below the WordPress application layer, whether through the hosting environment, direct file system access, or a server-level breach, are simply beyond the reach of any WordPress security plugin, free or not, from any provider.

It’s also why visible symptoms alone are never a reliable measure of safety. The fact is that many compromised sites run completely silently for months, serving malicious content or sending spam to visitors while the admin sees nothing unusual at all. Attackers do this deliberately. Staying hidden means staying in. A quiet site is not always a clean site.

This is exactly why we strongly recommend all WordPress users: prevention, to perform regular security audits of their sites. A security plugin is one important layer, but It’s worth taking a few minutes each week to perform a site review to catch issues early and wherever possible.

On scanning: any scans detect damage after it’s already happened. They do not prevent attackers from getting in. Shield includes free real-time scanning for WordPress core file integrity and abandoned plugins, running continuously. Not all free scanners work this way. Some rely on threat definitions that can be weeks out of date, meaning recently introduced threats may pass through completely undetected. A scanner that misses newer threats can create a false sense of security, which is a risk worth being aware of when choosing how to protect your sites.

Finally, we also want to be transparent: we were never given the chance to help. We had no opportunity to investigate what actually happened, identify the root cause, or guide you through a proper recovery. That is genuinely unfortunate, because that’s exactly what our support is here for. Had you knocked on our door, we’d have been there. That door is always open, and our support forum is always the right first step.

Regards and sincerely wish you and your client all the best going forward. 🙂

Jelena, Shield Security Team

Hi there,

Thanks for such a good question and for outlining exactly what you’re seeing, it’s much appreciated.

The addresses you’re seeing belong to Shield’s internal security API. They’re used by our silentCAPTCHA AntiBot system to quietly confirm that a visitor is a real human and not a bot. This is normal behaviour for Shield when bot protection is active.

In Google Search Console, the status “Crawled – currently not indexed” means Google can reach those technical URLs but has decided not to add them to the index. For internal API endpoints like this, that’s expected, because they’re not real pages and aren’t meant to appear in search results.

So what you’re seeing there is normal and not a problem caused by Shield. There’s nothing you need to change in the plugin for this specific case. If those entries are just noisy in your reports, you can filter out the internal Shield API URLs in Google Search Console so you can focus on your real pages.

Hope this helps.

To function correctly, Shield will try to write to its own plugin directory, as well as 1 of:
wp-content/shield/
wp-content/uploads/shield/

Based on what you described, the issue is likely occurring because Shield is unable to write and then read its required test files in any of its supported storage locations:
the plugin directory, wp-content/shield/, or wp-content/uploads/shield/.

When this happens, Shield treats the environment as unstable and repeatedly triggers re-authentication, which causes the redirect back to the homepage with reauth=1 instead of allowing access to the WordPress admin. The specific error in your log shows that Shield tried to read a test file in wp-content/uploads/shield/, but the file was not found, which indicates the initial write test failed.

Even if permissions on the folders appear correct, Shield can still fail its file tests if the PHP process cannot actually write to the folder, if server security restrictions block file creation, or if the folder doesn’t exist or is partially damaged for some reason. This could explain why checking permissions alone wasn’t enough to resolve the issue…

To fix this, you can remove both wp-content/shield/ and wp-content/uploads/shield/. It’s safest to do this while Shield is deactivated, but even if the plugin is active, removing these folders is generally safe and shouldn’t affect your site or content. After removing them, simply re-enable Shield and it will automatically recreate the folder and its test file. Once this is successful, the login redirect issue and related errors should stop.

If the folders are not recreated after re-enabling Shield, this usually indicates that the server environment is preventing the plugin from writing its own files. Common causes include file system restrictions set by the hosting environment, security modules that block file writes, or the PHP process not having permission to write to the WordPress directories. In this case, you may need to check with your hosting provider to ensure Shield can write to one of its supported storage locations.

Also, make sure that caching isn’t causing the troubles.

Hope this helps.

Since there’s been no activity for a few days, we’ll be closing this thread.
Thanks for joining in, and we hope everything’s going well.

Regards,
Jelena

Hi @deeveearr, I’m really glad to hear you managed to get everything working again.

And huge thanks to @hcabrera for pointing you in exactly the right direction. 🙂

Just to add a little extra context: Shield’s “Anonymous REST API” setting is designed to block unauthenticated requests to the REST API. This can be a great security measure, but as you’ve seen, it can also block legitimate plugins (like WordPress Popular Posts) that rely on those requests.

That’s why we also provide an exclusions option — this lets you whitelist specific API endpoints so your important plugins can keep working smoothly, while still keeping the rest of your site locked down.

So, you’ve got 2 easy ways forward here:

1. Keep the option disabled — which is perfectly fine if you don’t need that particular protection.
2. Use the ‘Rest API Exclusions’ list — this lets you re-enable the option, but still allow anonymous access for the specific API endpoints used by plugins like Popular Posts. That way you keep the protection in place for everything else.

Either approach works, so it’s really down to what feels best for your setup.

Thanks again to you both, awesome teamwork!

Jelena

Hi,

It’s been a few days since we last heard from you, so I’ll be closing this thread for now. If you have any further questions, you’re welcome to reopen the conversation.

Thanks.

Do you have your IP whitelisted in Shield? Can you double-check that that’s not the case?

Thanks.

No problem at all. Great to know things are running smoother now.

Regarding autoloads:

It’s normal to see autoloaded options related to Shield, especially if the plugin was used across different versions. These can add up and take some space.

You can safely delete all entries starting with shield_mod_config_* as these hold configuration data for Shield features. Don’t worry, if any are needed again, Shield will automatically rebuild them as required. So if they start building up again, you can just run the delete command again to clear them out.

There aren’t specific Shield options that must stay autoloaded for the plugin to work properly. Shield dynamically loads only what it needs.

Also, these autoloaded options generally have minimal impact on site speed or performance because they’re loaded in one SQL query. So while cleaning them up reduces autoload size, it likely won’t make a big difference in speed.