Blog

Joomla CSS changes are not showing when the browser never loads the file you edited, or it still loads an old copy. On Joomla 4.1, 5, and 6 the live sheet is media/templates/site/{template}/css/user.css on the active template. A child does not load the parent’s user.css. The Joomla 4.0 path templates/cassiopeia/css/user.css is ignored. Cache, Page Cache, and a CDN can keep the previous sheet after the path is already right.

This is the operator checklist. It is not a design tutorial. Put the file on the template style the public page actually uses, prove the Network tab requests it, then purge every layer in front of PHP. Safe placement (child, not core) is covered in Customize Joomla without editing core. Click-by-click child setup is How to set up a Joomla child template.

The old Joomla 4.0 folder is a dead end. The child media folder is the live sheet. The child does not inherit the parent’s user.css.

What you will learn

• Where Cassiopeia actually loads user.css on Joomla 4.1, 5, and 6
• Why a child looks stock after you already styled the parent
• How to create the file in Template Manager (filename user, no suffix)
• How to prove the sheet is requested (or 404) in the browser Network tab
• Which cache layers still serve yesterday’s CSS after a good save
• When the file loads and the page still looks unchanged (selector weight)

Official references: Cassiopeia Template Customisation, Child Templates (User Manual), Cache.

What you see	Likely cause	Wrong rabbit hole
No change anywhere	File is on the parent, the old 4.0 path, or a template style that is not assigned	Editing template.min.css
Change on Home, not on a landing page	That menu item uses a different template style	“Joomla CSS is broken”
Child site looks stock	You styled Cassiopeia. The child does not load parent user.css	Recreating the child
Network 404 on user.css	File is missing in that template’s media/…/css/ folder, or you named it user.css.css	Clearing cache only
Network 200, still old colours	Joomla cache, Page Cache, browser disk cache, or CDN	Rewriting selectors
File 200, still no visual change	Selector does not match, or a later sheet / inline style wins	Reinstalling Cassiopeia

Step 1: Confirm which template style the page uses

CSS lives on a template, not on “the site.”

1. Open the public URL that should show the change. Note the exact page, not a random inner article.
2. System → Site Template Styles. Note the default (star).
3. Open the menu item for that URL. Template Style may override the default.

If Home uses cassiopeia_brand and the page you tested uses stock Cassiopeia, you can edit the child all day and the landing page will stay stock. Assigning styles is not the same as creating a child. Creating a child does not switch the frontend until a style is assigned.

Club templates (Helix, T4, Gantry, YOOtheme) often have their own “custom CSS” fields. Those are not Cassiopeia user.css. If the site is not Cassiopeia, use that template’s documented custom-CSS slot, still on a child if the vendor supports one. Do not paste into compiled Bootstrap in media/.

Step 2: Put user.css on the media path of that template

On Joomla 4.1 and later (5 and 6 included), Cassiopeia loads:

media/templates/site/{template}/css/user.css

Examples:

• Parent Cassiopeia: media/templates/site/cassiopeia/css/user.css
• Child named cassiopeia_brand: media/templates/site/cassiopeia_brand/css/user.css

The Template Manager css folder is that media folder. It is not templates/cassiopeia/css/ on current Joomla.

The Joomla 4.0-only path templates/cassiopeia/css/user.css was moved into media/ when child templates landed. A file that still sits there will not run. Copy the rules into the media path, then delete or ignore the old copy so you do not edit the ghost next month.

In Template Manager:

1. System → Templates → Site Templates.
2. Open the active template (the child if you use one).
3. New File. Select the css folder.
4. Filename: user with no suffix in the name field. File type: .css.
5. Create, paste rules, Save.

If you type user.css in the name field and also pick .css, you often get user.css.css. The template looks for user.css. The extra suffix 404s. Name the file user only.

Cassiopeia registers user.css with a high asset weight so it loads after the template sheet. Keep !important rare. If a rule still loses, the file is loading and the selector is the problem (Step 7), not the path.

Do not edit template.min.css, vendor/bootstrap, or files under media/templates/site/cassiopeia/ on the parent if you already assigned a child. Parent updates replace those files. The child media folder is the overlay. Setup: Joomla child template.

Step 3: Copy parent rules into the child (they do not inherit)

A child does not load the parent’s user.css.

That is the usual “I created a child and the site went stock” report. You already had rules in Cassiopeia. You created cassiopeia_brand, assigned it, and left the CSS on the parent. The child starts with an empty css folder. Cassiopeia’s file is still on disk. The public style does not read it.

Fix:

1. Open the parent user.css (if it exists).
2. Copy the rules into media/templates/site/{child}/css/user.css.
3. Save. Leave the parent stock going forward so the next Cassiopeia update cannot wipe the live sheet.

Two user.css files on purpose (parent plus child) is not a cascade. Only the assigned template’s file loads. If some menu items still use the parent style, those pages will keep the parent sheet. That can look like “CSS works on Home only.” It is two styles, two files.

Joomla 6 Cassiopeia Extended is already a child. Put user.css on Extended (or on your child of Cassiopeia), not on the parent. Colour and font params on the style write CSS variables such as --headerbg. You can reuse those variables inside user.css. You still need the child’s file for rules the params cannot do.

Step 4: Prove the browser requests user.css

Guessing from “I saved” wastes time. Use the Network tab.

1. Open the public page. Hard refresh once so you are not looking at a frozen inspector session.
2. DevTools → Network → filter CSS.
3. Reload.

You want a request whose URL contains user.css under /media/templates/site/{the-active-template}/css/.

Read the status:

• 404: the file is not in that folder, or the name is wrong (user.css.css, custom.css, user.min.css). Create it again with filename user.
• 200, tiny file, your rules missing: you are viewing a different template’s sheet, or you edited FTP on the parent while the site uses the child.
• 200, body has your rules, page still old: cache or CDN (Step 5), or selector weight (Step 7).
• No user.css request at all: the active template is not Cassiopeia (club template custom-CSS field), or the template’s asset map never registered template.user. Club docs win. Do not invent a Cassiopeia path on Helix.

View Source and search user.css. If the <link> href points at /media/templates/site/cassiopeia/css/user.css while you edited cassiopeia_brand, the assigned style is still the parent.

Step 5: Purge Joomla cache, Page Cache, browser, and CDN

A correct user.css can still look unchanged because something in front of the file is serving bytes from earlier.

Order:

1. System → Maintenance → Clear Cache → Delete All. If Cache Handler is Redis or Memcached, emptying cache/ in FTP does nothing. Handler and permissions: Joomla cache not clearing.
2. If System – Page Cache is enabled, guests get a full HTML snapshot that still points at a hashed or cached CSS URL. Clear cache again, then test logged out. Guest vs login layers: Joomla cache showing old content.
3. Hard refresh the browser (or a private window). “Use Browser Caching” on the Page Cache plugin will not be fixed by Joomla Clear Cache.
4. Purge the CDN (Cloudflare, host “Optimize,” a LiteSpeed cache plugin). Origin can already show the new sheet while the orange-cloud hostname does not.

Conservative Joomla cache does not usually compile user.css into one blob, but page-level HTML can keep an old <link> with a stale query string. Progressive cache can keep an old module wrapper class you were targeting. Clear, then retest as a guest.

If you use a CSS extension or a page builder “compile” button, that is a fifth store. Joomla Clear Cache does not empty a builder’s CSS cache. Purge that UI too.

Step 6: Confirm you did not hide the change with CSS

If Network shows 200 and the response body contains your property, Joomla loaded the file. The cascade lost.

Check:

• The class or id you targeted exists on this template. Cassiopeia class names are not Protostar. .container-header is not .header. Inspect the live node.
• A later rule wins: template params (Joomla 6 colour settings), a custom module with inline style, or a page-builder CSS file loaded after user.css.
• You set display: none on a parent while testing and forgot. The “change” is that the block is gone, not that colour failed.
• You edited a print or RTL sheet. Cassiopeia has direction-specific presets. Test the same language and direction as the public page.

Specificity beats “I used user.css.” Raise the selector to match the live markup. Do not edit core Bootstrap to “make it stick.”

Need a layout change rather than a colour? That is an html/ override, not more CSS. Decision tree: customize without editing core. Visual work you do not want to own: Joomla design services.

Path first. Then child vs parent. Then cache. Then CDN and the browser. Then selector weight. Do not skip to !important.

Key takeaways

1. On Joomla 4.1, 5, and 6, Cassiopeia user.css is media/templates/site/{template}/css/user.css on the active template.
2. A child does not load the parent’s user.css. Copy the rules into the child’s media folder when you switch styles.
3. The Joomla 4.0 path templates/cassiopeia/css/user.css is a dead file. The Template Manager css folder is media.
4. New File: name user with no suffix, type .css. user.css.css 404s.
5. Prove the Network tab requests the sheet under the assigned template name. 404 is a path problem. 200 with old colours is cache or CDN.
6. Clear Joomla cache, watch Page Cache for guests, hard-refresh the browser, purge the CDN.
7. If the file body already has your CSS, fix the selector. Do not reinstall the template.
8. Keep the file on a child template so the next Cassiopeia update cannot wipe the live sheet.

Frequently asked questions

Why are my Joomla CSS changes not showing?

The public page is not loading the user.css you edited. The file is on the parent, on the old templates/…/css/ path, or on a template style that is not assigned. Or cache and CDN still serve the previous sheet. Confirm the Network URL, then purge.

Where is Cassiopeia user.css on Joomla 5 and 6?

media/templates/site/{template}/css/user.css. For a child, replace {template} with the child element name such as cassiopeia_brand. Official overview: Cassiopeia Template Customisation.

Does a Joomla child template inherit the parent user.css?

No. Cassiopeia loads user.css only from the template that is assigned. Copy parent rules into the child file when you create the child. User manual: Child Templates.

Why did the Template Manager create user.css.css?

The name field already had user.css and the type was .css. Joomla concatenated them. Create the file again as user plus type .css.

I cleared cache and the old CSS is still there. What next?

Clear Cache only empties Joomla’s handler. Guests may still hit System – Page Cache, the browser disk cache, or Cloudflare. Test a private window against origin, then purge the CDN. See cache not clearing if Delete All does nothing.

Can I edit template.min.css instead of user.css?

No. Updates replace compiled template CSS. user.css on the active (child) template is the supported overlay. Same rule as other custom files: customize without editing core.

My CSS file loads but a module still looks stock. Is that CSS?

Maybe. Confirm the module actually rendered. Unpublished, Access, and dates are a different diagnosis: Joomla module not showing. If the HTML is present and unstyled, you are still on this article.

Conclusion

When Joomla CSS changes are not showing, believe the Network tab before you believe the Template Manager save message. The live sheet is user.css under media/templates/site/ for the assigned template. Children do not borrow the parent file. The old templates/cassiopeia/css/ location is Joomla 4.0 history. After the path is right, purge Joomla cache, Page Cache, the browser, and the CDN. If the response already contains your rules, inspect the node and fix the selector. If the change you wanted was behaviour, not colour, that is user.js: Add custom JavaScript to Joomla and Joomla JavaScript not working.

If the site is a mix of club CSS fields, a CDN, and a half-assigned child, Joomla support and maintenance is faster than guessing folders on production.

Joomla 6 is the current major CMS line. Stable production today is Joomla 6.1.3. Joomla 6.2 is the next minor release: it is in feature freeze (Beta 2 as of 1 September 2026) with general availability planned for about 13 October 2026. Site owners still on Joomla 5.4 should note that Joomla’s bugfix window for 5.4 ends on that same October date. This guide covers what 6.x changed from 5.x, what 6.2 adds, and how to upgrade safely.

The old “Joomla 6 is coming” story is finished. Joomla 6.0 shipped. The 6.1.x line is receiving security and bugfix releases (6.1.3 announcement). Attention now moves to Joomla 6.2, which the project is testing in public betas (Beta 1, Beta 2). Betas are not for production.

If you need a managed path from 3.x, 4.x, or 5.x onto 6.x (or a staging dry-run before 6.2), use Infyways Joomla Upgrade services.

What you will learn

• Where Joomla 6.x stands in September 2026 (stable vs beta)
• What Joomla 6.2 is shipping (editors, multilingual, updates, APIs)
• The official 6.2 milestone calendar through GA
• How 6.x differs from 5.x and 4.x
• A practical upgrade checklist for site owners and developers
• When to call in Joomla upgrade or support help

Official schedule source: Joomla Project Roadmap.

Joomla 6.2 status: coming soon, already testable

Milestone	Planned date (roadmap)	Status
Alpha 1 to 3	May to July 2026	Done
Beta 1 (feature freeze)	18 August 2026	Done
Beta 2	1 September 2026	Current public beta
Beta 3	15 September 2026	Upcoming
RC1 (language freeze)	29 September 2026	Upcoming
6.2.0 stable (GA)	~13 October 2026	Planned
6.2.1+	Nov 2026 onward	Maintenance

Dates can slip. Treat them as planning targets, not contracts. Release managers for 6.2: Viviana Menzel and Martin Kopp (roadmap).

Production rule: run Joomla 6.1.3 (or the newest 6.1.x) on live sites. Install 6.2 Beta only on staging or throwaway test sites (launch.joomla.org is fine for experiments).

Calendar pressure for Joomla 5.4: official messaging around the 6.1.3 / 5.4.8 release notes that 5.4 bugfix support ends 13 October 2026, with security support continuing longer. That lands on the same week as planned 6.2 GA. If you are still on 5.4, plan the move to 6.x before bugfix ends, even if you wait for 6.2.0 stable rather than jumping into beta.

What is new in Joomla 6.2

Feature freeze started at Beta 1. No major new features after that. Below is what the project committed for 6.2, based on the Beta 1 feature notes and follow-up Beta 2 work. Always re-check the 6.1 to 6.2 migration guide and release notes before you upgrade.

Editors and content UX

Change	Why it matters
Native TinyMCE Readmore button	Replaces legacy readmore handling with a real TinyMCE plugin
Link selector modal	Unified link picker for article, contact, and menu editor buttons
TinyMCE uses Joomla text filter by default	Editor HTML follows core filter rules, not a separate TinyMCE whitelist
TinyMCE 8.8.x	Editor package bump for stability and security
Category / list sub-category images	Optional display of child category images in content (and related category list layouts)

Multilingual

Change	Why it matters
Language fallback chain	Missing language strings can fall through a configurable chain (example: regional → country → base), with overrides in Language options

Useful for agencies running many language packs where incomplete translations left English gaps or blank labels.

Updates, security visibility, media

Change	Why it matters
Security flag on updates	Installer UI and quickicons can mark security releases clearly
Highest-severity update preference	Updater prefers the update with the highest severity when multiple match
Clearer SVG upload error messages	Media Manager reports specific SVG validation failures instead of a generic XSS warning
Better installer error reporting	Failed web installs surface more precise diagnostics

APIs and developer tools

Change	Why it matters
EnumField form field	Build list options from PHP enums
Web Services: separate introtext / fulltext	JSON:API content endpoints expose both fields; combined text is deprecated (removal planned for Joomla 8.0)
Generic XOAuth2 support (Beta 2 line)	Broader OAuth2 plumbing for integrations (verify against final release notes)

Note on article preview tokens: Beta 1 announced signed preview tokens for unpublished articles without a frontend login. That work was reverted in Beta 2 for further work. Do not plan production workflows around it until it returns in a later release note.

Also in the 6.2 alpha/beta window: media/image manager improvements inside TinyMCE, accessibility tweaks (for example aria-disabled on toolbar buttons that need a selection), admin menu support-link polish, and assorted stability fixes aimed at larger sites.

What Joomla 6.x already changed vs 5.x and 4.x

Joomla 6.0 was the architectural jump. 6.1 and 6.2 are incremental on that base.

Area	Joomla 4.x	Joomla 5.x	Joomla 6.x
Focus	Bootstrap 5 admin, accessibility	Modern PHP, compatibility plugin era	Framework cleanup, new packages, stricter future path
PHP	7.2+ era evolving to 8.x	PHP 8+ focus	Modern PHP required (plan 8.1+ / 8.2+ on hosting)
Extensions	Many older extensions still ran	Compat plugin smoothed upgrades	Test every extension; compat is a bridge, not a forever plan
APIs	Mixed legacy	Deprecations increasing	Renderer, Console, Preload, DB/HTTP modernization
Support clock	Ended	5.4 bugfix ends ~13 Oct 2026	Active 6.1.x today; 6.2 GA planned same week

Core 6.0 themes that still matter for upgrades: stronger database patterns, HTTP / cryptography modernization, console tooling, preload helpers, and the compatibility plugin for migration. Details live in Joomla 6 migration docs and the roadmap.

Why you should prepare now

1. Support calendar. 5.4 bug fixes stop when 6.2 is due. Security patches continue longer, but feature and bug debt stacks up if you stay behind.
2. Extension vendors. Good vendors already ship Joomla 6 builds. Waiting until the week of GA means competing with every other late upgrader for support tickets.
3. 6.2 editor and language changes. TinyMCE filter defaults and language fallback can change what editors see. Staging catches that before clients do.
4. Headless / Web Services. If you use Joomla as an API, the intro/fulltext split needs client updates before the combined field disappears in a future major.

Need hands-on help: Joomla Upgrade, ongoing Joomla support and maintenance, or hire Joomla developers. For K2 sites stuck on old stacks, pair the CMS upgrade with K2 migration services.

Step 1: Inventory and hosting check

1. Export installed extensions, templates, custom overrides, and PHP version.
2. Confirm hosting meets Joomla 6 PHP requirements (modern 8.x). Upgrade hosting before the CMS if needed.
3. Mark every extension as: J6-ready, needs compat plugin, or replace.
4. Filter the Joomla Extensions Directory by Joomla 6 where vendors list readiness.

Step 2: Stage, never upgrade live first

1. Full backup (files + database).
2. Clone to staging with the same PHP version you will use in production.
3. On staging, update to the newest stable 6.1.x first if you are coming from 5.x.
4. Only then test 6.2 Beta on a separate staging copy if you want early validation. Beta is for discovery and extension testing, not go-live.

Official beta packages: Beta 2 announcement. Report issues at issues.joomla.org.

Step 3: Compatibility plugin, then remove the crutches

1. Enable the Joomla compatibility / BC plugin only while you patch or replace broken extensions.
2. Retest logins, checkout, forms, multilingual switching, and search.
3. Fix or replace templates that assume removed APIs.
4. Plan to turn the compat plugin off once everything is native-ready. It is a bridge.

Migration notes: 6.1 to 6.2 migration guide (update as the manual grows through RC).

Step 4: QA before production cutover

1. Frontend: home, menus, articles, category blogs, media, forms.
2. Admin: article edit (TinyMCE readmore/links), installer update view, language strings.
3. SEO: SEF URLs, redirects, sitemaps, canonical tags.
4. Performance: cache, CDN, image formats (WebP converter for Joomla).
5. Security: apply the latest 6.1.x / 5.4.x patches on whatever you run today; do not wait for 6.2 to install current security releases.

When staging is green, schedule production during low traffic, restore plan in hand. Infyways can run that cutover under Joomla Upgrade or white-label via outsource Joomla services.

Developer action plan for 6.2

1. Test extensions against 6.2 Beta / nightly builds before GA.
2. Stop depending on deprecated Web Services text for articles; use introtext and fulltext.
3. Adopt EnumField where enums already model your options.
4. Re-test TinyMCE integrations after the text-filter default change.
5. Watch language packs for fallback-chain behavior on incomplete translations.
6. Read B/C notes for 6.2 and file bugs early while betas are open.

Agencies maintaining many client sites: outsource Joomla services and Joomla extension development.

Key takeaways

1. Stable today: Joomla 6.1.3 (keep patched). Coming: Joomla 6.2 GA around 13 October 2026.
2. 6.2 is in feature freeze. Beta 2 (1 Sep 2026) is for testing only.
3. Headline 6.2 themes: better TinyMCE workflows, language fallback chains, clearer security updates, Web Services field split.
4. 5.4 bugfix ends around the same date as 6.2 GA. Plan the move to 6.x now.
5. Upgrade on staging first. Use Infyways Joomla Upgrade if you want a managed migration.

Frequently asked questions

When is Joomla 6.2 released?

The project roadmap targets about 13 October 2026 for 6.2.0 stable, after Beta 3 and an RC. Confirm on the roadmap as dates can move.

Should I install Joomla 6.2 Beta on my live site?

No. Betas are for testing. Production sites should stay on the latest stable 6.1.x until 6.2.0 ships and your extensions are verified.

What is the current stable Joomla 6 version?

As of late August 2026, Joomla 6.1.3 is the published stable download on downloads.joomla.org. Always check that page for newer 6.1.x patches.

How is Joomla 6.2 different from Joomla 6.0?

6.0 was the major platform jump. 6.2 is a minor release focused on editor UX, multilingual fallbacks, update severity visibility, API field clarity, and stability. It builds on 6.0/6.1 rather than replacing the architecture again.

Will my Joomla 5 extensions work on Joomla 6?

Some will, some need the compatibility plugin, some need vendor updates. Inventory and test on staging. Replace abandonware before you cut over.

Does Joomla 5.4 still get updates?

Bug fixes for 5.4 are scheduled to end around 13 October 2026. Security support continues longer per the project’s 5.4 / 6.1 release notes. Do not confuse “still gets security” with “good place to stay forever.”

How do I upgrade to Joomla 6 safely?

Backup, clone to staging, update hosting/PHP, update or replace extensions, test, then schedule production. Infyways documents and runs this under Joomla Upgrade services.

Where do I get help if the upgrade breaks?

Start with staging logs and vendor docs. For a full recovery or multi-site rollout, use Joomla support and maintenance or hire Joomla developers.

A WebP converter for Joomla turns JPG, PNG, and GIF files into smaller WebP (and optionally AVIF) copies so browsers download less data while visitors still see the same picture. That matters for Google ranking because Google uses page experience and Core Web Vitals as ranking signals. On image-heavy Joomla sites, a slow hero JPEG often is the Largest Contentful Paint (LCP) element. Cutting image weight by up to 80% is one of the fastest ways to improve what Google measures and what users feel.

Joomla does not convert formats when you upload a photo. Templates and page builders keep printing whatever you stored. Over years you get a folder of large JPEGs and PNGs. Google PageSpeed Insights and Lighthouse then flag Serve images in next-gen formats. This article starts with why next-gen conversion is a must for websites that want to rank in Google, then covers how to do it on Joomla 4, 5, and 6.

Same visual, smaller file. Google’s crawlers and real users both benefit when LCP images load faster.

What you will learn

• How Google uses speed and Core Web Vitals in ranking
• Why heavy images are a must-fix for almost every website
• Why Joomla sites fall behind on Google PageSpeed image audits
• How WebP and AVIF help you pass Google’s next-gen format checks
• Practical ways to convert (manual, CDN, plugin) and which fits
• Step-by-step conversion on Joomla 4, 5, and 6, then how to verify in Google tools

Related speed work: Joomla website optimization and Joomla on-page optimization.

How Google ranking is affected by slow images

Google Search does not rank on keywords alone. Google also evaluates how usable the page feels. Official Google Search documentation describes page experience and Core Web Vitals as part of that picture. Core Web Vitals currently center on:

Metric	What Google measures	Why images matter
LCP (Largest Contentful Paint)	How fast the main content appears	Often a hero image or intro photo on Joomla templates
INP (Interaction to Next Paint)	How responsive the page feels	Heavy pages compete for main-thread time while large images load
CLS (Cumulative Layout Shift)	Visual stability	Late-loading images without size hints can shove content around

Google’s guidance for a “good” LCP is roughly 2.5 seconds or under for most users in the field data Google collects. When the largest paint is a 400 KB JPEG on a mid-range phone, that budget burns before PHP or MySQL even enter the story. Content quality still matters most, but when two pages are similar, Google can prefer the faster, better-experiencing URL. That is how image format work impacts ranking: it protects LCP and page experience so you are not the slower option in a competitive SERP.

You see the same problem in tools Google provides:

• PageSpeed Insights (lab + field / CrUX data)
• Search Console → Experience / Core Web Vitals reports
• Lighthouse audits: Serve images in next-gen formats, Efficiently encode images, Properly size images

Ignoring those Google reports does not freeze your rankings overnight. It does leave ranking headroom on the table, especially on mobile Google results where bandwidth and CPU are weaker.

Why next-gen image conversion is a must for websites

Every public website that wants organic traffic from Google has the same constraint: users and Googlebot both wait on bytes. Images are often the largest bytes on the page. Leaving them as unconverted JPG and PNG is optional only if you do not care about:

1. Google ranking and visibility. Weak Core Web Vitals and poor page experience make it harder to win when competitors already ship WebP or AVIF.
2. Mobile Google users. Most searches happen on phones. A desktop-optimized JPEG that looks fine in the office fails in the field data Google uses.
3. Bounce and conversion. Slow LCP means people leave before they read. Fewer engaged visits can reinforce weaker performance in Google Analytics and Search Console over time.
4. Crawl and index efficiency. Bloated pages waste crawl budget and delay rendering. Leaner HTML and lighter assets help Google fetch and understand the page faster.
5. Cost. Hosts and CDNs charge for bandwidth. Serving 80% less image data is free money after the conversion path exists.

WebP and AVIF are not trends. They are smaller encodings of the same pixels. At similar visual quality, WebP is typically much smaller than JPEG or PNG. AVIF can be smaller still when the host and browser support it. For any website that lives on Google traffic, converting to next-gen formats is a must, not a polish task after “real SEO.”

On Joomla, the must is stronger: the CMS will happily keep uploading camera JPEGs forever unless something converts them automatically.

Why Google PageSpeed hits Joomla sites especially hard

Joomla stores media under images/ and reuses those paths everywhere: articles, modules, custom fields, templates, and third-party components. Unlike a one-page static site, you cannot casually rename every file without breaking references. Google still evaluates the rendered page. If the live HTML points at a 400 KB JPEG, Google PageSpeed counts that JPEG.

Typical Joomla image debt looks like this:

• Hero and intro images uploaded as high-quality JPEG from a phone or camera
• PNG screenshots and UI graphics that were never compressed
• Gallery and news folders with thousands of files from years of publishing
• Template CSS that still points at .jpg or .png backgrounds
• Structured data and Open Graph tags that still list the old JPEG URL

Manual fix: download, convert on a desktop, re-upload, update every article and module. On a 500-article site that is a migration project, not a maintenance task. New uploads start the problem again unless conversion is automatic.

So the need is not only "use WebP once." It is continuous: keep originals for the editor and backup, serve modern formats on the front end, and handle new uploads without a weekly batch job on someone’s laptop.

WebP vs AVIF: what each format is for

Format	Typical size vs JPEG	Browser support	Role on a Joomla site
WebP	Often 25 to 35% smaller at similar quality (sometimes more)	All modern browsers	Safe default for almost every Joomla 4+ site
AVIF	Can be ~50% smaller than WebP at similar quality	Strong in Chrome, Firefox, Opera; Safari support has expanded	Use when PHP and hosting can create AVIF
Original JPG/PNG	Largest	Universal	Keep as fallback for older clients

You do not need AVIF on day one. WebP alone clears most of Google PageSpeed’s Serve images in next-gen formats warning for modern traffic. AVIF is the second step when hosting supports it (usually PHP 8.1+ with GD imageavif() or ImageMagick AVIF).

Ideal delivery uses a <picture> chain: AVIF first (if present), then WebP, then the original. The browser picks the first format it understands. Google’s crawlers that support modern formats get the lean file. Older clients still get a working image. You should not hand-write that markup in every Joomla article.

How conversion can be done (pick a method)

Method	When it works	When it fails
Desktop tools + re-upload	Few images, one-time redesign	Large archives, ongoing editors, broken paths
Free online converters	One-off assets	Privacy, no Joomla integration, no automation
CDN / edge image polish	Host already offers format negotiation	Less control per folder; admin and exclusions harder
Joomla system plugin	Ongoing sites, many folders, exclusions	Needs PHP GD (and AVIF libs if you want AVIF)

A solid WebP converter for Joomla should do at least this:

1. Keep originals so Media Manager and backups stay intact
2. Convert on page load and/or in bulk before traffic spikes
3. Support WebP, and AVIF when the server can
4. Serve fallbacks so old browsers still see an image
5. Let you exclude logos, animated GIFs, checkout pages
6. Run on shared hosting without SSH

Those requirements define the "how," not a brand pitch. One product that matches them on Joomla 4, 5, and 6 is WebP Converter by JoomlaX (Infyways). The rest of this guide uses that plugin as the concrete how-to, with official documentation for settings detail.

How it works once a converter is installed

Two workflows cover most sites:

On-the-fly. A visitor opens a page. The plugin finds image tags (and can handle CSS backgrounds and optional global URL rewrite). If a WebP or AVIF copy exists, the HTML points there. If not, it can create the copy during that request (with memory limits), then reuse it later. Good for new uploads and steady traffic.

Batch Generate Images. In the administrator, open the plugin’s Image Management tab, tick folders under images/, choose WebP Only, AVIF Only, or Both, and run Generate. Use this before launch, after a migration, or for a large stories archive.

Default layout: images/stories/photo.jpg gains a copy under images/webp/stories/photo.webp (and AVIF when enabled). Originals are never deleted. Deleting converted files only removes the modern copies.

Lazy conversion for ongoing traffic, or pre-warm folders when you control the launch date.

Step 1: Check hosting before you convert

Goal	What you need
WebP	PHP with GD WebP support (common on Joomla hosts)
AVIF	PHP 8.1+ with GD imageavif() or ImageMagick AVIF
Disk	Space for parallel copies (originals stay)
Joomla	4.x, 5.x, or 6.x

If AVIF is missing, start with WebP Only. That still solves most of the necessity case above.

Step 2: Install the converter plugin

From the install guide:

1. Buy or download from joomlax.com/webp-converter.html.
2. Unzip the outer WebPConverter_UNZIP.zip on your computer.
3. Install only the inner plg_system_webpconverter_….zip via System → Install → Extensions → Upload Package File. Do not upload the wrapper zip.
4. System → Maintenance → Clear Cache.
5. System → Plugins → search WebP Converter → enable System – WebP Converter.

Step 3: First-time settings that matter

Open the plugin → General Settings:

1. Image Format: WebP Only (add Both later if AVIF works)
2. WebP Quality: about 70 to 80 (100 is rarely worth the size)
3. Use Lightweight Processing: Yes on shared hosting
4. Debug Mode: No on production
5. Save, open the public homepage, hard-refresh

Proof: view source and search for .webp, or open an image in a new tab and check the extension.

Optional next: Exclusion Settings for GIF animations, no-webp class on logos, menu items like checkout, or folders such as headers. Details: Exclusion Settings.

Step 4: Convert a folder in bulk (recommended first test)

1. Plugin → Image Management
2. Tick one small folder (not Root on the first try)
3. Choose WebP Only
4. Click Generate Images and wait for completion
5. Clear Joomla cache and purge the CDN if you use one
6. Re-run PageSpeed Insights on a page that uses those images

If Generate does nothing, tick a folder and use Load more folders when the list is long. Stay logged in as an administrator.

Step 5: Features you turn on only when needed

You do not need every switch on day one. After basics work, these solve real gaps:

Need	Setting or capability
PageSpeed still shows JPG in meta or schema	Replace Image URLs Globally
Long pages	Native lazy loading (keep above-the-fold eager if offered)
Huge news archives	Flat output directory and/or hashed filenames
Checkout or shop quirks	Disable for menu items / components / URL patterns
Maximum compression	Image Format → Both (AVIF + WebP + original)
Shared hosting RAM pressure	Memory threshold and lightweight mode

Security extras (CSRF on AJAX, rate limits, logging) matter more on multi-admin sites than on a single-editor brochure site. Full feature list: product page.

After conversion: prove it helped in Google’s tools

1. Hard-refresh a key page. Confirm .webp (or AVIF) in Network or view-source.
2. Compare file sizes of hero images before and after.
3. Re-test mobile in Google PageSpeed Insights. Watch LCP and the next-gen image opportunities.
4. Check Google Search Console Core Web Vitals / Experience reports over the following weeks (field data updates slowly).
5. Purge CDN so Googlebot and users are not still hitting old JPEG URLs at the edge.
6. Spot-check Open Graph previews if you enabled global URL replace.

If images look wrong, lower quality slightly or exclude that asset. Originals are still on disk.

Plans if you use WebP Converter

From the official store, all with a 30-day money-back guarantee:

Plan	Price	Sites	Access
Tester	$19	1	30 days (testing)
6 Months	$29	2	Priority support
1 Year (recommended)	$49	3	VIP support channel
Lifetime	$99	Unlimited	Dedicated support

Pick Tester for a staging proof. Pick 1 Year or Lifetime if you maintain client sites. Docs: WebP Converter documentation. Support: support.joomlax.com.

AVIF-focused companion: Joomla AVIF converter and WebP optimizer.

Key takeaways

1. Google uses page experience and Core Web Vitals in ranking. Slow LCP images put you behind faster competitors.
2. Next-gen conversion is a must for websites that depend on Google: smaller files, better mobile UX, clearer PageSpeed reports.
3. Joomla keeps uploading JPG/PNG forever unless something converts them continuously.
4. Start with WebP. Add AVIF when hosting supports it.
5. Manual conversion does not scale. A system plugin fits ongoing editorial sites.
6. Verify in Google PageSpeed Insights and Search Console after you clear cache and CDN.

Agency help with speed and SEO: Joomla SEO services.

Frequently asked questions

Does WebP conversion help Google ranking?

Yes, indirectly but materially. Google uses Core Web Vitals and page experience as ranking signals. Faster LCP from smaller images helps you compete when content quality is similar. It will not replace good content, but it removes a common technical drag on Google visibility.

Why is a WebP converter a must for websites?

Because Google and users both punish slow pages. Images are often the heaviest assets. Without WebP or AVIF, mobile Google traffic pays the full JPEG cost, PageSpeed stays red on next-gen format audits, and ranking headroom goes to sites that already converted.

Why do I need a WebP converter for Joomla?

Because Joomla serves uploaded JPG and PNG as-is. Converting to WebP or AVIF cuts file size, improves LCP for Google, and clears common PageSpeed image warnings without redesigning the site.

Is WebP enough, or do I need AVIF?

WebP is enough for most sites. Use Both when the server can create AVIF and you want maximum compression with automatic fallbacks.

Will conversion delete my originals?

No, when you use a proper Joomla converter that writes parallel files. Originals stay under images/.

Can I convert without a plugin?

Yes, manually or at the CDN. Plugins win when editors keep uploading and you need folder exclusions and HTML replacement inside Joomla.

How do I know conversion worked?

View source for .webp or .avif, check Network sizes, and re-run PageSpeed after clearing cache and CDN.

Does this work on Joomla 5 and 6?

Yes for current WebP Converter builds aimed at Joomla 4, 5, and 6. Confirm your package version on the product page.

What if PageSpeed still shows old JPG URLs?

Enable global image URL replacement if your plugin offers it, regenerate, and purge CDN. Meta tags and schema often keep old paths until that pass runs.

Can I skip logos and animated GIFs?

Yes. Exclude formats, folders, filenames, or add a class such as no-webp on specific images.

What PHP do I need for AVIF?

PHP 8.1+ with GD imageavif() or ImageMagick with AVIF. Otherwise stay on WebP Only.

Where do I get setup help?

WebP Converter documentation and JoomlaX support. JoomlaX is Infyways’ extension store.

Joomla Redirect Guide: 301, com_redirect, .htaccess, and nginx

A Joomla redirect sends visitors and crawlers from an old URL to a new one with an HTTP status code (usually 301). Joomla gives you three practical layers: server rules (.htaccess, nginx, or IIS) that run before PHP, the com_redirect component that runs after a 404, and Global Configuration switches that control how Joomla builds links. Pick the layer that matches whether the old URL still returns 200 or already 404s.

Redirects are not a cosmetic tweak. They are how you keep rankings when you rename an article, retire K2, force one hostname, or move HTTP to HTTPS without splitting authority across two URLs. Google treats a proper 301 as a strong signal to consolidate to the destination: Consolidate duplicate URLs.

This guide is the full map for Joomla 4, 5, and 6. For the "I saved a 301 and nothing happened" checklist, see Joomla 301 redirects not working.

Server rules run first. com_redirect only fires when Joomla has already decided the path is a 404.

What you will learn

• What 301, 302, and 307 mean in Joomla
• When to use .htaccess, nginx, com_redirect, or neither
• How to enable System – Redirect and publish rows in System → Redirects
• Exact .htaccess rules for www, non-www, and HTTP to HTTPS
• nginx and IIS equivalents when there is no .htaccess
• How to test headers, avoid redirect chains, and protect SEO after a migration

301, 302, and what Joomla actually sends

Code	Name	Use in Joomla
301	Moved permanently	Default for SEO migrations, retired aliases, www/HTTPS canonicalization
302	Found (temporary)	Short campaigns, A/B tests, maintenance you will reverse
307	Temporary redirect	Rare in Joomla admin; some server modules use it instead of 302

com_redirect defaults to 301 unless your Joomla version exposes per-row status codes under Redirects → Options. Server rules use [R=301] in Apache or return 301 in nginx.

A Menu Item Alias is not a redirect. It shows the same article at a second menu path while both URLs can still 200. Aliases are navigation. Redirects are HTTP responses. If two real menu items point at one article, you have duplicate URLs until you unpublish one or 301 the loser: Joomla duplicate URLs.

Pick the right layer

Layer	When it runs	Use it for
.htaccess (Apache / LiteSpeed)	Before PHP boots	www ↔ bare host, HTTP → HTTPS, /index.php/alias → /alias, folder moves, anything that still 200s
nginx server / location	Before PHP	Same jobs on nginx hosts (no .htaccess)
IIS web.config	Before PHP	Windows hosts
com_redirect + System – Redirect plugin	After Joomla returns 404	Old article aliases, retired menu paths, K2 URLs after uninstall
Global Configuration → Server → Force HTTPS	Link generation in Joomla	Makes Joomla emit https:// links. Pair with a server 301 for typed http:// visits
System – SEF	Rewrites URLs in HTML	Cleaner paths. Not a substitute for 301 when an old URL still resolves

Official component help: Redirects: Links (Joomla 5) and Redirects: New or Edit. Stock Apache snippets live in preconfigured htaccess.

If the old URL still loads a page, com_redirect never runs. Fix that at the server or unpublish the route.

Step 1: Set up com_redirect (Joomla 4, 5, and 6)

Use the component when the expired path is already a 404 and you want to manage dozens of mappings in the administrator.

Enable the plugin (not optional)

1. System → Plugins → search System – Redirect → Enable.
2. On fresh installs this plugin is often disabled. Rows in System → Redirects do nothing until it is on.

Do not confuse it with System – SEF. SEF builds pretty links. It does not send 301s for dead paths.

Create a redirect row

1. System → Redirects → New.
2. Expired URL: the full old address as you would type it (https://www.example.com/old-alias).
3. New URL: the full destination.
4. Status: Enabled (published). Collected 404s stay disabled until you add a New URL and publish.
5. Save.

Optional: turn on Collect URLs in the plugin so 404s appear in the list for you to map. Collection is logging, not redirecting.

Regex and bulk work

• Enable Regular expressions on a row when you need a pattern (example: all /blog/2019/ paths). Test one URL before importing hundreds.
• After a K2 removal, map /component/k2/... to new com_content URLs as part of Migrate K2 to Joomla articles. Do not leave public 404s while you "collect later."
• Joomla expects Use URL Rewriting on and a working rewrite file, or matching is unreliable. See Joomla index.php still in URLs.

If a row is published and the old URL still shows the old page, a menu item or alias is still serving it. com_redirect cannot help until that route 404s or you move the job to .htaccess.

Step 2: Redirect www and non-www in .htaccess

Pick one canonical host (www or bare) and 301 everything else. This belongs in server config, not in com_redirect.

Joomla ships a commented block in .htaccess labeled custom redirects. Place rules after RewriteEngine On and before the Joomla core rules, or inside the documented custom section from preconfigured htaccess.

Bare → www (replace example.com):

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example.com [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]

www → bare:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.example.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

Notes:

• Use your real domain. Escape dots in the host (example.com).
• If you also need HTTP → HTTPS, chain both conditions or use one rule that targets the final https:// host.
• [NC] makes the host match case-insensitive. [L] stops processing. [R=301] sends the permanent redirect.

After editing, purge CDN cache and test in a private window. The address bar should show your chosen host on the first hop.

Step 3: Force HTTPS at the server and in Joomla

Server (Apache / LiteSpeed)

Below RewriteEngine On, when SSL is working:

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [L,R=301]

Better: combine host canonicalization and HTTPS in one rule set so you do not create a chain (http://example.com → https://example.com → https://www.example.com).

Joomla Global Configuration

System → Global Configuration → Server → Force HTTPS: set to Entire Site once the certificate is valid. That makes Joomla generate https:// links in HTML. It does not always redirect a visitor who manually types http://. Keep the server rule for that.

Step 4: Single-path and migration redirects in .htaccess

When one old path still 200s but must point elsewhere:

Redirect 301 /old-folder/page https://www.example.com/new-alias

Or with mod_rewrite:

RewriteRule ^old-alias/?$ https://www.example.com/new-alias [L,R=301]

Use this for:

• Renamed menu aliases while the old menu item still exists
• /index.php/seo-tips → /seo-tips after SEF is fixed
• Retired microsite folders

For large content moves, pair server rules for structural changes with com_redirect rows for long-tail aliases that already 404.

Step 5: nginx and IIS when Joomla has no .htaccess

nginx (inside the server block for the site):

# bare to www + HTTPS (adjust host names)
if ($host = example.com) {
    return 301 https://www.example.com$request_uri;
}
if ($scheme = http) {
    return 301 https://$host$request_uri;
}

Official Joomla nginx notes: Nginx. You still need try_files so SEF works: details in Joomla index.php URLs.

IIS: rename web.config.txt to web.config, install URL Rewrite, and add equivalent rules. Joomla documents IIS rewriting alongside Apache in Enabling SEF URLs.

Step 6: Test headers, chains, and loops

1. Browser Network tab → first document request → Status should be 301 (or 302 if intentional) with a Location header pointing at the final URL.
2. Command line: curl -I https://www.example.com/old-path and read HTTP/1.1 301 plus Location:.
3. Avoid chains longer than one hop (/a → /b → /c). Google will follow them but dilutes signals. Point /a straight to /c.
4. Loops (/old → /new → /old) crash the browser. Usually a com_redirect New URL points back at the expired path.
5. Clear Joomla cache and any CDN. Cached 404 HTML can hide a redirect you just published.

Canonical tags complement redirects but do not replace them when both URLs still 200: Joomla canonical URL problems.

Redirect mistakes that still waste SEO

Mistake	Why it hurts	Fix
302 instead of 301 for a permanent move	Search engines may not consolidate equity	Use 301 in server rules or Redirect options
Old URL still 200	com_redirect never runs	Unpublish menu item or use .htaccess
Plugin off, rows published	Looks configured	Enable System – Redirect
Slash / www / HTTP mismatch	Row does not match request	Add rows for each variant or force one host at server
Only fixing canonical, not 301	Two indexable URLs remain	301 losers after duplicate audit
Leaving K2 404s public	Crawl budget on dead paths	301 map during K2 migration

Key takeaways

1. 301 is the default for permanent Joomla URL changes that should pass ranking signals.
2. Server rules handle www, HTTPS, and paths that still return 200. com_redirect handles paths that already 404.
3. Enable System – Redirect. The component UI alone is not enough.
4. Publish redirect rows. Collected 404s are a log until Enabled with a New URL.
5. Match the full expired URL (scheme, host, slash) or canonicalize host at the server.
6. Test with response headers, not only whether the browser lands on the right page.
7. After migrations, map old aliases before you declare SEO done. Broader cleanup: Joomla on-page optimization and Joomla SEO services.

Frequently asked questions

What is a 301 redirect in Joomla?

An HTTP response that tells browsers and crawlers a URL moved permanently. Joomla can send it via com_redirect after a 404, or via .htaccess, nginx, or IIS before PHP runs.

Should I use com_redirect or .htaccess?

Use .htaccess (or nginx/IIS) for www, HTTPS, and any old URL that still loads. Use com_redirect when the old path already 404s, such as retired article aliases.

How do I redirect non-www to www in Joomla?

Add Apache rewrite rules after RewriteEngine On in .htaccess, or the nginx/IIS equivalent. Do not rely on com_redirect for hostname changes while both hosts still 200.

How do I redirect HTTP to HTTPS in Joomla?

Force HTTPS in Global Configuration → Server for link generation, and add a server 301 from http:// to https:// so manual HTTP visits redirect too.

Why is my Joomla 301 redirect not working?

Usually the System – Redirect plugin is off, the row is unpublished, or the old URL still returns 200. Full checklist: Joomla 301 redirects not working.

Does Joomla redirect preserve SEO?

A correct 301 tells search engines to consolidate signals to the new URL. Chains, 302s, and duplicate 200 URLs undermine that.

Can I bulk import redirects in Joomla?

Yes on many Joomla 4/5/6 builds via System → Redirects import (CSV). Test a few rows, then import. Regex rows need extra care.

Is a menu alias the same as a redirect?

No. An alias serves the same content at a second menu path. Both can 200. A redirect returns 301/302 and stops serving the old URL.

What about IIS servers?

Rename web.config.txt, install URL Rewrite, and add host and HTTPS rules there. com_redirect still works for 404 paths on IIS.

Where do I put custom .htaccess redirects?

Use the custom redirects section documented in Joomla's preconfigured htaccess, after RewriteEngine On, without breaking the core Joomla rewrite block.

To create a custom 404 page in Joomla 5 or 6, publish a Custom HTML (or other) module in the error-404 position on Cassiopeia or a child of Cassiopeia. Joomla still returns HTTP 404. The module replaces the default message inside error.php. Do not header('Location: …') to a normal article. That turns a missing URL into a 302 or 200, which is what the 2019 version of this page did, and it is the wrong signal for Google.

On Joomla 4 there is no error-404 position in core Cassiopeia. You copy error.php into a child template and edit that copy, or you add the same module include that Joomla 5 shipped. Known broken URLs that should move, not 404, belong in the Redirect component.

A custom 404 is still a 404. Pretty HTML does not mean a 200 OK.

What you will learn

• Why a redirect to an article is not a 404 page
• How Cassiopeia error-404 and error-403 modules work (Joomla 5.0+)
• How to put the same pattern in a child template or a club template
• What to put on the page (search, home, useful links)
• How to test status codes, not only the design
• When to 301 instead of 404

Official module positions: Custom Error Pages (Joomla 5.4 manual). Magazine walkthrough: The 404 That Could (JCM, November 2025).

The 2019 method, and why to stop using it

The old Infyways steps were: create a 404 article, noindex it, copy error.php, then:

header('Location: /index.php?option=com_content&view=article&id=292');
exit;

What you wanted	What that code does
“Page not found” for humans	A second request to a real article
HTTP 404 for Google	Usually 302 then 200 on the article
One branded error view	A normal com_content URL that can get indexed unless you fight robots

Search engines need 404 (or 410) for URLs that are gone with no replacement. Soft 404s (200 with “not found” text) waste crawl time. If the URL moved, use a 301 in System → Redirects, not a custom error page.

If your site still has that Location block in error.php, delete it before you add a module. Put the file in a child so the next Cassiopeia update does not restore a hack, and so your fix is not wiped. Rule: customize Joomla without editing core.

Joomla 5 and 6: the error-404 module (preferred)

Cassiopeia since Joomla 5.0 reads modules in:

• error-404 for not found
• error-403 for forbidden

If no module is published there, visitors still get the default language strings. Debug output still appears under the module when debug is on.

No error.php edit is required on stock Cassiopeia 5+. A child still needs the same include if you copied a thin error.php.

Step 1: Use a child template

Create and assign a Cassiopeia child if you do not have one. How to set up a Joomla child template.

Club templates: check whether they already declare error-404. If not, you will add the include in Step 4.

Step 2: Create the 404 content as a module

1. Content → Site Modules → New
2. Type: Custom (Custom HTML). Search, Latest Articles, or a menu module also work.
3. Title: something you can find later, for example 404 message. You can hide the title.
4. Write the message: short apology, home link, search, two or three real destinations. Keep it useful, not a joke that hides the next click.
5. Position: type error-404 if it is not in the dropdown. Cassiopeia 5+ accepts it even when the style UI is thin.
6. Status: Published. Menu assignment: On all pages. The error document is not a normal menu item. All pages is the safe assignment.
7. Save.

Use absolute https:// URLs for images and the home link. Relative src="images/…" often breaks on nested missing paths (/category/no-such-page). That is a known error-page path issue. Prefer full URLs until your Joomla patch level includes the error-page SEF fixes.

Step 3: Test the status, then the design

Open a URL that does not exist, for example https://www.example.com/this-page-is-not-real.

You should see your module. Then check the status:

• Browser Network tab, or
• curl.exe -sI https://www.example.com/this-page-is-not-real

You want HTTP/1.1 404 (or 404 from HTTP/2). If you see 200 or 302 to /404 or to an article, you still have a redirect in error.php or in .htaccess.

Step 4: Joomla 4, or a template without error-404

Copy parent error.php into the child (same filename at the child template root), then add the official include. Do not edit the parent Cassiopeia file.

<?php
$errorCode = $this->error->getCode();
?>
<?php if ($this->countModules('error-' . $errorCode)) : ?>
  <div class="container">
    <jdoc:include type="modules" name="error-<?php echo $errorCode; ?>" style="none" />
  </div>
<?php else : ?>
  <?php // keep the template's original default message here ?>
<?php endif; ?>

That snippet is the Joomla custom error pages pattern. Wrap it around the default heading so you do not delete fallback text.

A full branded layout is still error.php in the child: logo, user.css, maybe a search module. Same child rule as any other PHP file.

Step 5: 403, Redirects, and language strings

Need	Tool
Forbidden (logged-out vs ACL)	Module in error-403, same idea as 404
Old URL has a new home	System → Redirects, 301. Not a 404 page
Default “page not found” wording only	Language override, if you are not using a module
Pretty CSS	Child user.css, not a core Cassiopeia sheet

Do not noindex a real 404 URL in an article. There should not be a public article acting as the 404 document.

Key takeaways

1. A custom 404 page must keep HTTP 404. Do not redirect error.php to a com_content article.
2. On Joomla 5 and 6 Cassiopeia, publish a module in error-404.
3. Put PHP and CSS in a child template. Parent updates will replace error.php if you edited Cassiopeia itself.
4. Use absolute URLs for images and home on the error document.
5. Test with a fake path and with the response code.
6. Moved content is a 301. Gone content is a 404. Soft 200 is the worst of both.

Need a branded error page built into a client template? Joomla design services. Ongoing 404 cleanup: Joomla SEO services.

Frequently asked questions

How do I create a custom 404 page in Joomla 5?

Publish a Custom HTML module in the error-404 position on Cassiopeia (or a child that includes that position). Visit a missing URL and confirm HTTP 404.

Should a Joomla 404 page return HTTP 200?

No. 200 on a not-found URL is a soft 404. Keep 404. Redirects belong in the Redirect component when the page moved.

Does the error-404 module work on Joomla 4?

Not in core Cassiopeia 4. Copy error.php into a child and add the error-{code} module include, or run Joomla 5+ Cassiopeia.

Why are images broken on some 404 URLs?

The missing path is nested, and the image used a relative URL. Use absolute https:// links. Update Joomla when error-page SEF path fixes are in your branch.

Can I use an article as the 404 page?

You can, if you redirect to it. You should not. You lose a clean 404. Use a module on the error document instead.

Will a Cassiopeia update delete my 404 module?

No. Modules live in the database. A parent error.php you edited by hand can be overwritten. Keep PHP in a child.

To enable maintenance mode in Joomla, open System → Global Configuration, stay on the Site tab, set Site Offline to Yes, choose an offline message (and optional image), then Save. Guests see the offline page with a login form. The administrator stays available. This is core Joomla. You do not install a plugin. The same switch works on Joomla 4, 5.4, and 6. Joomla calls it Site Offline, not “maintenance mode.” Searchers use both names.

The 2019 version of this page stopped at “set Yes and Save.” That is still the click. In 2026 you also need Offline Access for staff who are not Super Users, a message that is not a language-file hack, and a way back in if Global Configuration will not save.

Site Offline hides the frontend from guests. It does not lock you out of administrator.

What you will learn

• Where Site Offline lives on Joomla 4, 5, and 6
• How to set a custom message and an offline image
• Who can still log in on the frontend while the site is offline
• How to grant Offline Access without making everyone a Super User
• How to restyle the offline page in a child template
• How to force the site online if configuration.php is stuck

Official walkthrough: Taking the website temporarily offline. User manual: Site Offline.

Site Offline versus a real outage

Situation	Use
Planned update, template work, extension install	Site Offline in Global Configuration
White screen, 500, or you cannot open administrator	That is a break, not maintenance. Start with diagnostics, not this switch
You want HTTP auth in front of Joomla	Directory privacy on the host. The Joomla guide covers that as a separate “all users” lock
You only want a banner, site still public	A module or a custom message, not Site Offline

Site Offline is a flag in configuration.php (public $offline). When it is 1, the frontend layout is the offline view. Administrator is unchanged.

Step 1: Open Global Configuration

Log in to administrator.

On Joomla 4, 5, and 6 go to System → Global Configuration. The Home Dashboard also has a Global Configuration icon. Both open the same form.

Stay on the Site tab. That is the first tab. If you landed on Server or Permissions, click Site.

Step 2: Set Site Offline to Yes

Find Site Offline. Set it to Yes.

Joomla then shows the offline-related fields: Offline Message, Custom Message, Offline Image.

Do not Save yet if you still need to write the visitor-facing text. An empty custom message with “Use Custom Message” selected looks broken.

Save last. Test the frontend in a private window after Save.

Step 3: Choose the message and image

Offline Message has three useful values:

Setting	What visitors see
Site language default	The string from the site language file. English is “This site is down for maintenance. Please check back again soon.” Other languages use their own translation
Use custom message	The text in Custom Message
Hide	No message block. The login form can still appear

Prefer Use custom message for a dated note: what you are doing, when you expect to return, a status URL if you have one. Do not promise a clock you cannot keep.

Offline Image is optional. The help screens still advise keeping it under 400px wide. Upload through Media, then select it here. A huge PNG on a maintenance page is a bad first impression.

If you only need to change the default English sentence and you are not using a custom message, use a language override for that string. Do not edit core .ini files.

Step 4: Save and test as a guest

Click Save or Save & Close.

Open the public site in a private window, or another browser, not the session that is already logged in as Super User. Super Users with frontend access will not see what guests see.

You should get the offline page and a login form. Administrator at /administrator/ must still load.

If Global Configuration refuses to save, configuration.php is not writable. Fix permissions or the FTP layer, then try again. Joomla documents this under Cannot save Global Configuration changes.

Step 5: Decide who may enter while it is offline

The user manual is explicit: Site Offline does not apply to administrator. People who can log in to the backend can still log in to the frontend. Frontend login is denied by default to Registered, Author, Editor, and Publisher.

Staff who are not Super Users need Offline Access.

1. System → Global Configuration → Permissions
2. Select the group (for example Manager, or a custom “Editors on call” group)
3. Set Offline Access to Allowed
4. Save

Do not grant Super User to “let them see the site during maintenance.” That is the wrong permission.

Step 6: Customize the offline page without editing core

The default offline layout is a PHP view. To change markup, copy the layout into a child template html/ override. Do not edit Cassiopeia or components/ in place. Same rule as every other file Joomla will overwrite: customize Joomla without editing core.

CSS for the offline page belongs in that child’s user.css, not in a compiled template sheet.

If the job is a full branded holding page and you do not want to own the override, Joomla design services.

Step 7: Turn maintenance mode off

When the work is done:

1. System → Global Configuration → Site
2. Site Offline → No
3. Save

Test as a guest again. If you still see offline, you are looking at cache (Joomla page cache, Cloudflare, or the browser). Purge those layers.

If you are locked out of the switch

If administrator is up but you cannot save Site Offline, or you need the site public from the server:

1. Backup configuration.php.
2. Open it in a file manager or SFTP.
3. Find public $offline.
4. Set it to '0' for online, '1' for offline.
5. Save. Confirm the file is not left world-writable.

Only do this when the admin form cannot save. A typo in configuration.php takes the whole site down.

Key takeaways

1. Joomla maintenance mode is Site Offline in Global Configuration on the Site tab.
2. No extra extension is required on Joomla 4, 5, or 6.
3. Save, then test in a private window. A Super User session is a bad test.
4. Custom Message plus an optional image under 400px is the visitor-facing layer.
5. Grant Offline Access to staff groups. Do not promote them to Super User for this.
6. Override the offline layout in a child template. Leave core files stock.
7. If the form will not save, $offline in configuration.php is the emergency switch.

Need this done during an upgrade window? See our Joomla maintenance services.

Frequently asked questions

How do I enable maintenance mode in Joomla 5 or 6?

Open System → Global Configuration → Site tab, set Site Offline to Yes, set the message, then Save. The administrator stays online.

Is Site Offline the same as maintenance mode?

Yes, for Joomla. The product name is Site Offline. Searchers say maintenance mode. It is one switch.

Can visitors still log in when the site is offline?

Only groups with Offline Access (and users who can already use the backend). Registered, Author, Editor, and Publisher cannot, unless you change Permissions.

Does Site Offline hide the Joomla administrator?

No. /administrator/ stays available. Use host-level directory protection if you need to hide that too.

Why do I still see the live site after setting Site Offline to Yes?

You are logged in with access, or cache is serving the old HTML. Use a private window and clear Joomla plus CDN cache.

Can I change the offline page HTML?

Yes. Put an override in a child template. Do not edit core PHP. See Joomla child template.

What if Global Configuration will not save?

Make configuration.php writable long enough to save, or set public $offline by hand, then lock permissions down again.

To add a favicon in Joomla, change what the active site template (or a system plugin) prints in the page head as rel="icon". That is not always Cassiopeia, and it is not always three Joomla-named files. Helix, T4, Gantry, YOOtheme, and most club templates have their own favicon field or their own filenames. Cassiopeia is only the core default. View source, find the current href, then use that template’s option, replace that file, or inject a pack and strip the old tags.

A favicon is the mark in the browser tab, bookmarks, and (with extra sizes) on a phone home screen. Joomla 4, 5, and 6 all work the same way at the HTTP level: whatever is in <head> wins. This guide starts with that, then covers template options, Cassiopeia’s media files as one special case, cache, and when a generator plugin is easier than fighting five different template UIs.

The tab shows whatever the assigned template or a plugin put in the head. Cassiopeia is one of those templates, not the only one.

What you will learn

• How to see which URL Joomla is actually using for the icon
• Where commercial templates usually store the favicon (style options)
• The Cassiopeia-only three-file names, if that is your template
• Why Atum (administrator) is a separate pack
• How cache hides a correct upload
• When Easy Favicon is the template-agnostic manager

Do not edit parent index.php to hard-code a <link>. Same rule as CSS: customize Joomla without editing core. Prefer a child template when you must change files.

Step 1: See what is in the head

Open the public site. View source. Search for rel="icon", apple-touch-icon, and shortcut icon.

Write down:

• The href (that is the file you must replace, or the tag you must override)
• Whether there is more than one icon link (SVG plus ICO plus Apple is normal)
• Whether the path is media/templates/…, templates/…, images/…, or a CDN

If Helix (or another club template) prints a tag after Cassiopeia’s, the later tag often wins in the browser. Replacing Cassiopeia files then looks like “Joomla ignored me.” You were on the wrong template.

Also check System → Site Template Styles. The style with the star (and any menu assignment) is the one that must receive the change.

Step 2: Use the template’s own favicon control

Most paid templates never use joomla-favicon.svg. They expect an upload in Template Styles.

Template family	Where to look first
Helix Ultimate / JoomShaper	Template Options → a logo or favicon / favicon ICO field (name varies by version)
T4 (Joomlart)	Template style → theme / site identity
Gantry 5	Outline → Page Settings or atom for favicon
YOOtheme Pro	Customizer → favicon / apple-touch
Other club templates	Search the style for “favicon”, “icon”, or “site identity”
Cassiopeia (core)	No favicon field. Use the media files in the next section
Atum (core admin)	Separate administrator template. Frontend files do not change the backend tab

Upload a square PNG or ICO, 512×512 or larger if the field accepts PNG. Save the style. Then skip to cache (Step 4) and prove the new href in view source.

If the field only stores one ICO, you still will not get Apple 180 or Android adaptive icons unless the template generates them. That gap is why a pack plugin exists.

Step 3: Replace files only when the head points at files

This is the right move when view source shows a path under your template’s images or media folder.

Cassiopeia (and a Cassiopeia child) is the documented core case. It loads three names:

• joomla-favicon.svg (rel="icon")
• favicon.ico (rel="alternate icon")
• joomla-favicon-pinned.svg (rel="mask-icon")

Path on Joomla 4.1, 5, and 6:

media/templates/site/{template}/images/

If the assigned style is a child cassiopeia_brand, that folder is media/templates/site/cassiopeia_brand/images/. Replacing files only on parent Cassiopeia does nothing while the child is default.

If you replace only favicon.ico, Chrome can keep the SVG. Replace all three. Official map: Cassiopeia Template Folders and Files.

Any other template: do not invent those three Joomla filenames. Replace the file the href already names, or use the template option in Step 2. Joomla 4.0-era templates/{name}/images/ still appears on old forks. Match the live href, not a blog from 2017.

Root /favicon.ico: some bots still request it. It does not override a later SVG in Chrome.

Wrong template style, or the wrong filename, is why the Joomla mark remains.

Step 4: Clear cache and test in a clean browser

1. System → Maintenance → Clear Cache
2. Purge CDN cache if you use one
3. Private window, or a browser profile that has not seen the old icon

Chrome on phones caches favicons hard. View source again. The href must change. If it did not, you edited the wrong style or the template is still injecting the old URL.

Pick the method

Situation	Do this
Club template with a favicon upload	Step 2. Then view source.
Cassiopeia or Cassiopeia child	Three named files in that template’s media images/ folder
Head shows a path you do not recognise	Replace that file, or the template option that wrote it
Several icon tags from the template plus a plugin	Strip or disable one source. Two systems fighting is the usual mess
Apple, Android, dark mode, different admin tab	Pack plugin (next section), or a full generator ZIP plus template fields
Administrator tab still Joomla	Atum media files or an admin pack. Frontend changes never touch it

Managing icons across templates with Easy Favicon

Template options and Cassiopeia files are enough when you have one ICO and a cooperative theme. They are a poor manager when every client site uses a different template, or when Helix keeps printing the old apple-touch link.

Easy Favicon is a JoomlaX system plugin for Joomla 4, 5, and 6. It is template-agnostic: one master image, generate the pack, inject tags, optionally strip competing favicon and apple-touch tags so Helix, T4, or Cassiopeia defaults lose. That is the point of mentioning it here. It is not required to “add a favicon.”

From System → Plugins → System – Easy Favicon you can manage:

Need	What it does
One upload, usual sizes	16, 32, 48, Apple Touch 180, Android 192 and 512, optional ICO
Site vs administrator	Site pack, optional admin pack (reuse or a second master)
Dark OS theme	Optional dark masters
Android cropping	Maskable padding and background
Template still winning	Strip level for foreign icon tags
Mobile chrome	theme-color meta
Another PWA owns the manifest	Off, Generate, or Defer
Handoff	Preview, regenerate, ZIP. Files under images/easyfavicon/

PHP 8.1+, GD or Imagick. No jQuery. Icons stay on your server.

First run: install the inner plugin zip, enable it, choose a square master (512×512+ PNG or SVG), Generate all icons, clear cache, check the public tab, then the admin tab if the admin pack is on. If generate fails, check GD/Imagick. If the old icon remains, raise strip strength and purge CDN. If a PWA extension owns the manifest, set Defer or Off.

Docs: Easy Favicon documentation. Demo: Easy Favicon demo. JED listing. JoomlaX is Infyways’ extension store.

Key takeaways

1. The favicon is whatever the assigned template or plugin puts in <head>. Start with view source.
2. Most commercial templates use a style option, not Cassiopeia’s three filenames.
3. Cassiopeia is the core default: joomla-favicon.svg, favicon.ico, joomla-favicon-pinned.svg in that template’s media images/ folder, preferably a child.
4. Atum (admin) is a second template. Frontend files do not change the backend tab.
5. Prove the new href, then fight cache.
6. A pack plugin is for multi-size, admin, dark mode, and stripping template tags, not for every simple ICO swap.

Client branding across club templates: Joomla design services.

Frequently asked questions

How do I add a favicon in Joomla 5 or 6?

Find the assigned template style. Use its favicon option if it has one. On Cassiopeia, upload the three named files to that template’s media images/ folder. Clear cache and check view source.

Does this only work with Cassiopeia?

No. Cassiopeia is the core default and uses three specific filenames. Most live sites use Helix, T4, Gantry, YOOtheme, or another club template. Start from view source and that template’s style options.

Why does Chrome still show the old icon?

Wrong template style, a later tag from a club template, only one of several files replaced, or favicon cache. View source before you upload again.

Do I need a plugin?

No, if the template option or file replace already updates rel="icon". Yes, if you need a full size pack, a separate admin icon, or to strip Helix (or similar) tags.

Where do Easy Favicon files live?

Under images/easyfavicon/. The plugin injects head tags. You do not have to name Cassiopeia’s three files when it is managing the pack.

Will a template update delete my favicon?

A parent template media file can come back. A child, a template-style upload in the database, or plugin files under images/easyfavicon/ are safer.