If you run a WordPress site, it is easy to assume that every warning in Google PageSpeed Insights is a speed problem. In practice, that is not always true. Some of the most common Lighthouse notices belong to the best practices and security side of the audit, not only to performance.
That distinction matters. A slow image, an oversized script, and a missing security header may all appear inside the same PageSpeed Insights report, but they are not the same kind of issue. Some fixes involve page speed. Others involve browser behavior, HTTPS configuration, security headers, or the way WordPress loads scripts, plugins, forms, and embedded content.
For site owners, developers, and marketers working with WordPress, this can be confusing because a warning may look urgent even when it is not directly hurting rankings or load speed. The right response is not to chase every notice blindly. The right response is to understand what the warning means, decide whether it is simple or risky to fix, and test the site carefully after each change.
That approach helps you improve site quality without accidentally breaking contact forms, tracking scripts, payment tools, booking systems, page builders, cookie banners, or other functionality your business depends on.
Below is a practical guide to some of the most common PageSpeed Insights and Lighthouse warnings you may see on a typical WordPress site, with extra context for users who are not used to working with server files or command-line tools.
Before You Start: A Few Tools and Concepts You Should Understand
Some of the fixes below involve editing server configuration files or running simple commands. If you have never used a terminal, console, or .htaccess file before, do not worry. The concepts are not as intimidating as they look, but they do require care.
What Is the Terminal or Console?
A terminal, sometimes called a console or command line, is a text-based tool that lets you send instructions directly to your computer or server. Instead of clicking buttons in a visual interface, you type a command and press Enter.
For example, later in this article we will use commands such as:
curl -I https://example.com/
That command asks a website to return its HTTP headers, which are small pieces of technical information browsers use to understand how the site should behave.
There are two common places where you may run this kind of command:
- Your hosting account terminal, such as the Terminal feature inside cPanel.
- Your local computer terminal, such as Terminal on Mac or PowerShell / Windows Terminal on Windows.
If your hosting account uses cPanel and Terminal is enabled, you can usually find it by logging in to cPanel and searching for “Terminal” in the cPanel search bar. When you open it, you are working directly inside your hosting environment. Some hosting providers disable this feature for security reasons, so you may not always see it.
On a Mac, you can open your local terminal from Applications > Utilities > Terminal. On Windows, you can open PowerShell or Windows Terminal from the Start menu. For the simple curl checks in this article, using your own computer is often enough.
The important point is this: when this article says “run this command,” it means you should open one of those terminal tools, paste the command, replace example.com with your real domain, and press Enter.
What Is the .htaccess File?
The .htaccess file is a configuration file used by Apache-based servers. Many WordPress sites hosted on cPanel use Apache or LiteSpeed, and both commonly support .htaccess rules.
In WordPress, this file usually lives in the main website folder. On many cPanel accounts, that folder is called:
public_html
If WordPress is installed in a subfolder, the .htaccess file may be inside that subfolder instead.
The dot at the beginning of .htaccess means the file may be hidden by default. In cPanel File Manager, you may need to enable the option to show hidden files. This is often available from the File Manager settings panel.
You can usually edit .htaccess in one of three ways:
- cPanel File Manager: Open File Manager, locate
public_html, enable hidden files if needed, right-click.htaccess, and choose Edit. - FTP or SFTP: Download the file, edit it in a code editor, and upload it again.
- A server terminal: Advanced users can edit it from the command line, but this article assumes File Manager is easier for most WordPress users.
Before editing .htaccess, download a backup copy of the file. A small syntax error can cause a server error or take the site down temporarily. If that happens, restoring the previous version usually fixes the problem.
Also, avoid placing custom rules inside blocks generated by WordPress, cache plugins, security plugins, or redirect plugins. Those blocks often look like this:
# BEGIN WordPress
...
# END WordPress
or:
# BEGIN Some Cache Plugin
...
# END Some Cache Plugin
Instead, create your own small section outside those generated blocks. For example:
# BEGIN Custom Security Headers
# Your custom rules go here.
# END Custom Security Headers
This keeps your changes organized and reduces the chance that WordPress or a plugin will overwrite them later.
1. Mitigate Clickjacking with XFO or CSP
This warning appears when the page does not clearly tell browsers whether it can be embedded inside an iframe on another site.
An iframe is a way to display one web page inside another page. This can be useful in some legitimate situations, but it can also be abused. The main concern here is clickjacking. Clickjacking happens when a malicious site loads your page inside a hidden or disguised frame and tricks a visitor into clicking something they did not intend to click.
For many standard WordPress websites, the page does not need to be embedded inside other websites. In that case, the simplest fix is often to send a header called X-Frame-Options.
In a typical cPanel WordPress setup, you can add this rule to your .htaccess file, outside any sections generated by WordPress or cache plugins:
<IfModule mod_headers.c>
Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>
This tells browsers that your pages can only be embedded by the same domain. In other words, another unrelated website should not be able to place your page inside its own frame.
If you already created a custom section in .htaccess, place the rule there. For example:
# BEGIN Custom Security Headers
<IfModule mod_headers.c>
Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>
# END Custom Security Headers
After saving the file, you should verify that the header is actually being sent.
To do that, open the Terminal in cPanel or open the terminal on your own computer. Then run this command, replacing example.com with your real domain:
curl -I https://example.com/
The -I part tells curl to show only the response headers instead of downloading the full page. The output may include many lines, but you are looking for this one:
X-Frame-Options: SAMEORIGIN
If you see it, the header is active.
For more advanced setups, you can also control iframe behavior with the frame-ancestors directive in a Content Security Policy. However, for many WordPress sites, X-Frame-Options: SAMEORIGIN is the easiest and safest starting point.
The risk of this change is usually low unless your site intentionally needs to be displayed inside an iframe on another domain. Examples may include embedded apps, partner portals, learning platforms, or certain booking systems.
2. Use a Strong HSTS Policy
HSTS stands for HTTP Strict Transport Security. It tells the browser to always use HTTPS for your site for a defined period of time.
This is not a speed optimization in the usual sense. It is a browser-level security instruction. Once the browser receives the HSTS header, it remembers that your site should be loaded over HTTPS and avoids trying the insecure HTTP version.
PageSpeed Insights may flag this issue if your site has no HSTS header, if the max-age value is too low, or if the policy is not strong enough.
Before adding anything manually, check whether your hosting stack or security tools already set this header. HSTS may be configured by cPanel, Cloudflare, Sucuri, Nginx, Apache, LiteSpeed, a security plugin, or another server-level tool.
As we did in the previous section, you can inspect the headers with:
curl -I https://example.com/
In the output, look for a line similar to this:
Strict-Transport-Security: max-age=31536000
If the header already exists, do not add a second version blindly. Duplicate or conflicting security headers can make troubleshooting harder.
If the header is missing and your site already works correctly over HTTPS, you can start conservatively by adding a short HSTS policy to .htaccess:
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=3600"
</IfModule>
A max-age of 3600 tells browsers to remember the HTTPS-only instruction for one hour. This is a cautious first step because it gives you a chance to confirm that everything works correctly before committing browsers to a longer policy.
After saving the change, run the same header check again:
curl -I https://example.com/
Look for:
Strict-Transport-Security: max-age=3600
Once you confirm that the site, forms, admin area, checkout, embeds, images, and key pages all work correctly over HTTPS, you can increase the duration:
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000"
</IfModule>
That value equals roughly one year, which is a stronger HSTS policy.
Be careful with the optional includeSubDomains and preload directives. They can be useful, but they also raise the risk level. If you include subdomains, the browser will expect HTTPS to work properly not only on your main domain, but also on subdomains such as:
mail.example.comwebmail.example.comcpanel.example.comstaging.example.comdev.example.com
If any of those subdomains are not configured correctly for HTTPS, users may run into access problems. For that reason, HSTS is best applied in stages.
3. Ensure Proper Origin Isolation with COOP
COOP means Cross-Origin-Opener-Policy. This header helps isolate the main browser window from documents on other origins, especially when your site uses popups, JavaScript-opened windows, or cross-origin interactions.
That sounds technical, so it helps to think of it this way: browsers often allow pages to open other pages, communicate in limited ways, or keep some relationship between windows. COOP gives the browser stricter instructions about how much separation should exist between your site and pages from other origins.
Lighthouse may recommend this header because it improves navigation context isolation. In WordPress, a common implementation is to add this to the .htaccess file:
<IfModule mod_headers.c>
Header always set Cross-Origin-Opener-Policy "same-origin"
</IfModule>
If you already created a custom security header block, you do not need separate <IfModule> blocks for every header. You can combine the headers we have been adding into a single organized section:
# BEGIN Custom Security Headers
<IfModule mod_headers.c>
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Strict-Transport-Security "max-age=31536000"
Header always set Cross-Origin-Opener-Policy "same-origin"
</IfModule>
# END Custom Security Headers
As before, save the file and verify the result with:
curl -I https://example.com/
This time, look for:
Cross-Origin-Opener-Policy: same-origin
This header has a medium-low risk profile for many simple WordPress sites, but it can affect flows that depend on external popups or cross-origin interactions. After applying it, test the most important parts of the site.
Pay special attention to:
- Social login
- Google or Microsoft OAuth login
- Payment tools
- Booking engines
- Reservation widgets
- Chat widgets
- CRM forms
- Embedded third-party tools
- Admin workflows that open popups
The point is not to avoid COOP completely. The point is to avoid assuming that every WordPress site behaves the same way. Add the header, test the site, and remove or adjust it if a critical integration stops working.
4. Ensure CSP Is Effective Against XSS Attacks
CSP, or Content Security Policy, controls what a page can load and execute. It can limit scripts, styles, images, fonts, iframes, connections, and other resources.
In theory, CSP is one of the strongest browser-side defenses against cross-site scripting, often abbreviated as XSS. In practice, CSP must be handled carefully on WordPress sites.
The reason is simple: WordPress sites often depend on many different resources. A typical marketing site may use a page builder, form plugin, analytics script, tag manager, cookie banner, embedded video, map, chat widget, CRM form, Meta Pixel, Google Fonts, icon library, and several plugin-generated inline scripts or styles.
A strict CSP can block those resources if they are not explicitly allowed. That can improve security, but it can also break the visible site or important business functionality.
For that reason, it is usually safer to begin with a report-only policy rather than a blocking policy.
A report-only CSP tells the browser: “Watch for potential policy violations and report them, but do not block the resources yet.” This lets you inspect what would break before enforcing the policy.
Here is a starter example for .htaccess:
<IfModule mod_headers.c>
Header always set Content-Security-Policy-Report-Only "default-src 'self' https: data: blob:; script-src 'self' 'unsafe-inline' 'unsafe-eval' https:; style-src 'self' 'unsafe-inline' https:; img-src 'self' https: data: blob:; font-src 'self' https: data:; connect-src 'self' https:; frame-src 'self' https:; object-src 'none'; base-uri 'self'; frame-ancestors 'self'; form-action 'self' https:;"
</IfModule>
This is not a perfect final CSP. It is a cautious diagnostic starting point for a WordPress environment. It still allows broad HTTPS resources and common WordPress patterns such as inline scripts and inline styles. That means it is not as strict as a mature production CSP, but it is much less likely to break the site immediately.
After adding the report-only policy, open your site in a browser, right-click the page, and choose Inspect or Inspect Element. Then open the Console tab. Browse the site as a normal user would. Submit a test form if appropriate. Open key landing pages. Check embedded videos, maps, popups, menus, and tracking-related functionality.
If the browser reports CSP violations, review them carefully. They help you understand which domains and resource types your site actually uses.
You can also verify that the report-only header exists with the same command we used before:
curl -I https://example.com/
Look for:
Content-Security-Policy-Report-Only:
Only after testing and adjusting the policy should you consider switching from Content-Security-Policy-Report-Only to a real blocking Content-Security-Policy header.
In WordPress, CSP is an important improvement, but it is not a quick one-size-fits-all fix. Treat it as a configuration project, not as a single copy-and-paste solution.
5. Detect and Correct Mixed Content
Mixed content happens when a site loads over HTTPS but some resources are still requested over HTTP.
For example, your page may load securely at:
https://example.com/
but one of the images inside the page may still use:
http://example.com/wp-content/uploads/image.jpg
That creates mixed content. The page itself is secure, but at least one resource is being requested through the insecure HTTP version.
Mixed content can involve images, scripts, fonts, SVGs, stylesheets, plugin files, or old URLs stored in the WordPress database. It can create browser warnings, reduce trust, and cause some resources to be blocked.
A simple way to look for internal HTTP URLs in the final HTML is to use this command:
curl -sL https://example.com/ | grep -o "http://example.com[^\"' <)]*" | sort -u
This command looks intimidating if you are not used to the terminal, so let’s break it down.
curl -sL https://example.com/downloads the final HTML of the page quietly and follows redirects.grep -o "http://example.com..."searches that HTML for URLs that still start withhttp://example.com.sort -usorts the results and removes duplicates.
As before, replace example.com with your real domain.
If the command returns no results, that specific page may not contain internal HTTP URLs in its final HTML. If it does return results, those URLs should be reviewed and updated.
For WordPress sites, old HTTP URLs are often stored in the database. They may come from old media uploads, page builder content, plugin settings, widgets, menus, or theme options.
The safest command-line tool for replacing URLs in a WordPress database is WP-CLI.
What Is WP-CLI?
WP-CLI is the official command-line tool for managing WordPress. It lets you run WordPress tasks from the terminal, including plugin updates, user management, database exports, and search-replace operations.
Not every hosting account has WP-CLI available. To check, open the cPanel Terminal and run:
wp --info
If WP-CLI is installed and available, you should see version and environment information. If the command is not found, your hosting provider may not support WP-CLI on your account, or it may require a different path.
When using WP-CLI, make sure you are inside the WordPress installation folder. On many cPanel accounts, that means:
cd ~/public_html
If WordPress is installed in a subfolder, go to that folder instead.
Before changing anything, test the replacement with a dry run:
wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefix --dry-run --report-changed-only
A dry run shows what would change without actually modifying the database. This is important because database replacements can affect many rows.
If the dry run looks correct, make a database backup before running the real replacement. This backup is a .sql file, which is a copy of the WordPress database at that moment. It does not back up your images, themes, or plugins, but it does give you a restore point for the database before changing stored URLs.
wp db export ~/site-before-http-to-https-searchreplace-$(date +%F-%H%M).sql
This command exports the WordPress database and saves the backup file in your hosting account’s home directory. The ~ symbol means “home directory,” which is usually one level above public_html in a cPanel account. The file name will include the current date and time, so it may look something like this:
site-before-http-to-https-searchreplace-2026-05-13-1045.sql
Saving the backup outside public_html is useful because it keeps the database copy away from the public website folder. In cPanel File Manager, you would normally find it by going to your account’s main home directory, not inside the WordPress media library or the WordPress admin area.
If something goes wrong after the replacement, you can restore that database backup with WP-CLI. First, make sure you are still inside the WordPress installation folder, such as ~/public_html. Then run the import command using the actual backup file name:
wp db import ~/site-before-http-to-https-searchreplace-2026-05-13-1045.sql
This imports the saved database copy back into WordPress. In other words, it rolls the database back to the state it was in before the search-and-replace operation. Replace the example file name with the real .sql file created by your backup command.
Then run the real replacement:
wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefix --report-changed-only
WP-CLI is preferred because it handles serialized WordPress data more safely than a manual SQL replacement. Serialized data is a special format WordPress and plugins often use to store arrays or settings. If you change serialized data incorrectly with a raw SQL query, you can break plugin settings or page builder content.
After the replacement, clear all relevant caches:
- WordPress cache plugin cache
- Server cache
- CDN cache
- Browser cache if needed
Then check the site again. You can reuse the same curl and grep command from earlier to see whether the old HTTP URLs still appear in the final HTML. If something looks wrong after the replacement, remember that you can restore the database backup using wp db import, replacing the example file name with the real .sql backup file created earlier:
wp db import ~/site-before-http-to-https-searchreplace-2026-05-13-1045.sql
6. Mitigate DOM-Based XSS with Trusted Types
Trusted Types is an advanced browser protection against certain DOM-based XSS issues. It controls how sensitive DOM values are passed into functions that can create security risks.
For a standard WordPress site, this is usually not the first fix to make.
The reason is that Trusted Types can interfere with JavaScript patterns used by plugins, themes, builders, forms, tracking tools, and inline scripts. A marketing website built with WordPress may depend on many moving parts that were not designed with Trusted Types enforcement in mind.
That does not mean Trusted Types is unimportant. It means it should be treated as an advanced hardening step, not as a fast correction for every site owner.
Before enforcing Trusted Types, a developer should review how the site uses JavaScript, test the policy in a safe environment, and confirm that critical features still work. For most small business WordPress sites, it is usually more practical to focus first on updates, plugin quality, HTTPS, security headers, backups, least-privilege user access, and careful CSP planning.
7. Detected JavaScript Libraries
This warning is often misunderstood.
When Lighthouse reports detected JavaScript libraries, it is not always saying that something is broken. In many cases, it is simply listing the JavaScript libraries it found on the page.
For example, a WordPress site might load jQuery, a slider script, a form script, a page builder script, a tracking library, or a cookie banner script. Lighthouse may detect and list some of them.
The warning deserves action when a library is:
- Outdated
- Known to have security vulnerabilities
- Loaded on pages where it is not needed
- Duplicated in multiple versions
- Hurting performance
- Added by an unnecessary plugin
- Coming from a source you do not recognize
If none of those conditions apply, this notice may be better understood as a diagnostic note rather than a problem that must be fixed immediately.
A practical WordPress review would include checking whether the theme and plugins are updated, whether unnecessary plugins can be removed, whether scripts are loading sitewide when they are only needed on one page, and whether performance plugins can safely delay or defer non-critical JavaScript.
Be careful, though. Aggressively delaying or deferring scripts can break menus, sliders, forms, tracking, maps, cookie banners, or checkout flows. As with the other fixes in this article, test important user journeys after every change.
A Practical Order of Operations for WordPress
If you are managing a WordPress site, the safest way to handle these warnings is to work in a clear sequence.
Start with a backup. Before changing .htaccess or the database, make sure you have a recent backup of the site files and database. At minimum, download a copy of .htaccess before editing it.
Next, avoid editing inside generated blocks. WordPress, cache plugins, redirect plugins, and security plugins may write their own rules into .htaccess. Keep your custom rules in your own clearly labeled section.
Then move from lower-risk changes to higher-risk changes:
- Add
X-Frame-Optionsfirst if your site does not need to be embedded on external domains. - Verify the header with
curl -I. - Check whether HSTS already exists before adding it manually.
- Roll out HSTS gradually, starting with a short
max-age. - Add COOP if appropriate and test key functionality.
- Use CSP in Report-Only mode first.
- Review browser console warnings before enforcing a strict CSP.
- Search for mixed content with
curlandgrep. - Correct old internal HTTP URLs with WP-CLI if needed.
- Clear cache after each change.
- Re-run PageSpeed Insights after the updates.
This sequence matters because not all warnings have the same risk level. Some header changes are relatively simple. Database replacements and strict security policies require more caution.
The Main Takeaway
Not every PageSpeed Insights warning should be handled the same way.
Some headers, such as X-Frame-Options, Strict-Transport-Security, and Cross-Origin-Opener-Policy, can often be added safely with careful testing. Other improvements, such as a strict Content Security Policy or Trusted Types, need more planning because they can interfere with common WordPress features.
That is why the best approach is not to chase every warning blindly. It is to understand what each notice means, decide whether it is a security fix, a diagnostic note, or a deeper configuration issue, and then apply changes in a way that protects the site without disrupting the tools your business depends on.
For businesses that rely on WordPress to support visibility, credibility, and growth, this kind of careful technical work can make a real difference. A stable site is easier to trust, easier to maintain, and better prepared for long-term digital marketing efforts.
If you need help improving the technical SEO of your WordPress site, Boreas Digital Media can help you review the issues behind your PageSpeed Insights warnings, prioritize the fixes that matter, and apply changes carefully without disrupting the tools your business depends on. From performance improvements and security headers to WordPress configuration and SEO-focused website maintenance, we can help you build a cleaner, more stable foundation for long-term visibility and growth.
