If you run an LFM traffic exchange or mailer script, you are sitting on top of a highly targetable target. Because these scripts have been around for a long time, bad actors constantly scan them looking for direct access to files hidden deep inside your system folders—like inc/, lib/, or lfm_plugins/, hoping to find unpatched files they can exploit.
By locking down those directories, you keep your script incredibly safe. But if you want to apply this .htaccess rule and run Google AdSense or utilize Google’s crawling bots, you need to make sure you don’t accidentally lock Google out of the resources it needs to verify and monetize your site.
Here is a complete, developer-friendly guide on how to implement this security rule while keeping Google happy.
Why It Matters to Protect LFM Script (And The Google Conflict)
Your script’s core engine files and plugins should only ever be executed when called by main gateway files (like index.php, mybanners.php, or surfing.php).
The rule you shared stops hackers dead in their tracks:
RedirectMatch 403 ^/(themes|inc|lib|xlib|surf_modules|lfm_plugins|plugins)/.*\.php$
If a malicious bot tries to type [https://yoursite.com/inc/funcs.php](https://yoursite.com/inc/funcs.php) directly into their browser, your server throws a 403 Forbidden error.
The Google Problem
If you are working with Google (especially Google AdSense or Google Search Console), Google’s automated crawl bots need to inspect your site to understand its layout, look for policy violations, or read dynamically generated page layouts.
While Google rarely needs to read raw backend .php files in your inc/ or lib/ folders directly, their crawlers do need access to your assets (like CSS, JS, and images) inside folders like themes/. If your system uses dynamic PHP files to generate stylesheets or custom themes on the fly inside those folders, the strict block above might cause Google to flag your site as “unreachable” or “unusable on mobile.”
How to Safe-List Google While Blocking Hackers
⚠️ Important Notice: Use these code snippets at your own risk. This guide is provided for educational and security hardening purposes as a general recommendation. We do not assume any responsibility or liability if these modifications break your site or conflict with custom plugins. Always back up your file before editing!
To get the best of both worlds, maximum security for your LFM script and seamless integration with Google, you have two main options to adjust your setup.
Option 1: The Modern .htaccess Way (Recommended)
Instead of a blunt RedirectMatch 403 that blocks absolutely everyone, you can use Apache’s mod_authz_core to block direct PHP execution unless the visitor is verified as a Google bot.
Replace your single-line redirect with this block in your .htaccess file:
# Protect sensitive directories from direct PHP execution, except for Google
<IfModule mod_authz_core.c>
<FilesMatch "\.php$">
<If "%{REQUEST_URI} =~ m#^/(themes|inc|lib|xlib|surf_modules|lfm_plugins|plugins)/#">
Require all denied
# Allow verified Googlebots to crawl if they hit a dynamic script
Require expr %{HTTP_USER_AGENT} =~ m#Googlebot|Mediapartners-Google#
</If>
</FilesMatch>
</IfModule>
What this does: It tells your server: “If anyone tries to load a .php file directly inside these folders, block them instantly. However, if the requester identifies as a Google Crawler (Googlebot or Mediapartners-Google for AdSense), let them through so they can scan the page’s output.”
Option 2: The Third-Party Subdirectory Rule (Hesk, WordPress, etc.)
If you run helper platforms in subdirectories of your LFM site such as a Hesk Help Desk (/help/ or /support/), a WordPress Blog (/blog/), or other third-party membership scripts; Google bots will frequently crawl these directories.
Because Apache rules in your root folder automatically cascade downwards, your LFM security restrictions might accidentally break the themes, plugins, or attachments of these helper scripts.
To prevent this, add a local .htaccess file inside your subdirectory (e.g., /support/ or /blog/) to override the parent restrictions:
# Place this in your subdirectory .htaccess (e.g., /support/ or /blog/)
# This ensures local PHP and theme files remain crawlable and fully functional
<Files *.php>
DeclareParentSettings Off
</Files>
Google AdSense Checklist to protect LFM script
If your main goal is getting approved or staying compliant with Google AdSense on a traffic exchange, keep these three rules in mind:
- Keep
ads.txtin the Root: Google absolutely requires yourads.txtfile to be accessible at[https://yoursite.com/ads.txt](https://yoursite.com/ads.txt). Ensure your rewrite rules do not block or redirect.txtfiles in the root. - Don’t Block CSS/JS in Robots.txt: Ensure your
robots.txtfile is not blocking Googlebot from reading resource files inside your/themes/folder. Google must be able to load your CSS to prove your site is mobile-friendly. - The Frame Rule: Remember that Google AdSense has strict policies about placing ads inside frames or pages that auto-surf/refresh. Keep your Google ads on your static landing pages, blogs, and member dashboards; never on the surf bar page itself!
Final Verdict
Protecting your website from intrusive people with everything but good intentions is a must when running your business. We, here at Bizeem, are at your service, should you need any help. You can also check out our tutorials here!
Is Google Stealing My PHP Code? How Crawlers Interact with LFM
[…] breaking your search rankings or losing your AdSense monetization, read our companion guide on how to protect your LFM script folders without blocking Google AdSense, where we share a custom, copy-and-paste .htaccess rule that solves this exact […]