How do you connect a solar project with Pronovo?

A solar project answers the broader user question: should I install, with which support logic, how do I prepare the file, and what trade-offs do I make between self-consumption, storage, grid injection and local complements? Pronovo answers a narrower question: how does the federal one-off remuneration work, who can claim it, when should the file be submitted, and how do I avoid a refusal? The two layers complement each other, but they do not replace each other.

In practice, this distinction matters because a solar project is a decision path, while Pronovo is a programme path. The solar page helps the reader frame the investment: technical scope, business logic, local incentives, and sequencing with the wider project. Pronovo only becomes central once the question is about the federal support mechanism itself.

That is also why the solar page should not be rewritten as if Pronovo were the whole subject. Officially, Pronovo exists to administer the federal remuneration scheme. But the project still has to answer many other questions before and around that step: roof suitability, target production, storage strategy, possible local support, and how the network announcement fits into the sequence.

If Pronovo becomes the implied parent of the solar topic, everything else disappears: cantonal support, supplier bonuses, battery cases, the order with network notification, and collective or local logic. Yet a photovoltaic project still exists even when Pronovo is not the first question to settle. Keeping the solar parent as the main page therefore protects the coherence of the journey and lets the Pronovo cluster keep its role as the official programme layer.

This is not just a structural preference. It is a way to preserve the reader’s decision order. A user usually starts with the project itself: what is being installed, why now, and what strategic choices matter first. Only after that does the federal remuneration layer become the right place to drill down. If Pronovo sits too high in the hierarchy, the content starts from administration instead of from the project.

From a semantic point of view, the two entities also serve different purposes. The solar project page needs to support qualification: is the project viable, what support layers exist, and which factors influence the design? Pronovo supports eligibility and filing logic. If those roles are merged, the article loses depth and the same content gets duplicated across two pages.

The solar page keeps the questions that belong to project strategy. Pronovo takes the questions that belong to the federal framework and the remuneration mechanism. This boundary prevents the same explanation from being rewritten under two different URLs and helps the user know where each decision belongs.

As a rule, the solar page should hold questions that change the project design: technical choices, self-consumption, storage, local incentives, and the order of actions. Pronovo should hold questions that depend on the official federal regime: who is eligible, how the remuneration is calculated in principle, what the filing logic is, and how to stay within the programme’s administrative rules.

That split is especially important for SEO and navigation. If the solar page answers Pronovo questions in too much detail, it risks becoming a second Pronovo page. If Pronovo tries to explain every project scenario, it turns into a generic solar guide. A clean boundary preserves both relevance and usefulness.

The right internal linking pattern starts from the solar project page and only branches to Pronovo when the question becomes programme, calculation, documents or federal timing. The opposite mistake is to funnel every solar topic through Pronovo, which turns a technical and economic decision into a simple administrative portal question. The content should move from project frame to programme frame, not the other way around.

A good reading path follows the user’s decision order. First comes the project overview, then the support landscape, then the Pronovo layer, then the local or federal details that belong to the filing. That means each page should answer one layer deeply enough to move the reader forward, but not so much that it steals the function of the next page.

Use links as transitions, not as repetitions. The solar page can introduce Pronovo briefly as the federal remuneration layer and then send the reader to the dedicated Pronovo page. The Pronovo page, in turn, can point back to the solar project page when the user still needs to understand the broader project logic. This two-way but asymmetric linking keeps both pages honest: one frames the project, the other formalises the programme.

For example, the solar project page can point to:

• Solar photovoltaic project overview
• What support is available for solar photovoltaics?
• How to estimate the Pronovo one-off remuneration
• What documents to prepare for a subsidised solar project

Those links should not feel like a list of related articles. They should reflect the actual path a user takes: from the project itself, to the support architecture, to Pronovo only when the official programme becomes the relevant layer.

For a real user, the most useful sequence is simple: frame the solar project, understand the support layers, position Pronovo, verify the local logic, and only then organise the steps for the file. That preserves the hierarchy between measure, programme and execution. It also reduces confusion when the same project has both technical and administrative decisions.

A practical reading path looks like this:

• Start with the main Solar photovoltaic project page
• Read the guide on available support for solar photovoltaics
• Move to this guide to understand how Pronovo fits into the project
• Open the relevant Pronovo guide if the question becomes calculation, eligibility or filing
• Finish with the process page on documents to prepare for a subsidised solar project

That order matters because it prevents premature narrowing. If the reader starts with Pronovo, they may think the project is only about the federal remuneration. If they start with the project, they can first understand what they are building, then decide which programme layer actually applies.

• Pronovo
• SwissEnergy
• cantonal energy services