JoomShaper Indigo - Joomla Template

A Guide to Setting Up and Using JoomShaper Indigo on a Joomla Website

JoomShaper Indigo is not just a ready-made look for Joomla. It is a bundle of connected solutions: a Helix Ultimate template, pages built with SP Page Builder, demo variations for the homepage, portfolio, blog, utility pages, navigation with Mega Menu, and a shop-oriented setup. In this guide, we will look at how to treat it as a working foundation for a real website, not just a polished demo screenshot.

This material is aimed at site owners, Joomla administrators, and developers who need to quickly understand where Indigo is strongest, which settings to review after installation, how to avoid breaking the demo structure, how to adapt the homepage for a real business, and where to look if the menu, modules, SP Page Builder, or styles do not behave the way you expected.

The main idea is simple: Indigo works best when you separate the work into three layers. The first layer is the template and its styles in Joomla. The second is the Helix Ultimate layout, positions, and navigation. The third is the content pages and blocks inside SP Page Builder. If you blur those layers together, it becomes very easy to edit the wrong thing: changing a module when the problem is actually in a menu item, or hunting for CSS when the section is simply hidden in the responsive settings.

Where Indigo Works Well and When Another Template Makes More Sense

Indigo is designed as a multipurpose template for business websites, agencies, corporate pages, portfolios, and smaller product catalogs. You can see that both in the product page and in the demo: the top of the page focuses on a large hero section, a high-contrast call-to-action button, clean navigation, a value statement block, services, portfolio, facts, testimonials, a blog, and a shopping variation. That combination works well for a site that needs to do more than publish contact details. It helps present trust, expertise, case studies, and a clear user path.

The best use case for Indigo is a company site with several service lines, visual case studies, a team, a blog or news section, and one or two key conversion goals. For example, a consulting firm could build a homepage with a hero section, service sections, a "why us" block, a project portfolio, testimonials, and a contact form. A creative agency could lean on the portfolio and industry tabs. A small gift shop or digital products store could test the shopping variation, but only after separately configuring products, payments, shipping, and access permissions.

Indigo should not be treated as a universal substitute for actual site planning. The template speeds up the launch, but it does not solve your content structure, legal pages, real imagery, SEO page logic, or lead-handling workflow for you. If you need a highly minimalist blog with no page builder, the template may feel too heavy. If you need a complex store with serious inventory handling, it makes more sense to evaluate the eCommerce extension and integrations first, then choose the visual shell.

Who the Template Is a Good Fit For

Indigo makes sense if you want to get a site with a ready-made visual language up quickly and you are prepared to replace the demo content with real content. It is especially convenient for teams already working with Joomla, who understand menu items, modules, template styles, and are comfortable with SP Page Builder. The template is also useful for a developer who needs to hand over a site to a client where most text and visual edits can be made through the interface rather than by editing files.

• Service-based businesses where the hero section, trust, case studies, team content, and a contact form matter.
• Agencies and studios that need portfolios, category filters, and expressive page sections.
• Corporate websites that need multilevel navigation and a clean blog.
• Small catalogs or product showcases, if the shopping block is treated as part of the site rather than a complex commerce system.

Who It May Not Work For

The template may not be the best choice if you want a site with no builder, a completely custom design system from scratch, or a strict requirement for minimal code. Indigo also does not eliminate compatibility questions around third-party extensions: if you already have a complex booking component, CRM forms, a custom cart, or older overrides, those need to be tested separately. On projects like that, it is better to deploy the template on a site copy first, not directly over the live version.

What a Working Indigo Setup Is Made Of

JoomShaper's product page for Indigo highlights several important building blocks: compatibility with current Joomla branches, Helix Ultimate, SP Page Builder Pro, a set of homepage variations, portfolio support through SP Simple Portfolio, Mega Menu, blog styling, an eCommerce scenario, and a subscription form through an SP Page Builder addon. Those details help you divide the work correctly. The look of the homepage does not live in one place: some of it is controlled by the template style, some by the SP Page Builder page, some by modules and menu items, and some by separate extensions.

If you install QuickStart, you get a structure that is close to the demo. It already includes pages, menus, modules, the template style, and demo data. If you install only the template package on an existing site, you get the visual shell, but not necessarily the entire demo site. That distinction matters: the first path is convenient for a new project, while the second is better for a careful rollout on a site that already has content, users, and working URLs.

This kind of map helps you avoid mixing up actions. If you need to replace the text in the "Services" section on the homepage, that is usually an SP Page Builder task. If you need to change the menu layout or enable Mega Menu, that belongs in Helix. If you need to display a separate block above a component, you should look at module positions and module assignments. If a product is missing, you need to check EasyStore or another eCommerce extension, not just the template.

The Demo's Visual Logic: Hero, Services, Portfolio, and Trust

The screenshot of the top part of the demo shows Indigo's character very clearly. The header includes a top bar with contact details and languages, navigation with Home, Portfolio, Shop, Pages, Blog, and Addons, a centered logo, and a large hero section with a background image of a team and a short call to action. Below that comes a bright accent block, then the "We are only Indigo" information block, service cards, a tabbed portfolio, and the trust-building sections that follow.

That structure is not random. The template is built for a page where the visitor quickly understands who they are looking at, what services are available, whether they can review past work, and how to take the next step. If you mechanically swap out the background, heading, and cards without changing the meaning, the site will still feel like a demo placeholder. That is why it helps to map out the real content before editing: what single promise belongs in the hero section, which 3 or 4 services deserve the first row, which case studies belong in the portfolio, and what trust signals are needed before the contact form.

Do Not Keep the Demo Order Without Reviewing It

The demo page is built as a showcase of the template's capabilities, not as a ready-made strategy for every business. On a real project, the order of sections may need to change. A consulting firm often needs to show the problem and industries first, then move the portfolio lower. An agency may benefit from keeping the portfolio near the top of the first scroll. A store-focused project may need categories or delivery benefits earlier. Indigo gives you a framework, but the order of blocks should serve the page goal.

A practical approach is to keep the demo structure in the first draft, replace the content, and then review the page as if you were a new visitor. If the offer is still unclear after the hero section, do not change the CSS first. Change the meaning of the sections. If all service cards feel the same, add specifics: audits, implementation, support, training, ongoing maintenance. If the portfolio is empty, it is better to temporarily replace it with a "How we work" block than leave a set of empty cards.

Color and Typography

The original visual reference shows a clear contrast between neutral white sections, a large photograph, a teal-green accent, and strict navigation. That is not a palette you should break with random color choices. If the client's brand requires a different primary color, change it systematically: buttons, active tabs, service icons, hover states, and CTA blocks should stay consistent. Randomly turning one button red and another blue will quickly ruin the template's clean look.

What to Check Before Installation

Before you install Indigo, decide which scenario you need: a clean new site based on the demo, or introducing the template into an existing site. For a new site, QuickStart is usually more convenient because it deploys a ready-made copy of the demo structure. For a live site, QuickStart is risky as a direct path because it is effectively a Joomla site installation with a full set of files and data, not a normal extension install through the extension manager.

The Helix Ultimate documentation clearly separates QuickStart from a standard install: QuickStart is installed as Joomla itself, not through the Extension Manager. That is an important warning for Indigo, because many problems start when people try to "install the demo" on a Joomla site that is already running. If the site is live, use a staging subdomain, a copy of the database and files, or a separate local environment. Move only verified settings, pages, and content to the real site.

Minimum Pre-Launch Checklist

• Create a backup of the files and database if you are not working with a clean installation.
• Confirm which package you actually have: QuickStart, a regular template package, SP Page Builder Pro, and any extra extensions.
• Make sure the hosting environment meets the requirements for the current Joomla version and the extensions you plan to use.
• Prepare a separate database for QuickStart, or a new table prefix in a staging environment.
• Confirm access to the admin panel, file manager, or SFTP, because troubleshooting sometimes requires clearing cache or checking files.
• Gather real images, the logo, service copy, contact details, legal pages, and the menu structure before you begin large-scale editing.

Safe rule: if you cannot clearly explain how QuickStart differs from installing a template, do not deploy QuickStart on a live site. Test it on a separate copy first.

What Depends on the Installation Source

The Indigo product page lists related tools, but the actual file set depends on which archive you downloaded and what product plan is available to you. You should not assume that installing a single template on an existing site will automatically bring in every page, product, portfolio item, and menu from the demo. If you specifically need demo-level results, verify the package contents and JoomShaper instructions. If you are migrating the design manually, plan separate stages: template, SP Page Builder pages, menus, modules, portfolio, store, and forms.

Installation: QuickStart, Template Package, and the First Review

Indigo installation should start with the scenario you have chosen. For a new project, the fastest path is to deploy QuickStart on an empty environment. For an existing site, it is usually safer to install the template package, make sure the site still opens correctly, and then move pages and settings one at a time. In both cases, do not jump straight into design work after installation. First confirm the basics: the admin panel opens, the front end loads, menus do not lead to 404 pages, SP Page Builder pages can be edited, cache can be cleared, and there are no obvious critical errors in the browser console.

QuickStart for a New Site

Install QuickStart the same way you would install a standard Joomla site. Unpack the archive, upload the files to the target directory, create the database, open the domain or staging subdomain in a browser, and go through the installer. During setup, do not use the default admin login for the super user. After a successful installation, remove installation traces, review the .htaccess file, and enable clean URLs only after you have confirmed that the site opens without server errors.

After signing in to the admin panel, create another backup. This will become your "clean point" after the demo installation. Then open the public homepage, several internal pages, the portfolio, the blog, and the shop variation. Note which parts you actually need and which parts you will remove. That saves time: there is no reason to edit every demo page if half of the structure will not make it into the final site.

Regular Template Package for an Existing Site

If the site is already running, install the template through Joomla's built-in extension manager, then open the list of template styles and assign Indigo only to a test menu item or a temporary page. Do not make the new template the default style until you have seen how it interacts with the current components, modules, and positions. On a live site, it is especially important to review older overrides, third-party modules, language files, and cache behavior.

If you already have SP Page Builder, make sure the version and package match your needs. The SP Page Builder documentation separately covers pages, Addons Management, the editor, section settings, and troubleshooting cache-related issues. That matters for Indigo because many visible blocks on the homepage are not "template magic" at all. They are simply sections and addons that need to open correctly in the editor.

First Review After Installation

1. Open the homepage in a normal window and in Incognito mode.
2. Check the main menu, dropdown items, off-canvas menu, and links to internal pages.
3. Open Components - SP Page Builder and confirm that the pages are available for editing.
4. Open the template settings and review Header, Layout, Menu, Typography, and Custom Code.
5. Clear Joomla cache and browser cache after the first change.
6. Check the page at desktop, tablet, and phone widths, because Helix and SP Page Builder have separate responsive settings.

Template Styles and Helix Ultimate: Where Configuration Really Starts

Real Indigo setup begins not with CSS, but with understanding the template style. In Joomla, the same template can have multiple styles assigned to different menu items. That is useful for Indigo: you can create a primary style for the homepage, a separate style for the shop area, another style for a service landing page, or a language-specific version. But this is also where mistakes happen most often: the administrator edits one style while the page is actually using another.

Start with an inventory. Open the list of template styles, find the Indigo style or the Helix-based style, check whether it is assigned as the default, and see which menu items use it. Then open the settings. In Helix Ultimate, the important tabs are Basic, Presets, Layout, Custom Header, Menu, Typography, Blog, Custom Code, and Advanced. You do not need to change everything at once. Start with the logo, header, menu, baseline typography, layout rows, and custom CSS only for small adjustments.

Header and Header Variations

The Indigo product page highlights multiple header style options. In the demo, the header plays a major role: it appears transparent or high-contrast over the hero area and includes a top utility bar, the logo, and several menu groups. Before you change the header, decide what matters most: branding, fast access to sections, languages, cart access, login, or a lead button. If you try to fit everything into the header at once, it will lose its light feel.

Check the header in three states: over the hero section with the background image, on an internal page with a light background, and at mobile width. If the logo is hard to read over the photo, do not change only the logo image. Review the header mode, background, spacing, and contrast as well. If the off-canvas menu does not show the items you need, look at the Menu settings in Helix and at menu assignment, not just the Joomla menu module.

Layout Builder and Module Positions

Helix Ultimate Layout Builder works with rows and columns tied to module positions. The documentation describes a 12-column grid, rows, columns, responsive settings, sticky columns, and the ability to select module positions. That is especially useful for Indigo if you need to add a block above a component, place a banner beside the content, change footer behavior, or create a utility strip for contact details.

Do not create positions randomly. Use clear names: hero-top, service-cta, footer-contact, shop-promo. If a position is needed on only one page, assign the module to a specific menu item. If it should be global, make sure the block does not unexpectedly appear on login pages, registration pages, checkout pages, or system pages.

Mega Menu and Off-Canvas

Indigo puts a lot of emphasis on expanded navigation. In Helix Menu Builder, you can control item structure, enable Mega Menu, add rows and columns, place modules inside dropdown menus, and manage icons and badges. That is useful for an agency site with many services or industry pages, but it requires discipline. A Mega Menu should not turn into a map of the entire site. It should help people choose a direction, not force them to read twenty items.

For mobile devices, check the off-canvas menu separately. In a multilingual project, each language may require its own menu and module set in the off-canvas position. If the English and Russian versions use different menu items, do not duplicate them blindly without checking assignments, or the mobile menu may point to the wrong language or to hidden pages.

How to Edit Indigo Pages in SP Page Builder

Most of Indigo's value shows up inside SP Page Builder. The demo pages are made of sections, columns, and addons: headings, buttons, images, portfolio tabs, testimonials, counters, an opt-in form, a gallery, blog-like cards, and other blocks. The Page Builder documentation shows that pages can be created, edited, duplicated, added to menus, and exported, and that section and addon settings are divided into General, Style, and Advanced.

Before making broad changes, create a copy of any important page. That is faster and safer than trying to undo dozens of edits manually. For example, duplicate the homepage, name the copy Home - Draft, assign it to a temporary menu item, and edit there. Once the result is ready, switch the menu item or replace the content of the live page. This approach is especially useful when you are changing the hero section, the order of sections, and responsive behavior.

Sections and Columns

In the section settings, review four groups: Style, Title, Responsive, and Animation. Style controls the background, color, spacing, border, and other visual parameters. Title is relevant if the section has its own heading. Responsive lets you hide the section on different devices. Animation controls motion. Do not turn animations on everywhere. On a business site, they should support attention, not slow down comprehension.

Columns have their own Style, Responsive, and Animation settings. This is often where mobile issues get solved: column order, visibility, and spacing. If a section looks good on desktop with "image on the left, text on the right," the phone version may need a different order, a hidden decorative element, or larger spacing between blocks. Check that both in the editor and on the actual public page.

Addons and Reusing Styles

SP Page Builder lets you copy, paste, duplicate, save, and rename addons. That is useful in Indigo because many sections repeat the same visual style: buttons, service cards, fact blocks, portfolio elements. If you are building new service pages, do not rebuild every section from scratch. Copy a tested block, replace the text and image, and then adjust only the meaning-specific details.

Do not delete a demo block right away if you do not understand what it depends on. Hide it through the settings first, or unpublish it on the draft page. That way you can return to it if it turns out the block contains styles you still need or a useful addon configuration example. After final approval, you can remove unneeded sections and clean up media files.

Subscription Form and External Services

The Indigo product page mentions subscription support through the SP Page Builder Opt-in Form addon with support for several email platforms. That does not mean email marketing will work automatically. You still need to choose the service, add the keys or integration parameters, verify user consent, the button text, the error message, and the confirmation email if one is used. On a public site, always test the form in a real browser and see what happens with an empty email, an invalid email, and a successful submission.

Portfolio, Services, Blog, and the Store Scenario

Indigo is interesting for more than just its homepage. On the JoomShaper product page, portfolio, service showcasing, blog design, the shop/eCommerce variation, and built-in pages are all highlighted separately. These areas matter because real business websites almost always break down not in the hero section, but on secondary pages: case studies, service pages, product cards, blog posts, contacts, and the 404 page.

Portfolio and Categories

In Indigo, the portfolio is built for visual presentation and category-based filtering. If you use SP Simple Portfolio or a similar component, define 4 to 6 categories that actually help the visitor choose. Do not use categories like "All," "Design," "Creative," or "Branding" just because the demo did. For an agency, better options might be "Corporate Websites," "Online Stores," "Branding," and "Support." For consulting, that could be "Audit," "Implementation," "Training," and "Ongoing Support."

Each case study should have a goal, a result, a short description, and an image. If the images vary too much in size and quality, the cards will look sloppy even with a good template. Prepare a consistent cover format in advance. After publishing, check the filters, the detail page, breadcrumbs, the meta title, the Open Graph image, and the return path back to the project list.

Service Pages

The Indigo demo presents services as separate cards and pages. On a real site, a strong service page should answer four questions: what problem the service solves, who it is for, how the work is done, and what the client gets. Use Indigo's blocks not as decorative sections, but as an argument structure. The hero section should present a concrete outcome. Then come the problem symptoms, the process, examples, FAQ, and CTA.

If you have many services, do not push them all into the top menu. Use Mega Menu or a dedicated "Services" page where the directions are grouped logically. The most important services can appear at the first menu level, but secondary ones are better kept inside a category. That improves navigation and reduces the risk of overloading the header.

Blog and Articles

Indigo's blog design is useful if you plan to publish expert content, news, or detailed breakdowns on a regular basis. But the blog should not become a storage room for random notes. Configure categories, author, article image, intro text, meta description, and the internal linking structure. Review how the article list, single article page, sidebar, pagination, and mobile version look. If you do not need the blog, it is better to hide it from the menu than leave demo posts in place.

Shop Variation

On the Indigo product page, the store scenario is tied to eCommerce features. On current JoomShaper pages, EasyStore is also promoted as a Joomla eCommerce solution, and the EasyStore documentation covers products, images, pricing, inventory, variations, checkout, payments, shipping, and SP Page Builder integration. For Indigo, that means the visual shop layout may already be prepared, but the store itself depends on the extension, product settings, and checkout validation.

If the store is only meant to be a showcase, start with 3 to 5 test products, categories, images, and a listing page. If you need to actually accept orders, separately verify taxes, shipping, payments, email notifications, guest orders, statuses, and legal pages. The template is responsible for clean presentation, but it does not replace proper commerce configuration.

Practical Example: Building a Homepage for an Agency

Let us look at a concrete scenario. You need to create a homepage for a small digital team: the company sells websites, support, and content, and wants to showcase services, case studies, the team, a blog, and a contact form. The Indigo demo is already close to that goal, so instead of building the page from scratch, we adapt one of the homepage variations.

Goal

Create a homepage where a visitor understands the offer within the first two scrolls, sees 3 key services, can move to the portfolio, and can submit an inquiry. The template should keep Indigo's visual strength: a large hero, teal accents, clean cards, portfolio tabs, and crisp white sections.

Preparation

Create a copy of the demo homepage in SP Page Builder. Prepare the logo, a hero photo or team image, 3 or 4 services, 4 case studies, a short process description, a contact email, and a link to the data processing policy. Check which menu item opens the current homepage, and assign the draft copy to a temporary menu item so you do not break the live page.

Setup Steps

1. Open the draft page in SP Page Builder and replace the hero heading with a specific promise: not "We are here for you," but something meaningful like "We launch and support Joomla websites for B2B teams."
2. Replace the first-screen button with a real action: inquiry, consultation, portfolio, or project estimate. Make sure the link points to an actual section or page.
3. In the purpose block, keep one strong point and one secondary button. If the two buttons compete, keep the main one.
4. In the services section, keep 3 cards: development, support, and content. For each card, write the outcome, not a generic string of words.
5. In the portfolio, create categories that match the actual case studies. Remove tabs that have no work behind them.
6. In the facts block, use numbers you can verify. If you do not have the numbers, replace the section with a process overview or a short FAQ.
7. Configure the footer: contact details, links, social profiles, legal pages, and a repeated CTA.
8. Check the mobile order of sections and the height of the hero section. On a phone, a large background image should not consume all the meaning.

Checking the Result

Open the page in Incognito mode, click every button, open the menu, submit a test form, and review the portfolio and blog. Then clear Joomla cache and browser cache. If old text still appears on the public page, confirm that you edited the page actually assigned to the current menu item. If the changes are visible in the editor but not on the site, start with cache and duplicate styles.

Short takeaway: successful Indigo setup is not about "replacing all the pictures." It is about aligning the demo structure with the real user path: promise, services, proof, action.

How to Connect Menus, Modules, and Pages into a Multi-Page Website

Once the homepage is in place, you reach the stage where Indigo usually becomes either a clean working website or a set of attractive but disconnected pages. You need to connect SP Page Builder pages, menu items, module positions, portfolio content, the blog, and the footer into a single navigation system. This is not decorative work. It determines whether a visitor can move from a service to a case study, from a case study to a form, from an article to an offer, and from the mobile menu to the right section.

Start with a simple site map. For a typical agency, the top level is usually enough: home, services, portfolio, about, blog, contacts. Inside services, you can create separate pages, but you do not need to put each one at the first level. Indigo works well with a hybrid approach: keep 5 or 6 items in the main menu and show deeper service links through Mega Menu. Repeat the key links in the footer and add legal pages there. In the off-canvas menu, keep only the most important items, because long navigation becomes awkward very quickly on mobile.

An SP Page Builder Page Needs a Clear Menu Item

SP Page Builder includes an Add to Menu action, but on a real project, it is best used intentionally. A page should have a clear menu title, alias, selected menu, parent item, and access level. If you create a service page but do not add it to the menu or internal links, it will exist as an isolated draft island. If you add the page to the menu but do not assign the correct template style, it may open with a different header, a different footer, or the wrong set of modules.

Review every important page as a chain: the page is created, published, added to the menu, using the correct template style, has the required modules, opens at the expected URL, works on mobile, and has a title and meta description. That kind of check takes only a few minutes, but it prevents the usual mistakes like "the page exists, but the menu points to the old copy" or "the form is in the editor, but hidden on the public page because of its access level."

It Is Better to Design Module Positions in Advance

Helix gives you a lot of freedom with module positions, but freedom should not turn into chaos. With Indigo, it helps to decide in advance which positions are global and which are contextual. Global positions: header, offcanvas, footer, maybe topbar. Contextual positions: CTA after a service, promo above the portfolio, shop notice, blog sidebar. If the same module should appear only on service pages, assign it to those menu items. If it should appear everywhere, check system pages too, so you do not end up with a CTA on the login page or the 404 page.

Pay especially close attention to language and access. If the site is multilingual, a module for the Russian version should not appear on the English page. If you have gated materials, a module with a public link should not send users into a section that is available only to registered users. Indigo looks great with clean CTA blocks, but poor assignment rules quickly make the site feel unfinished.

Review After Every Major Change

After changing a menu, a template style, or a module position, do a small result check. Do not wait until the end of the project to discover that the off-canvas menu on mobile still points to old pages and the footer still shows demo contacts. Open the homepage, one service page, one case study, one article, and the contact page. On each one, review the header, active menu item, breadcrumbs, main content, CTA, footer, and mobile menu.

If something breaks, roll back the last change instead of rewriting everything at once. For example, if a service page block disappears after enabling a new module, unpublish the module or restrict its assignment. If the header shifts after a Layout Builder change, restore the saved style copy or disable the custom header. The smaller the step, the easier it is to find the cause.

Checking Responsiveness, Performance, and SEO After Setup

Once the visual edits are done, you need to check not just how the site looks, but how it behaves. Indigo uses a responsive grid, Helix Layout Builder, and SP Page Builder sections, so the same issue can live at different levels. For example, a block may disappear on a phone because of a Responsive setting in SP Page Builder, because of Column Options in Helix Layout, or because of CSS added later.

Responsiveness

Check desktop, tablet, and phone widths. On the homepage, focus on the header, hero section, service cards, portfolio tabs, forms, footer, and the off-canvas menu. If a section is too long on a phone, do not jump straight to writing CSS. Open the section, column, and addon settings first. Sometimes changing the column order, hiding a decorative image, or reducing spacing is enough.

In Helix Layout Builder, keep the grid and breakpoints in mind. If the sum of columns in a row does not follow a sensible layout or if the hiding rules are too aggressive, the result will be unpredictable. For blocks that matter for SEO and for users, it is usually better not to hide the text completely on mobile. The Helix documentation notes that responsive hiding works through CSS, which means the content may still remain in the HTML. That matters when you review accessibility and page weight.

Performance

A visually rich template is easy to overload with images. In Indigo, hero photos, portfolio thumbnails, blog images, and shop images matter especially. Compress images to a sensible size, use clear alt text, and do not upload multi-megabyte originals if they only appear as cards. If extra images and pages are left over from the demo install, remove them only after making a backup and confirming they are no longer in use.

Animations, sliders, maps, third-party widgets, and subscription forms should all be reviewed separately. Not all of them are necessary on every page. If a service page needs to load quickly from search, some decorative blocks may be better removed. If a map on the contact page slows loading, you may be better off replacing it with a directions button and a static image, if that works for the project.

SEO and Structure

Every important page should have a unique title, meta description, H1 at the page level, a clear URL, breadcrumbs, and internal links. In this guide, the first heading starts with H2 because the product page already has an H1, but on your own site a standard service page should have one main H1. Do not carry over demo headings without meaning. Text like "We solve your problem" may look nice in the template, but for SEO and trust it is better replaced with a specific statement.

Check schema markup if you are using structured data features from SP Page Builder or Joomla. For the blog, make sure images, author, date, and category are displayed correctly. For the store, separately review product pages, canonicals, and whether price and status are present, if your chosen eCommerce extension supports them.

Safe Improvements Without Editing the Template Core

Indigo can be adapted cleanly without editing the template's core files. In the Helix documentation, JoomShaper recommends using the Custom CSS field or a separate custom.css/override.css file for small adjustments instead of editing template.css. For larger changes, template overrides are available. That is the right approach: updates should not wipe out your changes.

A Small CSS Tweak for Better CTA Contrast

If the button in the hero section becomes hard to read after you replace the background image, you can add a small rule in Custom CSS or in the custom.css file. First, identify the button class through the browser inspector on your site. The example below uses a placeholder section class that you should replace with the real class of your hero section. Do not paste the code in blindly.

/* Small contrast adjustment for the Indigo hero button.
   Replace .indigo-hero with the real class of your section. */
.indigo-hero .sppb-btn,
.indigo-hero .btn {
  border-color: #12c8b4;
  background-color: #12c8b4;
  color: #ffffff;
}

.indigo-hero .sppb-btn:hover,
.indigo-hero .btn:hover {
  background-color: #0fa898;
  border-color: #0fa898;
}

The validation step is simple: clear cache, open the homepage, hover over the button, and then check the page at phone width. If the rule affects too many buttons, narrow the selector to the specific section. Rolling it back is just as simple: remove the rule from Custom CSS or from the file.

Template Override for Clean Output Changes

If you need to change the markup of a component or module, use an override instead of editing the extension's source file. The Helix documentation covers how to create overrides for component and module views. With Indigo, you might need this, for example, if you want to adjust the output of an SP Simple Portfolio item or a module card without touching the core files. But you should create an override only after making a backup and understanding which file is actually responsible for the output.

Do not use PHP in the Custom CSS field, and do not add complex JavaScript unless there is a real need. If the task can be solved with SP Page Builder settings, Template Styles, or Joomla menu assignment, use the settings. Code should be the last small layer, not a replacement for proper configuration.

Languages and Localization

For a multilingual site, use Joomla's built-in tools and the Helix recommendations: the languages should be installed, pages and modules should be assigned to the correct languages, the off-canvas menu should be prepared for each language version, and the fonts should support the required characters. If some strings remain in English, check language files and overrides first, then review the content of the SP Page Builder pages. The demo includes a lot of English text, and that needs to be replaced manually as content, not by searching for a "template translation" for every phrase.

Common Indigo Issues and How to Diagnose Them

Most issues after installing Indigo are not caused by the visual layer itself, but by the wrong configuration level: cache, the wrong template style, the wrong menu item, a hidden SP Page Builder section, an incorrect module assignment, or a conflict with a third-party extension. It is best to troubleshoot from simple to complex.

Editor Changes Are Not Visible on the Site

Symptom: the text or section has changed in SP Page Builder, but the public page still shows the old version. Possible causes: the wrong menu item is being opened, you are editing a copy of the page, Joomla cache is enabled, the browser cache is stale, or there is CDN or server-side caching.

What to check: open the list of SP Page Builder pages, find the actual page tied to the menu item, verify the URL, clear Joomla cache through the admin panel, then open the page in Incognito mode. If Cloudflare or server-side cache is in use, clear that as well. The SP Page Builder documentation for similar editor issues also recommends checking browser cache, Joomla cache, and an alternate browser.

The Homepage Does Not Look Like the Demo

Symptom: after installing the template, the demo sections, portfolio, menu, or shop page are missing. The cause is often that only the template package was installed, not QuickStart. A regular template is not required to deploy the full demo site on an existing Joomla installation.

What to do: check which type of archive you used. If you need the demo site, deploy QuickStart on an empty staging environment. If the site is already live, migrate the structure carefully: pages, menus, modules, extensions, images, and settings. Do not try to "finish installing QuickStart" through the extension manager on a live Joomla site.

Mega Menu Does Not Show the Expected Columns or Modules

Symptom: the desktop menu does not show the expected columns, banner, icons, or nested items. Possible causes: Mega Menu is not enabled for the required item, the menu structure has not been built, the module is unpublished, the module is assigned to the wrong language or access level, or the changes were saved in the wrong template style.

Check Menu Builder in Helix, Mega Menu enablement for the specific item, rows and columns, the list of added modules, the module's published state, and language assignment. If the menu is multilingual, review the separate menus for each version. Rollback path: disable Mega Menu for the problematic item and return to a standard dropdown until you identify the issue.

A Section Disappears on Mobile

Symptom: the block exists on desktop but is not visible at mobile width. The cause may be Responsive settings in the SP Page Builder section, column, or addon, or Helix Layout column options. In some demos, the block is hidden intentionally to simplify the mobile version.

Open the section, column, and addon settings. Check visibility, ordering, and device-based hide/show rules. Then check Layout Builder if the block is a module inside a position. Do not write CSS before reviewing the interface settings. If the block is important to the meaning of the page, it is usually better to adapt it than hide it completely.

After an Update or Migration, the SP Page Builder Editor Is Unstable

Symptom: the editor does not open, some functions are unavailable, JavaScript errors appear, or an older interface version shows up. Possible causes: cache, a mix of Lite and Pro packages, outdated update sites, server-side cache, or a conflict with an override or third-party extension.

Start by clearing Joomla cache and browser cache, then check the SP Page Builder package, access permissions, and an alternate browser. If the issue appeared after an update, check whether there is an old update site for the free package and whether the Pro package needs to be reinstalled. If the error appears to be override-related, temporarily disable the custom override on a test copy and check again.

The Store Shows Products, but Orders Do Not Go Through

Symptom: product cards are visible, but checkout, shipping, payments, or notifications do not work. In that case, the problem usually belongs to the eCommerce extension and its settings, not to Indigo. The template affects the presentation, but the order logic lives inside the store component.

Check product settings, inventory, checkout, payment gateways, shipping, email notifications, and access permissions. Create a test product with a clear price and a simple purchase path. If you are using EasyStore, rely on its documentation for products, checkout, and SP Page Builder integration. Rollback path: temporarily disable disputed payment or shipping settings in the staging environment, but do not change live orders without a backup.

Useful Indigo Video

The official Indigo page includes a video with the ID Y-PUJsfbwRg. It is worth using as a quick visual reference before you start configuring the template: it reinforces the idea that the template should be evaluated through its ready-made variations, demo blocks, and overall visual logic, not just through its feature list. After watching it, it becomes easier to decide which homepage variation to use as a starting point and which sections to keep in the first draft.

When JoomShaper Indigo Is the Right Choice

JoomShaper Indigo is worth using if you need a visually rich Joomla template for a business website, agency, portfolio, or corporate showcase, and you are prepared to work with Helix Ultimate, SP Page Builder, menus, modules, and extensions as one connected system. Its strength is not any single block, but the ready-made rhythm of the site: hero section, services, portfolio, trust, blog, contacts, and a potential shop scenario.

Before final rollout, test QuickStart in a staging environment, configure the template styles, review the SP Page Builder pages, remove unnecessary demo content, and check the menus, responsiveness, cache, forms, and SEO data. If the structure matches the project's goals after that, you can get the JoomShaper Indigo file and use the template as the foundation of a working site.

If instead you need a narrowly focused template for consulting, a fresher digital agency style, or a portfolio without the store layer, compare Indigo with Unfold, Artolio, Stratos, and Anobiz. The right choice is the one that requires less removing, renaming, and rebuilding. A good template only speeds up a project when its structure matches the real site scenario.