FAQs

Studio CMS is the content management platform where pages, blocks, SEO, menus, forms and integrations are configured. Studio Help works as the operational support layer that explains this ecosystem in a practical way.

In practice, Studio Help reduces friction between editorial, marketing and technical teams because it turns backoffice tasks into clear, reusable steps.

The page is the main structure where the URL, SEO, language, hierarchy and editorial purpose are defined. Blocks are the internal components that build the visible content of that page.

This matters because SEO does not live only at page level: in many cases the blocks themselves also need proper completion and consistency for the SEO report to be truly complete.

The fastest place for that is the glossary. It was built precisely to avoid having to open multiple guides just to understand a term such as Open Graph, Machine name, Advanced settings or SEO Report.

The backoffice is the overall management environment. The interface is the way that environment is visually organized. The Workspace is the central dashboard used as the daily entry point, with shortcuts, indicators and recent history.

It is useful to separate these levels because a structural product question is not solved in the same way as an operational question about the initial dashboard.

The most useful panels for daily work are usually Favorites, SEO Summary, Latest updated pages, Content scheduling and Search. They help you quickly see where recurring work, content review or urgent tasks exist.

For teams managing many pages or multiple languages, this quick reading avoids repetitive navigation and reduces time lost looking for the starting point.

Favorites work best for areas or pages used repeatedly. Latest updated pages help track recent activity, understand what changed and validate ongoing editorial or technical work.

Used together, they create a quick loop between frequent access and recent context, which is especially useful when several people are editing the same project.

Menus define the organization and navigable reading of the website. The navigation section helps position each page inside that structure, connecting hierarchy, page relationships and journey consistency.

When this distinction is unclear, teams often create pages with correct content but poor placement in the architecture, which hurts discovery and maintenance.

A new page should enter navigation when it already has a clear editorial purpose, a stable URL, a defined relationship with the rest of the content and real value for the end user. Test pages, temporary pages or content without a clear role should not be pushed too early into primary menus.

The practical rule is simple: if the page is still being 'figured out' internally, public navigation is rarely the right place for it.

Hierarchy affects both the user reading experience and internal management. A well-designed structure helps teams find pages, understand dependencies and avoid duplication or orphan content.

As the architecture grows, poorly resolved navigation stops being only a visual problem and becomes an operational one, because it makes search, review and consistency harder.

This is where the form's overall behavior is defined: internal identification, feedback messages, submission rules, automatic notifications and the parameters that influence the user experience after submission.

In practice, this layer is not a minor technical detail. It affects history reading, notification consistency and even the way data will be consumed later.

Because internal names influence exports, reporting, readability for non-technical teams and future maintenance. If a form grows without a naming convention, exported columns quickly become opaque and hard to interpret.

This is especially important when there are multiple forms, external integrations or a need to share data with sales, marketing or support teams.

Submissions live in the submitted forms area, which works as a centralized history. Its value depends directly on the quality of the form architecture, the internal naming and the fields chosen for table reading and export.

If the setup was done without criteria, the history still exists but stops being operational: it exports poorly, reads poorly and requires too much manual interpretation.

Notifications are built from reusable templates. First the technical template structure is defined, such as name, machine name and language; then the content is completed with subject, body and the required variables.

This avoids duplication between similar forms, makes maintenance easier and helps keep consistency across teams and languages.

The admin notification is for internal triage and action. The user notification is for confirmation, transparency and continuity of the experience after submission.

Not every form needs both, but on critical forms the absence of one of them usually creates friction: either the team does not react in time, or the user is left without a clear confirmation.

Before increasing complexity, it is worth defining the structure, validation, naming, hidden fields, table columns, success messages, notification templates and the way data will be consumed.

The common mistake is to design the 'visible' form first and only then think about operational reading. In Studio, the invisible part is often what decides whether the form will be sustainable.

The best practices revolve around clarity, reading rhythm, consistent titles, blocks suited to the content and a structure that helps the user quickly understand what they are reading.

In Studio, good content is not just about 'writing well'. It is also about choosing the right composition, avoiding redundancy and aligning visible content with SEO, Open Graph and page architecture.

The main criterion should be content intention, not visual variety. A block only makes sense if it helps communication, not just because it exists in the library.

On longer pages, repeating a coherent block system usually works better than mixing too many formats without editorial logic.

Replicating a language version helps with speed, but it should not replace editorial review. Each language version needs its own review of titles, metadata, Open Graph, messages and the nuances of the main content.

Multilingual consistency does not mean literal copying. It means preserving intent, clarity and quality in each language.

The most direct path is the SEO Report. That is where Studio CMS shows the overall percentage for Meta, Open Graph and Blocks, together with the page table and status by row.

When a page appears with issues in Meta, Open Graph or blocks, it should usually be treated as a priority before moving on to finer work.

Metadata mainly serves search engines, especially the meta title and meta description. Open Graph controls how the page looks when shared on social networks. H1, H2 and H3 organize the visible content structure inside the page itself.

A page becomes stronger when these three layers are aligned and do not contradict each other.

The best flow is usually: first adjust the page structure and titles, then write the metadata, then prepare Open Graph and finally review images, ALT, TITLE and formats.

This avoids optimizing one layer in isolation while the rest of the content remains misaligned.

Meta shows the status of the meta title and description. Open Graph shows whether the social sharing layer is configured. Blocks summarizes whether the blocks used on that page also have their SEO filled in.

When one of these indicators fails, the page may look 'almost ready' while still being incomplete from an optimization point of view.

Redirects should be used when a URL changes, when a page no longer exists but has a new equivalent, or when traffic, backlinks and navigation consistency need to be preserved.

If structural website changes happen without redirects, it is easy to create unnecessary 404s and lose accumulated organic value.

Yes. Each language should be treated as its own editorial layer, with a meta title, description, Open Graph and structure adjusted to that language version.

Replicating content without reviewing SEO by language often creates vague, inconsistent or unnatural messaging for the end user.

Because SEO is not only about organic visibility. It also helps structure content better, clarify the purpose of each page and make the website easier to read for search engines and people.

In the Studio context, strong SEO discipline improves the editorial quality of the whole project, not just rankings.

Google Analytics measures traffic and behavior. Google Tag Manager helps manage scripts and events more flexibly. Search Console focuses on organic presence, indexation and how Google reads the website.

The three tools do not replace one another: each covers a different area of the project.

Yes. First the account is created and the correct IDs or scripts are obtained, and only then should installation happen in Studio CMS.

This avoids implementation errors and ensures the inserted code belongs to the right project.

After installation, the best approach is to confirm in the Google environment itself that data is starting to arrive, and cross-check that with inspection of the code or container inserted in Studio.

If there is doubt, it is best to review the source account first, then the script or container used, and only then the exact location where it was placed in the backoffice.

It makes sense when the website needs to reinforce brand identity, support content sharing and keep consistency between pages and official profiles.

This becomes especially strong when social media configuration is paired with well-resolved Open Graph settings.

It depends on the chosen protocol. In the most common scenario, you need SMTP data or, in the case of Microsoft 365, the integration elements associated with Azure and the organization's tenant.

Before moving forward, it is important to know which provider will be used and who has access to the required credentials or permissions.

Use SMTP when the sending infrastructure is already centered around host, port, user and password. Use Microsoft 365 when the organization wants email delivery to integrate with the Microsoft ecosystem and its authentication flow.

In practice, the decision usually depends on the active provider and the team's level of technical governance.

The goal is to reduce file weight without compromising visual quality too much, improving loading, performance and browsing experience.

It does not replace naming, ALT or TITLE, but it complements the website's visual optimization layer well.

The file name should be descriptive. ALT should explain the image for context and accessibility. TITLE can help as contextual reinforcement, but it usually has less direct weight than ALT.

Avoid generic names and artificial descriptions used only to 'stuff keywords'.

Not exactly. Content images respond more to the editorial reading of the page, while Open Graph images are designed for preview in shares.

Ideally there should be visual consistency between both, but without assuming they serve the same purpose.

Louro.AI is the AI support layer inside the Studio ecosystem, used to accelerate tasks such as text generation, editorial support, translation or content assistance.

It makes most sense when the team needs to speed up production without giving up human review and editorial judgment.

No. AI helps speed up and unblock tasks, but the final control of coherence, brand, technical accuracy and contextual fit should remain human.

The more sensitive the content is, the more important that final review becomes.