Blog

To speed up a Joomla website in 2026, fix Time To First Byte and images first, then JavaScript. Google ranks field Core Web Vitals (LCP, INP, CLS), not your one-off Lighthouse screenshot. Joomla 5 and 6 already have cache, Gzip, and the Web Asset Manager. Most slow sites are still on PHP 7, uncompressed images, Progressive cache on a logged-in shop, or five minify plugins fighting each other.

The 2023 version of this URL was a long “10 ways” list. That list still works. The destination changed. FID is gone. INP is the interactivity metric. Cassiopeia and modern templates load almost no jQuery unless an old extension drags it in. If you only enable Conservative Caching and call it done, you will not win a PageSpeed argument.

This is the order we use at Infyways on Joomla 4, 5, and 6 (current 6.1.3 / 5.4.8). For a full optimization project, see Joomla website optimization.

What you will learn

• Why lab scores lie and Search Console field data does not
• Conservative vs Progressive vs System Page Cache, without breaking logins
• What actually moved in Joomla 5 and 6: Web Asset Manager, PHP 8.3, less default JS
• The image and INP work most “speed up Joomla” posts still skip

What “fast” means in 2026

Metric	What Google wants (good)	Usual Joomla cause when it fails
LCP	Largest content paints quickly	Hero JPEG, no dimensions, slow TTFB
INP	Clicks respond in about 200 ms or less	Heavy JS, jQuery stacks, chat widgets
CLS	Layout stays still	Images without width/height, late fonts, ads
TTFB	Server answers fast	PHP 7, no cache, distant origin, huge SQL

Use PageSpeed Insights and Search Console together. The top of PSI is field data when Google has enough traffic. Lighthouse below that is a lab story on a simulated phone. A green lab and a red field report means your real visitors are slower than the test. Trust the field numbers for ranking.

Test tools still worth a pass: PageSpeed Insights, GTmetrix, WebPageTest, and your host’s TTFB. They do not replace Search Console.

Step 1: Measure one URL, logged out, on mobile

Pick the homepage and one heavy inner URL (product, article with modules). Test logged out. Logged-in administrator pages will always look worse. Note LCP element (usually the hero image), unused JavaScript, and TTFB. Do not change ten settings at once. You will not know what helped.

Step 2: Put PHP and the host on Joomla 6 footing

Joomla 6 expects modern PHP (8.3 on the official 5 to 6 path). Shared hosting on PHP 7.4 will lose to a cheap VPS on 8.3 with OPcache. HTTP/2 or HTTP/3, SSD, and a region near your users beat another caching plugin.

If you are still on Joomla 3, speed work is a delay tactic. Upgrade path is in Joomla 3 to Joomla 6.

Step 3: Turn on Joomla cache the way the site actually works

Global Configuration, System tab, Cache Settings:

• Conservative Caching: safe default. Modules can still vary. Use this on shops, membership, and anything with a cart or login.
• Progressive Caching: more aggressive. Fine for a brochure site that is identical for every guest. It will show the wrong module to the wrong user if you sell or personalize.
• Cache Handler: File is fine on small sites. Redis or Memcached if the host actually runs them. Do not pick Redis because a blog said so.
• Cache Time: start around 15 minutes. Raise it if content barely changes.

Separately, the System, Page Cache plugin caches full HTML for guests. That is often the biggest Joomla-native win. Exclude cart, checkout, and account pages. Purge cache after template or extension updates.

Module-level cache helps repeating chrome (menus, footers). Do not cache a module that shows the logged-in name.

Step 4: Compress on the server, then confirm in Joomla

Gzip in Global Configuration, Server tab, still matters if the host is not already sending Brotli or Gzip. Many Nginx stacks already compress. Enabling Gzip twice does nothing useful. Confirm in the response headers (content-encoding: gzip or br). Walk through the admin toggle in test and enable Gzip in Joomla. If the host offers Brotli, prefer it at the server and leave Joomla Gzip off to avoid double work.

Also send long cache-control for /media, /templates, and images. Joomla’s Web Asset Manager appends a version query when assets change, so long browser cache is safe if you actually use WAM. See the Web Asset Manager docs.

Step 5: Fix LCP, which is usually an image

Resize the hero to the largest size you display. Serve WebP or AVIF with a fallback. Set width and height so CLS does not jump. Lazy-load below the fold only. Never lazy-load the LCP image.

A 4000px PNG in a 720px column will beat any cache plugin. If you want that conversion inside Joomla, our JoomlaX WebP/AVIF tools exist for that job. CDN the /images tree after the files are small.

Step 6: Cut JavaScript until INP recovers

Joomla 4+ templates should not ship jQuery for decoration. If the page still loads jQuery, an extension asked for it. Unpublish sliders, live chat, and “add to any” buttons you do not use. One chat widget can wreck INP on mobile.

Do not install three CSS/JS minify extensions. They race, break Web Asset Manager order, and duplicate HTTP requests. Pick one approach: a capable template, or one well-supported optimizer, or Cloudflare’s rocket features, not all three.

Defer non-critical JS. Keep first click handlers light. INP is about the worst interaction on the page, not the first paint only.

Step 7: Use a CDN for bytes, not as a substitute for PHP

Cloudflare, Bunny, or Fastly help static files and TTFB for distant users. Purge after deploys. Page rules that cache HTML for logged-in cookies will leak carts. Cache /media and images aggressively. Be careful with HTML at the edge on Joomla sites that set cookies on first view.

Step 8: Clean the CMS so the cache has less to store

• Uninstall unused extensions. Disabled plugins still load in some stacks. Uninstall.
• Keep Joomla on 6.1.3 or 5.4.8. Old 3.x PHP loops are slow and unsafe.
• Limit modules in the header. Every module is queries and HTML.
• Turn off debug and uncompressed scripts on production.
• Database: delete expired sessions, old banner tracks, and leftover #__session bloat if the host shows huge session tables.

What not to do

Habit	Result
Progressive cache on a shop	Wrong prices or a logged-in module on a guest page
Five “speed” plugins	Broken CSS, duplicate jQuery, worse INP
Lazy-loading the logo and hero	Worse LCP
Chasing 100 on Lighthouse desktop	You ignore mobile field data
Gzip plus Brotli plus a minify CDN plus JCH	Unreadable CSS and no way to debug

Related guides and services

• Joomla caching strategy
• Joomla PHP settings
• Joomla .htaccess for compression and caching headers
• Joomla website speed optimization service – if you want it done for you

Key takeaways

1. Speed up Joomla for LCP, INP, and TTFB, not a vanity lab score.
2. Conservative cache plus Page Cache for guests beats Progressive cache on personalized sites.
3. Images and PHP version usually beat another minify extension.
4. Use the Web Asset Manager. Stop injecting raw script tags in the template.
5. One optimizer stack. Then re-measure the same URLs.

Frequently asked questions

How do I speed up a Joomla website in 2026?

Measure field Core Web Vitals, raise PHP, enable Conservative Caching and guest Page Cache if the site allows it, compress responses, shrink the LCP image, and remove extra JavaScript. Then retest the same URLs.

What is the difference between Conservative and Progressive Caching?

Conservative caching is the safe default and respects module variation. Progressive caching stores more aggressively and is for sites that look the same to every guest. Do not use Progressive on carts, membership, or personalized modules.

Does Gzip speed up Joomla?

It reduces HTML, CSS, and JS bytes if the server was sending them raw. If Nginx already sends Brotli or Gzip, turning it on in Joomla will not magically double the gain. Check response headers.

Will a caching plugin replace a slow template?

No. Cache serves the same heavy HTML faster the second time. It does not fix a 2 MB hero or 400 KB of jQuery plugins on first view.

Is Joomla 6 faster than Joomla 3?

A current 6.x site on PHP 8.3 with Web Asset Manager is in a different league than Joomla 3 on PHP 7. The CMS version alone is not a PageSpeed plugin. You still have to size images and modules.

Conclusion

Speed work on Joomla is a sequence: measure, host, cache, compress, images, JavaScript. Skip the sequence and you get a graveyard of speed extensions. If you want that sequence run as a project, use Joomla website optimization and keep the site patched under support.

Updated 15 October 2026 · By Abhilash Sahoo, Founder, Infyways

This is the sequence we use at Infyways when a client’s Joomla site is already serving malware or has been blacklisted. The command output below comes from a deliberately infected Joomla test tree on our own machine, not from any client site. If you’d rather hand this to someone, we offer hacked Joomla site repair. Take a forensic copy of the infected files before you change anything.

Is my Joomla site actually hacked?

Confirm a compromise before you start deleting. These are signs of a real hack:

• Google Search Console → Security issues, or a red “Dangerous site” warning in the browser.
• Your host suspended the account for malware.
• A Super User you didn’t create, or a user with a registration date that doesn’t match your records.
• Redirects that only fire for visitors coming from Google, or only on mobile.
• PHP files in /images, /tmp, /media or a template folder.
• .htaccess rules or pages you didn’t write.

A slow site, a white screen after an update, or a plugin conflict is usually not a hack. Google’s own guidance is to treat the Security issues report as the source of truth, because a Safe Browsing warning may not reproduce in every browser.

What should I do first (contain the damage)?

1. Freeze evidence. Copy the whole site, the database, and 14–30 days of web server access and error logs. Label the copy “infected”. Don’t restore it later as the clean site; you need it to find the entry point and to recover any unique content.
2. Take the site offline without wiping the server. Use Joomla’s offline mode if the admin still works, or a host-level placeholder. Keep logging on. Our Joomla offline mode guide shows how.
3. Change every password: Joomla Super Users, database, FTP/SSH, and the hosting control panel. Attackers often have stolen credentials, so patching files alone won’t lock them out.
4. Scan the computers used to administer the site. Stolen FTP and admin passwords are frequently harvested by malware on a local machine (Joomla’s checklist makes this point).

How do I find the backdoors and injected code?

Work from a shell (SSH) or a local copy of the files. Joomla’s checklist and Google’s hacked-site guide both say to search for suspicious code and recently changed files. These are the commands we actually run; the output here is from our infected test tree.

PHP where it doesn’t belong

A clean Joomla site has no PHP under /images. Webshells love those folders:

# PHP (even disguised) in folders that should only hold assets
find images media tmp templates -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.php*.gif' \)

# obfuscation markers (Google suggests: eval, base64_decode, system)
grep -rIn --include='*.php' -E 'eval\(|base64_decode|gzinflate|str_rot13|\$_(POST|GET|REQUEST)\[' .

Recently changed files

Joomla’s checklist gives this one. It lists files changed in the last day:

find /path/to/site -type f -ctime -1 -exec ls -ls {} \;

Spam and redirects in JavaScript and HTML

Automated scanners are good at base64 in PHP and weak at a one-line redirect inside a JavaScript file. Search by hand:

grep -rIn --include='*.js' -E 'document\.write|<iframe|eval\(|atob\(' .
grep -rIn -E 'HTTP_REFERER|window\.location|<iframe' .

Client case 1: a hidden iframe a security extension missed

On one client site, a popular Joomla security extension reported the site clean, but Google still flagged it. The injection was a single line appended to a minified JavaScript file that the template loaded on every page. It wrote a zero-size, off-screen <iframe> to a malicious host. Scanners that focus on PHP walked right past it.

What found it was a diff against a clean copy of that file:

The lesson: compare every served file against a known-good original, and read JavaScript, not only PHP. A scanner saying “clean” is not proof.

Client case 2: .htaccess injected into every folder

Another client ran an old Joomla 3 site on PHP 7.2. The attacker had dropped an .htaccess file into nearly every folder, each adding a referrer-based redirect, so visitors arriving from Google or Bing were sent to a malicious site while the owner, typing the URL directly, saw nothing wrong.

# list every .htaccess, then flag the ones with redirects
find . -name .htaccess
grep -rIl --include='.htaccess' -E 'HTTP_REFERER|RewriteRule.*https?://' .

Because the site was on an unsupported Joomla and PHP version with injections throughout, cleaning file-by-file wasn’t worth the risk. We kept the database and the images, and rebuilt everything else from scratch on Joomla 6: a fresh install, a fresh template, and extensions reinstalled from clean sources. That’s our standard approach for badly compromised old Joomla 3 sites, and it ties into our Joomla 3 to 6 upgrade guide.

Should I clean the site or rebuild it?

	Clean in place	Rebuild on new Joomla
Best when	Current Joomla, one known entry point, a clean pre-hack backup exists	Old Joomla 3 / PHP 7.x, injections everywhere, no trustworthy backup
Core	Reinstall the same series from a clean zip	Fresh Joomla 6.2 install
What you keep	Cleaned files plus the database	Database and images only, after review
Template & extensions	Reinstalled from clean copies	Rebuilt from scratch
Confidence it’s gone	Good, if you found every backdoor	Highest

Joomla 6 needs PHP 8.3 or newer (we confirmed JOOMLA_MINIMUM_PHP = 8.3.0 in the 6.2.0 package). A rebuild is also a forced move onto a supported stack, which closes the door that let the old site get hacked.

How do I replace the core without breaking the site?

• Match the installed major version first. Reinstall the same series from a clean official package to overwrite tampered files; keep configuration.php and your database. Joomla’s checklist warns that overwriting a Joomla 3 tree with a different major version will break the site.
• Reinstall, don’t just unpublish, extensions. Unpublishing a vulnerable component leaves its PHP on disk, and it still runs if the attacker hits the old URL. Joomla’s documentation is explicit that unpublishing is not enough; uninstall it.
• Check the Vulnerable Extensions List for every component, module and plugin you keep, and update to a patched release. For versions, use our Joomla 6 compatibility check.
• Clean the database and .htaccess. Malware hides in article HTML, module content and server rules, not only in files. Replace the root .htaccess with Joomla’s shipped htaccess.txt (see our Joomla .htaccess guide).
• Lock down upload folders. Joomla’s checklist suggests an .htaccess in /images that disables script execution, plus file permissions of 644 and folders 755, never 777.

How do I remove the Google “this site may be hacked” warning?

1. Fix the issue on every page, not just the samples Google lists. A partial fix won’t restore you.
2. Verify the way Google sees the site. Hackers often cloak content for Googlebot, so use the URL Inspection tool, or curl with a Googlebot user-agent and a Google referrer, rather than only a normal browser.
3. Request a review in Search Console → Security issues. Google says a good request names the exact issue, lists the steps you took, and shows the result.
4. Wait. Reviews take from a few days to a few weeks. Don’t resubmit while one is pending, or you can be marked a repeat offender.

Safe Browsing, Search Console and your host’s blocklist are separate systems. Clearing one doesn’t clear the others, so check each.

Troubleshooting

Symptom	Likely cause	What to do
Cleaned the site, reinfected within hours	A backdoor or entry point was missed	Reinstall core fresh, re-hunt webshells, change all passwords again
Only visitors from Google get redirected	Referrer rule in .htaccess or a cloaking script	Grep every .htaccess for HTTP_REFERER; test with a Googlebot referrer
Security extension says “clean” but Google disagrees	Injection in JS/HTML the scanner skipped	Diff files against clean originals; read JavaScript by hand
Restored a backup and the hack came back	The backup was taken after the compromise	Use an older backup, or clean and rebuild instead
Site white-screens after replacing core	Wrong major version written over the tree	Restore the infected copy, then match the installed series
New Super User keeps reappearing	A webshell or scheduled task recreates it	Find the backdoor and the cron/task; don’t just delete the user
Spam links appear only in page source	Injected into modules or article HTML in the database	Search the database, not only files
Google review rejected	Issue still present on some pages	Fix site-wide, reverify as Googlebot, resubmit once

FAQs

How do I repair a hacked Joomla website?

Contain and back up the evidence, take the site offline, change all passwords, remove the attacker’s files, users and .htaccess rules, replace core and extensions from clean copies, close the entry point, then request a Google review.

Can I just update Joomla to remove the malware?

No. Updating closes one hole but leaves any webshells, rogue users or injected files already on the site. You have to remove the backdoors as well.

Is unpublishing a vulnerable extension enough?

No. The files still execute if the attacker requests the old URL. Joomla’s documentation says to uninstall it, not unpublish it.

Should I restore my latest backup?

Only if it was taken before the hack. A backup made after the compromise restores the malware too. If you can’t be sure, clean or rebuild instead.

When should I rebuild instead of clean?

When the site is on an old, unsupported Joomla and PHP version, the infection is everywhere, or you have no clean backup. Keep the database and images, and rebuild the rest on Joomla 6.2.

Why did my security extension miss the infection?

Many scanners focus on PHP. One of our client cases was a hidden iframe inside a JavaScript file, which the scanner ignored. Diffing against clean files and reading JavaScript found it.

What are the injected .htaccess files for?

Usually redirects. In one client case, an .htaccess in every folder sent visitors arriving from Google or Bing to a malicious site, while the owner saw nothing.

How long does the Google warning take to clear?

After you fix every page and request a review, from a few days to a few weeks. Don’t resubmit while a review is pending.

Will my search rankings come back?

Rankings usually recover once the warning is lifted and the spam is gone, but it isn’t instant, and heavily affected pages can take time to return.

Can Infyways clean or rebuild my site?

Yes. We do incident response, malware removal and rebuilds through our hacked Joomla site repair service, and ongoing protection through Joomla support and maintenance. To prevent a repeat, start with the Joomla security guide.

Joomla turns 21 today, 17 August 2026. Twenty-one years after the Mambo fork on 17 August 2005, it is still a production-ready open-source CMS for multilingual, ACL-heavy, and enterprise-style websites. Market share is smaller than WordPress. The next chapter depends on developer confidence, smoother upgrades, and core strengths that still outpace many competitors.

I have used Joomla since the Mambo days. At Infyways we still ship Joomla extensions used worldwide. Looking only at market share, it is easy to say Joomla lost. Looking at architecture, security, and real project fit, that conclusion is incomplete. Today is a birthday, not a eulogy.

What you will learn

• Why 17 August 2026 is Joomla’s 21st birthday, and how the 2005 fork actually started
• Why Joomla’s decline was mostly confidence and migration friction, not weak technology
• Which core capabilities still make Joomla a strong CMS choice in 2026
• Where Joomla 5.4.x and 6.x stand on the current roadmap
• When to choose Joomla instead of trying to copy WordPress

17 August 2026: Joomla is 21

The date is not marketing copy. The Joomla project and the official 20 Years of Joomla timeline put the start of the story on 17 August 2005: a fork of Mambo so the CMS would stay truly open source. The name Joomla (from the Swahili jumla, “all together”) was announced on 1 September 2005. Joomla 1.0 shipped on 22 September 2005.

That makes today, 17 August 2026, twenty-one years of a volunteer-run CMS with no corporate owner. Last year’s 20th birthday week is documented in the Joomla Community Magazine. Year 21 is quieter, which is fine. The work is in releases, not merch shops.

Date	Milestone
17 August 2005	Mambo fork. The project that became Joomla begins.
1 September 2005	The name Joomla is announced.
22 September 2005	Joomla 1.0 ships.
17 August 2025	Official 20th anniversary.
14 October 2025	Joomla 6.0 and Joomla 5.4 ship together.
17 August 2026	Joomla turns 21.
18 August 2026	Planned Joomla 5.4.8 and 6.1.3 on the project roadmap.
21 to 22 August 2026	Global Pizza, Bugs and Fun contributor event.

Joomla market share vs WordPress in 2026

According to W3Techs, Joomla currently powers about 1.2% of all websites and roughly 1.7% of sites that use a known CMS. WordPress powers over 43% of all websites and nearly 62% of the CMS market.

Signal	Joomla	WordPress
Share of all websites	~1.2%	~43%+
Share of known CMS market	~1.7%	~62%
Core multilingual	Native	Usually plugin-based
Granular ACL	Built into core	Often plugin-dependent
Best-fit use cases	Complex, multilingual, permission-heavy sites	Publishing speed and mass adoption

Bottom line: market share measures popularity. It does not measure whether Joomla is still the better tool for a university portal, government site, membership platform, or multi-language enterprise build.

Joomla never lost because of technology

The most common misconception is that Joomla declined because it could not keep up technically. I disagree. Modern Joomla is one of the strongest releases the project has ever shipped.

• Native multilingual support
• Enterprise-grade Access Control Lists (ACL)
• Custom Fields for structured content entities
• Template overrides for full front-end control
• Web Services / API endpoints for headless and hybrid builds
• Modern PHP architecture, cleaner code, and a strong security posture

Many of these capabilities existed in Joomla before they became table stakes elsewhere. Technology was never the core weakness.

The real challenge was confidence

The harder problem was investment confidence. Major releases modernized the platform, but they also created painful migrations, broken extensions, template rewrites, and changing APIs.

Businesses delayed upgrades. Developers spent months on compatibility instead of new products. Agencies hesitated before recommending Joomla for long-term roadmaps. Some extension authors moved ecosystems or stopped shipping altogether.

That uncertainty, not a lack of features, slowed Joomla’s commercial momentum.

The biggest loss was developers, not just users

A CMS is only as strong as the ecosystem around it: extension developers, template creators, agencies, hosts, educators, and community contributors. When developers stop building, users eventually stop arriving. That developer attrition was Joomla’s deepest challenge over the last decade.

What Joomla still gets right in 2026

Joomla still wins on flexibility, security, scalability, and developer freedom. Unlike platforms that outsource essential capability to plugins, Joomla keeps many advanced features in core.

• Multilingual: still among the best native CMS implementations
• Permissions: ACL depth most competitors still struggle to match cleanly
• Architecture: enough freedom to build complex applications, not only brochure sites
• Trust: a long security track record with businesses, education, and public-sector projects
• Governance: still community-run. No venture owner can flip the license.

As cybersecurity and data ownership become non-negotiable, those strengths matter more, not less. For a practical hardening view, see our Joomla security 2026 guide.

Where Joomla 5.4 and Joomla 6 stand on its 21st birthday

On 14 October 2025, the project released Joomla 6.0 and Joomla 5.4. 5.4 is the bridge. 6.x is the new major line, with automatic core updates and a Backward Compatibility 6 plugin to reduce upgrade risk.

The Joomla roadmap (updated 16 August 2026) is the right snapshot for today:

• Joomla 5.x current: 5.4.7. Bugfix only. Regular bugfix support until 13 October 2026. Security-only until 12 October 2027.
• Joomla 6.x current: 6.1.2. Bugfix support until 17 October 2028. Security-only until 16 October 2029.
• Tomorrow, 18 August 2026: planned 5.4.8 and 6.1.3.
• Joomla 6.2.0 is aimed at 13 October 2026, with Beta 1 listed for 18 August 2026.

This week the community also runs Pizza, Bugs and Fun on 21 to 22 August 2026, a hybrid global event for testing, docs, and patches, including work toward Joomla 6.2. Birthdays are nice. Contributor weekends keep the CMS alive.

Why I still build with Joomla

People ask why I keep investing after two decades. Because the product still solves hard problems well. At Infyways we keep releasing and maintaining Joomla products, and we stay active on the Joomla Extensions Directory. If we did not believe Joomla had a future, we would not keep putting time and capital into that ecosystem.

For teams also optimizing content for AI search answers, pair this CMS strategy with our practical guide to GEO for Joomla.

Joomla does not need to become WordPress

Comparing Joomla only to WordPress misses the point. WordPress won by making publishing extremely simple. Joomla won by giving developers and organizations deep flexibility. That identity should stay.

Instead of chasing raw market share, Joomla should keep improving what already makes it exceptional, while making onboarding, upgrades, and sustainable extension businesses easier.

Key takeaways

1. Joomla is 21 today, 17 August 2026, counting from the 17 August 2005 Mambo fork.
2. Smaller market share does not mean the CMS is obsolete for complex builds.
3. Core multilingual, ACL, Custom Fields, and Web Services remain durable advantages.
4. Joomla 6.1.2 is the current major line. 5.4.x is still supported. 5.4.8 and 6.1.3 are on the calendar for 18 August 2026.
5. Joomla should double down on its identity, not imitate WordPress.

Frequently asked questions

When did Joomla turn 21?

On 17 August 2026. The project began as a Mambo fork on 17 August 2005, was named Joomla on 1 September 2005, and shipped 1.0 on 22 September 2005.

Is Joomla still worth using in 2026?

Yes, when you need native multilingual, deep ACL, structured content, or a flexible architecture for complex sites. It is not always the fastest path for a simple brochure blog, but it remains a strong CMS for demanding projects.

Did Joomla lose to WordPress because of bad technology?

No. Joomla’s harder problem was confidence: migration pain, extension compatibility risk, and uncertain long-term investment signals. The core technology stayed competitive.

What should I run on Joomla’s 21st birthday?

Joomla 6.1.2 on the 6.x line, or 5.4.7 if you are still on 5.x. Watch for 6.1.3 and 5.4.8 around 18 August 2026 on the official roadmap, then plan toward 6.2 later in 2026.

Who should choose Joomla over WordPress?

Teams building multilingual portals, permission-heavy applications, government or education sites, or custom systems that benefit from core ACL and overrides, rather than assembling the same stack from many plugins.

Conclusion

Twenty-one years in, Joomla’s next chapter will not be written by market-share charts alone. It will be written by developers who keep building, businesses that keep investing, and a community that treats security, ownership, and flexibility as first-class product values. I am still building extensions, still contributing on the JED, and still recommending Joomla when it is the right fit, not from nostalgia, but because the platform still has enormous potential.

Happy 21st birthday, Joomla. Here’s to the next 21 years.

Updated 15 October 2026 · By Abhilash Sahoo, Founder, Infyways

Joomla security is the set of updates, account controls, server settings and monitoring that keep a Joomla website from being hacked, and that let you detect and clean an infection quickly if it happens.

To secure a Joomla website, keep Joomla core and every extension on a supported, patched version, turn on Multi-factor Authentication for all administrators, give users only the permissions they need, run a PHP version Joomla supports, block PHP execution in upload folders, and keep tested off-site backups.

Most Joomla sites are not hacked through Joomla core. They are hacked through an outdated extension, a weak administrator password or an unmaintained server. The checklist below covers all three.

In short: Joomla security is a maintenance routine, not a single extension. Patch first, lock down accounts second, harden the server third, and check regularly for signs of compromise.

Question	Short answer
Is Joomla secure?	Yes, when core and extensions are kept up to date
Latest safe Joomla versions	6.2.0, or 5.4.10 on Joomla 5 (both 13 October 2026)
Most common way in	Outdated third-party extensions and stolen admin passwords
Most important single step	Update core and extensions, then turn on MFA
Where malware hides	PHP and JavaScript files, templates, .htaccess, the images folder and the database
Site flagged by Google	Clean everything, then use Request Review in Search Console’s Security issues report
Hacked Joomla 3 site	Usually rebuild on Joomla 6 instead of cleaning file by file

Is Joomla secure?

Yes. Joomla core has a dedicated Joomla Security Strike Team (JSST) that publishes every fixed core vulnerability, with its CVE number and affected versions, in the Joomla Security Announcements, and ships fixes as numbered security releases. It also includes several protections in core that other CMSs often add with plugins:

• Access Control Lists (ACL): fine-grained permissions per user group (view, create, edit, publish, administer).
• A separate administrator application at /administrator, which you can restrict by IP address, VPN or HTTP authentication.
• Multi-factor Authentication in core since Joomla 4.2, including authenticator apps (TOTP), passkeys/WebAuthn, YubiKey and email codes.
• Automated core updates since Joomla 5.4, so a site can install new core releases without manual action.

The weak point is almost always what sits on top of core: third-party extensions, templates, hosting and people. The summer 2026 incidents below are a good example.

How do I secure a Joomla website? (12-step checklist)

Work through these steps in order. Steps 1–4 close the most common ways in.

1. Update Joomla core. Run the latest release of your branch: Joomla 6.2.0 (released 13 October 2026) or, if you are still on Joomla 5, 5.4.10 (13 October 2026, the last bugfix release for 5.x). Go to System > Update > Joomla. Plan your move to Joomla 6 with our Joomla 3 to 6 upgrade guide.
2. Update every extension and template. Go to System > Update > Extensions, click Find Updates, and update editors, page builders and form extensions first. They are the most common entry point.
3. Remove what you do not use. Uninstall (not just disable) unused extensions, old templates and sample data. Code that is not installed cannot be exploited.
4. Turn on Multi-factor Authentication. In Users > Manage, require MFA for every Super User and Administrator. Use an authenticator app or a passkey.
5. Apply least privilege. Keep very few Super Users. Editors and authors should never be in the Super Users group. Review Users > Groups and Global Configuration > Permissions.
6. Use strong, unique credentials. Unique passwords for Joomla admins, the database user, hosting control panel, FTP/SFTP and SSH. Prefer SFTP or SSH keys over plain FTP.
7. Run a supported PHP version. Joomla 6 needs PHP 8.3 or later (8.4 recommended); Joomla 5 needs PHP 8.1 or later. See our Joomla PHP settings guide.
8. Force HTTPS. Install a TLS certificate and set Global Configuration > Server > Force HTTPS to Entire Site.
9. Harden the web server. Rename htaccess.txt to .htaccess, block PHP execution in images, media, tmp and upload folders, and disable directory listing. Our Joomla .htaccess guide has the rules.
10. Protect the administrator area. Restrict /administrator by IP or VPN where your team allows it, or add HTTP authentication in front of it.
11. Turn off error display on live sites. Set Global Configuration > Server > Error Reporting to None (or System Default with display off) so paths and queries are not shown to visitors.
12. Back up and test restores. Keep automated, off-site backups of files and database, and restore one to staging at least once. See how to back up Joomla.

What are the most common Joomla security issues?

Threat	How it usually gets in	Warning signs	Fix
Vulnerable extension (RCE, file upload, SQL injection)	Outdated editor, page builder or form extension with a public endpoint	Unknown PHP files, new admin users, spam pages	Update or remove the extension, then check for a backdoor
Stolen or guessed admin password	Reused passwords, no MFA	Logins at odd hours, changed settings	Reset passwords, enforce MFA, review Super Users
Outdated Joomla core	Skipped security releases	Pre-update check warnings, public CVEs for your version	Update to the latest 6.x or 5.4.x release
Backdoor left after an old hack	Incomplete cleanup	Reinfection after “cleaning”	Full file comparison against clean core and extension packages
Malicious redirects / SEO spam	Injected code in templates, .htaccess or database	Visitors from Google sent to other sites, spam in search results	Clean files and database, request a review in Search Console
Weak hosting setup	Shared accounts, writable core files, old PHP	Other sites on the account also infected	Isolate the site, fix permissions, upgrade PHP

Where does malware hide in a Joomla site?

Attackers hide code where owners and scanners rarely look. Check all of these, not just PHP files:

Location	What to look for
JavaScript files (template, media, extension assets)	Appended code that writes an invisible <iframe> or loads a script from another domain
Template files (index.php, layout overrides in html/)	eval, base64_decode, long encoded strings, links you did not add
images, media, tmp, cache folders	Any .php, .phtml or .shtml file (these folders should hold media only)
.htaccess files	Extra redirects, auto_prepend_file lines, or an .htaccess file in every folder
Database: #__content, #__modules	<script> or <iframe> tags inside articles or Custom modules
Users table	Super Users or Administrators you did not create
Server cron jobs	Scheduled tasks that re-download malware after cleaning
Core files	Files that differ from a clean copy of the same Joomla version

How do I search a Joomla site for malware? (commands)

Run these over SSH from the Joomla root on a copy of the site where possible. A match is a lead, not proof; legitimate extensions sometimes use base64_decode.

# PHP obfuscation commonly used by malware
grep -rlE "eval\(|base64_decode\(|gzinflate\(|str_rot13\(" --include="*.php" .

# Hidden iframes or injected scripts in JavaScript files
grep -rliE "<iframe|document\.write\(|String\.fromCharCode" --include="*.js" .

# PHP files where only media should be
find images media tmp cache -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.shtml" \)

# Files changed in the last 7 days
find . -type f -mtime -7 -not -path "./cache/*" -not -path "./administrator/cache/*"

# Count .htaccess files (a normal site has very few)
find . -name ".htaccess" | wc -l

# Cron jobs for the hosting user
crontab -l

In the database (replace jos_ with your table prefix):

SELECT id, title FROM jos_content WHERE introtext LIKE '%<iframe%' OR `fulltext` LIKE '%<iframe%' OR introtext LIKE '%<script%';
SELECT id, title FROM jos_modules WHERE content LIKE '%<iframe%' OR content LIKE '%<script%';

Also check Users > Manage for unknown Super Users. In the summer 2026 SP Page Builder attacks, JoomShaper reported attacker accounts with @secure.local email addresses.

From our cleanup work: two real cases

Case 1: Google flagged the site, but every scan came back clean

A client’s site was flagged by Google as dangerous. Before contacting us, the client had scanned the PHP files and run one of the most popular Joomla security and firewall extensions. Neither found anything.

We found the cause in a JavaScript file. Code added to it created an invisible iframe that loaded content from another site. Because the file was JavaScript, not PHP, the PHP scan and the extension’s checks did not flag it. After removing the injected code and checking the other .js files, templates and database for similar iframes and scripts, we requested a review in Google Search Console.

Lesson: PHP-only scans and security extensions can miss JavaScript and asset injections. Check .js files, templates and the database for hidden iframes and scripts, then request a review in the Security issues report.

Case 2: An .htaccess file in every folder

A server was hacked and the attacker had created an .htaccess file in every folder. The site was running Joomla 3 on PHP 7.2, both long out of support. Instead of cleaning it file by file, we upgraded it to Joomla 6. We kept only the database content and the images and media, checked them first, and rebuilt everything else from clean sources. We then fixed the remaining issues on the new, supported version.

Lesson: on an outdated, heavily compromised site, a clean rebuild plus upgrade is more reliable than trying to find every infected file. See our Joomla upgrade service and the Joomla 3 to 6 upgrade guide.

What should I do if Google says “This site may be harmful”?

Google shows warning labels in search results, and browsers can show a red warning page, when it detects hacked content, malware or deceptive pages. To remove the warning, follow Google’s process in the Security issues report help page:

1. Open Security issues in Google Search Console and expand each issue to see sample affected URLs. The list is only a sample.
2. Inspect pages safely with the URL Inspection tool or curl, because hacked pages can show different content to Google and to logged-in owners.
3. Clean the issue across the whole site, not just the sample pages, and fix every issue listed.
4. Close the hole that let the attacker in (update, remove the vulnerable extension, rotate passwords).
5. Select Request Review and describe what you found and fixed. Google says reviews can take from a few days to a few weeks.

How do I prevent reinfection?

• Find and fix the entry point before you clean, or the attacker will return.
• Replace core and extension files with fresh copies from official packages instead of editing infected files.
• Remove unknown users and rotate every password: Joomla admins, database, hosting, FTP/SFTP and SSH.
• Delete malicious cron jobs and extra .htaccess files.
• Update everything, then apply the hardening configs below.
• Keep monitoring: file-change alerts, Search Console email alerts and regular backups.

For the full recovery process, follow our guide to repair a hacked Joomla website.

Copy-paste Joomla security configs

Test these on staging first. They assume Apache 2.4 (the Require syntax) and a standard Joomla install.

1. Block PHP execution in upload folders. Save as .htaccess inside images, media and tmp:

<FilesMatch "\.(php|php[0-9]|phtml|phar|shtml)$">
    Require all denied
</FilesMatch>

2. In the root .htaccess: disable directory listing and block direct access to configuration.php:

Options -Indexes

<Files "configuration.php">
    Require all denied
</Files>

3. File permissions: directories 755, files 644, and configuration.php read-only:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 444 configuration.php

Joomla needs to write configuration.php when you save Global Configuration, so set it back to 644 temporarily when you change settings.

4. Security headers. Joomla 4 and later include the System – HTTP Headers plugin, where you can set these without editing server files. Or add them in .htaccess:

<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Strict-Transport-Security "max-age=31536000"
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

Only add Strict-Transport-Security once the whole site works over HTTPS, and test a Content-Security-Policy separately, because a strict one can break editors and page builders.

What are the current Joomla security vulnerabilities? (October 2026)

Safe versions to run now (checked 15 October 2026)

• Joomla core: 6.2.0, or 5.4.10 if you are still on Joomla 5. The most recent core security fixes shipped in 6.1.4 and 5.4.9 (fixed 25 September 2026), including an MFA bypass through “remember me” cookies (CVE-2026-92227), SSRF vectors (CVE-2026-92222) and arbitrary directory deletion via cache purge (CVE-2026-90915). The release before that, 6.1.3 and 5.4.8, blocked SHTML uploads (CVE-2026-73373) and fixed another MFA bypass (CVE-2026-73337). Details are in the Joomla Security Announcements.
• JCE editor: CVE-2026-48907 (CVSS 10.0) let unauthenticated visitors upload and run PHP through editor profiles. It was fixed in 2.9.99.5 with extra hardening in 2.9.99.6. Run the current release: JCE 2.9.99.12, or JCE 3.0.2 on Joomla 5/6 (both released 7 October 2026). Older sites that cannot update can use the vendor’s free security patch.
• SP Page Builder: 6.8.0 (12 August 2026) fixed CVE-2026-67285, an unauthenticated PHP file-inclusion flaw (CVSS 9.2) affecting versions up to 6.7.1, and CVE-2026-65876, an unauthenticated SQL injection. JoomShaper also warns that versions 5.x to 6.6.0 could have been infected through an upload hole. Run 6.8.0 or later, then check for planted admin accounts and backdoor files.

If either extension was outdated on a live site during summer 2026, assume compromise until you have checked, using the malware checks above.

Is Joomla more secure than WordPress?

Joomla gives you more security controls in core: granular ACL, a separate administrator application and built-in MFA. WordPress can reach the same level, but usually with more plugins, and each plugin adds attack surface. WordPress is also attacked far more often, mainly because it runs far more websites, so automated bots target it first.

In practice, the platform matters less than maintenance. A patched WordPress site is safer than an abandoned Joomla site, and the other way round. Joomla’s advantage is that you need fewer third-party extensions to reach a strong baseline.

Do I need a Joomla security extension?

Not to be secure, but one can help. As our first case shows, it can also miss malware. A firewall or security extension can add login protection, file-change detection and blocking rules. It cannot replace updates, MFA, least-privilege accounts, server hardening and backups, and it cannot fix a site that already has a backdoor. Install one as an extra layer after the checklist, not instead of it.

Get help with Joomla security

If your site is already hacked, start with cleanup, then hardening. Infyways handles hacked Joomla site recovery, security hardening and Joomla 5/6 upgrades on a staging copy first, and replies within 12 hours. See our Joomla support and maintenance plans or our Joomla upgrade service.

Frequently asked questions

How do I secure my Joomla website?

Update Joomla core and all extensions, remove unused extensions, enable Multi-factor Authentication for administrators, limit Super Users, run PHP 8.3+ for Joomla 6, force HTTPS, block PHP execution in upload folders, restrict the administrator area and keep tested off-site backups.

Is Joomla secure in 2026?

Yes, when it is maintained. Joomla core has a Security Strike Team and regular security releases. Most hacked Joomla sites were running an outdated extension or core version, not a flaw in current Joomla.

Which Joomla version is the most secure?

The latest release of a supported branch. As of 15 October 2026 that is Joomla 6.2.0, or 5.4.10 for sites still on Joomla 5. Joomla 3 and Joomla 4 no longer receive security updates.

How do I know if my Joomla site is hacked?

Look for unknown administrator accounts, PHP files in image or media folders, changed core files or .htaccess, spam pages in Google, unexpected redirects and security warnings in Google Search Console.

Does Joomla have two-factor authentication?

Yes. Joomla 4.2 and later include Multi-factor Authentication in core, with authenticator apps, passkeys/WebAuthn, YubiKey and email codes.

Do I need a security extension for Joomla?

No, but it can add an extra layer. It does not replace updates, MFA, server hardening and backups.

Is Joomla more secure than WordPress?

Joomla includes more security controls in core, such as granular ACL and a separate administrator application, and it is targeted less often. Both are secure only when core, extensions and hosting are kept up to date.

Why didn’t my security extension detect the malware?

Many scanners focus on PHP files and known signatures. Malware injected into JavaScript files, templates or database content, such as a hidden iframe, can pass those checks. Search .js files, templates and the #__content and #__modules tables as well.

Should I clean a hacked Joomla 3 site or rebuild it?

Usually rebuild. Joomla 3 no longer receives security updates, so cleaning leaves you on vulnerable software. Keep the checked database content and media, rebuild the rest on Joomla 6 from clean sources, and update the extensions.

What should I do first if my Joomla site is hacked?

Take the site offline or restrict access, make a backup for evidence, then clean files and database, remove unknown users, rotate all passwords, update everything and harden the site. Follow our guide to repair a hacked Joomla website.

If you’ve tried integrating MailerLite with Joomla, you already know the problem.

There’s no solid, dedicated module.

Most people end up doing one of these:

• Using embed forms from MailerLite
• Writing custom API code
• Installing outdated or unsupported extensions

None of these feel right.

Embeds look out of place.
Custom code takes time.
And exposing API keys in the browser is risky.

So I built a proper solution.

👉 https://joomlax.com/mailerlite-newsletter.html

A clean, secure, AJAX-based MailerLite newsletter module for Joomla.

The Problem with Existing MailerLite Integrations

Let’s be honest.

Most integrations are not built for real Joomla workflows.

Here’s what usually goes wrong:

• API keys exposed in frontend scripts
• No control over design
• Poor mobile layout
• No proper module positioning
• Hard to maintain across Joomla updates

If you’re running Joomla 4, 5, or planning for 6, this becomes a bigger issue.

You need something native.

Something that works the Joomla way.

---

The Solution: MailerLite Newsletter Module (AJAX-Based)

This module is built specifically for Joomla.

No hacks. No workarounds.

Just install, configure, and publish.

👉 Live Demo: https://demo.joomlax.com/demo/utilities/mailerlite-newsletter
👉 Documentation: https://joomlax.com/documentation/mailerlite-newsletter

---

Why This Module Is Different

1. Your API Key Stays Secure

Most solutions expose your API key in JavaScript.

This one doesn’t.

Everything runs server-side using Joomla’s AJAX system.

• No API key in browser
• No leaks in DevTools
• Clean and secure integration

Your credentials stay where they belong.

On your server.

---

2. Works Like a Native Joomla Module

This is not a plugin hack.

It behaves exactly like a Joomla module:

• Assign to any module position
• Show on selected menu items
• Create multiple instances

Just like you expect.

---

3. Fully Customizable Design

You control everything.

• Heading and intro text
• Button label and icons
• Success and error messages
• Colors, spacing, typography

Horizontal or vertical layout.

It adapts to your design. Not the other way around.

---

4. Built for Modern Joomla (4, 5 & 6)

No legacy code.

No compatibility issues.

This module is designed for current and future Joomla versions.

So you don’t have to worry about migrations later.

---

5. Multilingual Ready

Running a multilingual site?

No problem.

• Create separate modules per language
• Translate content easily
• Use Joomla language files

Works perfectly with standard Joomla workflows.

---

MailerLite Forms vs This Joomla Module

At first glance, you might think:

“MailerLite already gives me a form. Why do I need this?”

Fair question.

Let’s break it down.

MailerLite Embedded Forms

MailerLite’s default forms are:

• JavaScript-based
• Submitted without page reload (AJAX-like)
• Easy to copy and paste

Sounds good.

But here’s where things fall short:

• Runs entirely in the browser
• Limited control over layout inside Joomla
• Styling can clash with your template
• Harder to manage across multiple module positions

It works.

But it doesn’t feel native to Joomla.

---

This Module (Server-Side AJAX Approach)

This module takes a different approach.

• AJAX on the frontend
• Processing handled on the server via Joomla
• API token never exposed
• Full control over design and placement

So you get:

• Better security
• Cleaner integration
• More flexibility

And most importantly…

It behaves like a real Joomla module.

---

Quick Comparison

MailerLite Embed:

• Frontend-driven
• Limited customization
• Not Joomla-native

This Module:

• Server-side secure processing
• Fully customizable
• Built for Joomla workflows

---

The Bottom Line

MailerLite forms are fine for quick setups.

But if you’re building a serious Joomla website…

You need something more controlled.
More secure.
And easier to manage.

That’s exactly what this module delivers.

---

How to Install and Set It Up

This is where things get simple.

Step 1: Download the Module

Go here:
👉 https://joomlax.com/mailerlite-newsletter.html#download

Download the ZIP file.

---

Step 2: Install in Joomla

• Go to System → Install → Extensions
• Upload the ZIP file
• Wait for success message

Done.

---

Step 3: Create the Module

• Go to System → Manage → Site Modules
• Click New
• Select MailerLite Newsletter

Now assign:

• Module position
• Menu items

---

Step 4: Connect MailerLite

You’ll need two things.

API Token:

• Go to MailerLite dashboard
• Navigate to Integrations → Developer API
• Copy your API token

Group ID:

• Go to Subscribers → Groups
• Open your group
• Copy the numeric ID

Paste both into the module settings.

That’s it.

---

Step 5: Customize the Form

Now make it yours.

• Add heading and description
• Set placeholders
• Update button text
• Style colors and layout

Preview it.

Adjust it.

Publish it.

---

What Happens After Setup

Once live:

• Visitors enter name and email
• Form submits via AJAX
• Data is sent securely to MailerLite
• Subscriber is added to your group

No page reload.

No messy redirects.

Just smooth user experience.

---

Who Is This For

This module is perfect if you:

• Use Joomla and MailerLite
• Want a clean newsletter signup
• Care about security
• Don’t want to write custom code
• Build websites for clients

It’s especially useful for agencies standardizing their workflow.

---

Why I Built This

I couldn’t find a proper solution.

Every project needed the same thing.

A simple and secure MailerLite integration for Joomla.

So instead of repeating the same workaround again and again…

I turned it into a reusable module.

---

Try It Yourself

👉 Product Page: https://joomlax.com/mailerlite-newsletter.html
👉 Demo: https://demo.joomlax.com/demo/utilities/mailerlite-newsletter
👉 Documentation: https://joomlax.com/documentation/mailerlite-newsletter
👉 MailerLite Newsletter Joomla Extensions Directory – https://extensions.joomla.org/extension/login-popup-pro/

---

Final Thoughts

MailerLite is powerful.

Joomla is powerful.

But without the right bridge, things get messy.

This module fixes that.

Simple setup.
Secure integration.
Clean design.

That’s how it should have been from the start.

Related Joomla guides

• add a module inside an article
• Joomla module not showing
• free Joomla module generator

Need hands-on help? See our Joomla module development.