How to Create Pillar Pages That Rank: A Practical Structure and Strategy Guide
A pillar page should do more than collect links to related posts. Use it to answer the core topic well, organize supporting coverage, and make the next reader decision obvious.
What is How to Create Pillar Pages That Rank?
A pillar page is a central resource that answers a broad topic while linking to supporting pages for deeper subtopics. In 2026, the page should provide substantive standalone value rather than acting as a thin index.
The source page's earlier planning examples note that pages under 1,500 words may struggle when they rely entirely on links for depth, but word count is not a documented Google threshold. A strong hub uses clear sections, accurate internal links, useful original analysis, and structured data only where it matches visible content.
The aim is to satisfy the broad intent and make the next useful step obvious, not to chase a top-10 outcome through a fixed template.
Key Takeaways
- Treat the pillar as a useful hub with enough standalone depth to satisfy the broad intent, not as an oversized index.
- Choose the topic by mapping the reader journey and supporting demand, then use intent velocity as a planning lens rather than chasing a single head term.
- Sequence supporting content so the hub launches into an existing body of relevant coverage instead of an empty cluster.
- For optimizing for AI Overviews, write clear section openings and supporting detail that can stand on its own in 2026.
- Use internal linking to show real conceptual relationships between the hub and its supporting pages.
- Audit an existing pillar before expanding it: check intent coverage, missing concepts, weak sections, internal links, and update needs.
- Your H2 structure should move from the broad decision to the details a reader needs next, with a clear hierarchy supporting a coherent topic path.
- Write sections that remain useful even when a search feature summarizes the basic answer, then give readers a reason to continue into examples, tradeoffs, and process.
- Use consistent names for concepts and explain their relationships in context so readers and machines can interpret the page coherently.
- Use a 30-day build sequence to move from topic selection through cluster preparation, drafting, linking, launch, and the first maintenance checkpoint.
Introduction
A pillar page succeeds when it is both a strong answer and a strong organizer. It should help a reader understand the broad topic, choose what to do next, and reach deeper pages when a subtopic deserves its own treatment.
That sounds simple, yet many pillar pages are planned as publishing artifacts rather than as part of a larger information system.
The common failure pattern is easy to recognize. A team chooses a broad keyword, writes a long guide, adds a table of contents, inserts a handful of internal links, and calls the page a hub. The page may look comprehensive, but its sections often repeat generic advice, its links feel bolted on, and its supporting content does not clearly extend the reader journey. The issue is not formatting. It is scope, sequencing, and editorial logic.
A better process starts before drafting. Define the exact topic the hub should own, map the questions and decisions that belong on the hub, separate those from subjects that need dedicated supporting pages, and make sure the cluster has enough useful material to justify a central page.
Then write the pillar so it stands on its own while naturally handing off deeper questions to the right supporting content.
This guide turns that process into practical decisions you can apply to a new or existing content architecture. It covers topic selection, section design, supporting content, internal links, AI-readable answer blocks, pre-publication review, launch sequencing, and maintenance.
The goal is not to manufacture authority with a page template. The goal is to publish a genuinely useful hub that earns its place in the site architecture and can improve as the topic and the surrounding cluster evolve.
What Most Guides Get Wrong
The familiar playbook is to choose a broad keyword, produce 3,000 words or more, link to related posts, and wait for the page to become the center of the topic. That approach reflects a 2019 version of pillar-page strategy more than the practical demands of 2026.
A long page can still be useful, but length is not a substitute for a clear scope, strong information architecture, or evidence that each section answers a real reader need.
Another mistake is assuming the pillar should be created before the supporting cluster. A hub with almost nothing meaningful to link to cannot demonstrate much structure. Supporting pages do not need to be complete forever before the pillar launches, but enough of the cluster should exist to make the hub useful on publication day.
The final mistake is optimizing the page around one head query and treating everything else as a variation. Broad topics usually contain several distinct questions and decision states. A better pillar separates the questions that belong on the hub from the questions that need dedicated depth elsewhere, then connects them with editorially sensible links. The result is a page designed around reader progress rather than a word-count target.
What Should a Pillar Page Do in 2026?
A pillar page is the central resource for a defined topic within a site's content architecture. It should answer the broad intent well enough to be useful on its own, explain the main concepts a reader needs, and point to supporting pages when a narrower question deserves dedicated treatment.
In 2026, that means the hub should function as both a substantive guide and a navigation layer, not merely as a directory.
A long page is not automatically a pillar. A 5,000-word article can still be a poor hub if its scope is vague, its sections overlap, or its internal links do not correspond to meaningful subtopics. The page needs a deliberate relationship with the rest of the cluster.
The first requirement is layered intent. A broad topic often attracts readers who need an overview, readers comparing approaches, and readers trying to act. The hub should make those states easy to recognize and move through without turning every possible subtopic into a full-length section.
The second requirement is concept clarity. Name the important entities, processes, tools, and decisions that belong to the topic, then explain how they relate. Avoid treating keyword repetition as topical coverage. A clear explanation of relationships is more useful to the reader than a dense list of semantically related terms.
The third requirement is extractable structure. In 2026, each H2 can open with a concise direct answer, followed by 2 or 3 paragraphs of detail, examples, limitations, or next steps. That structure works well for readers who scan and for Google AI features that may quote or summarize a section, without assuming special markup or guaranteed visibility.
The fourth requirement is cluster support. A pillar should connect to useful supporting pages that actually extend the topic. In 2026, the best reason to add a supporting page is not simply that a keyword exists. It is that the subtopic needs more depth than the hub can provide without becoming repetitive or unwieldy.
Key Points
- A pillar page must answer the broad intent and organize deeper coverage at the same time.
- Concept clarity comes from explaining relationships among important ideas, not from repeating keywords.
- Clear section openings make the page easier to scan, summarize, and revisit.
- Supporting pages should extend the topic where dedicated depth is genuinely useful.
- The hub should remain valuable even if a reader never clicks into every supporting page.
💡 Pro Tip
Before drafting, list the 8-12 concepts that a reader must understand to make sense of the topic. Use that list to decide what belongs on the hub, what needs a supporting page, and what does not belong in the cluster at all.
⚠️ Common Mistake
Publishing the hub before the cluster has any substance. Have at least 3-4 useful supporting pieces ready or near-ready so the pillar can link to real depth from the start.
Build the Structure Around Reader Decisions, Not a Generic Long-Form Template
A good pillar outline is a sequence of reader decisions. Phase 1 is to define the broad question before drafting. The structure should answer the broad question, establish the vocabulary needed for the topic, explain the operating process, address tradeoffs, and show where specialized supporting pages take over. The important part is not following a branded acronym. It is making sure every section has a distinct job.
Start with a definition that reflects how the topic is used in practice. Then explain the context a reader needs to evaluate the subject responsibly. If there are established limitations or competing approaches, surface them instead of postponing them until the conclusion.
Next, move into process. Operational guidance is usually where the hub earns its usefulness. Each process section should tell the reader what decision to make, what information to gather, what to avoid, and when a deeper supporting page is the better next step.
A strong pillar also includes a diagnostic layer. Readers should be able to tell whether their current approach is sound, incomplete, or in need of revision. This makes the page useful beyond the first read and gives you natural reasons to link to focused tutorials or glossaries.
Finally, show how the topic connects to the surrounding architecture. A hub should not hide its role as a central page. Use natural contextual links when a concept is introduced, then provide a curated next-step path near the end for readers who want more depth.
A structure planned this way is easier to maintain because sections have clear responsibilities. When the topic evolves in 2026, you can update the affected area without rebuilding the entire page. That maintenance discipline matters just as much in 2026 as the initial outline.
Key Points
- Give each section a distinct purpose in the reader journey.
- Include limitations and tradeoffs where they matter instead of presenting one method as universally correct.
- Use process sections to turn the page from an overview into an actionable resource.
- Add diagnostic guidance so readers can evaluate their current approach.
- End with a curated path into supporting content rather than a generic related-posts list.
💡 Pro Tip
If two adjacent sections could be swapped without changing the reader's understanding, the outline probably lacks a strong progression. Reorder the page so each section answers the question created by the section before it.
⚠️ Common Mistake
Treating the outline as finished once the headings look comprehensive. Re-read it as a user journey and ask whether a reader who has worked in the topic for more than 12 months would still learn something useful from the sequence.
How to Build the Supporting Cluster Before the Hub Depends on It
A pillar works best when it sits inside a real body of supporting coverage. The practical question is not whether the cluster or the hub comes first in absolute terms. It is whether the hub has enough surrounding content to support meaningful navigation and enough scope discipline to avoid duplicating those pages.
Step 1 - Map the reader journey. List the broad informational questions, the comparison questions, the evaluation questions, and the action-oriented questions that naturally surround the pillar topic. Do not force every query into the cluster. Keep only the subjects that belong to the same conceptual area.
Step 2 - Separate hub coverage from supporting-page coverage. The pillar should explain the concept and the decision, while a supporting page handles the extended procedure, deep comparison, glossary definition, or specialized scenario.
Step 3 - Publish useful supporting pages early. Choose the pages that clarify the biggest conceptual gaps in the hub. They do not need to be the easiest keywords. They need to make the central resource more complete.
Step 4 - Link in both directions where it is editorially natural. Supporting pages should reference the pillar when they rely on its broader context, and the pillar should point back to the supporting page at the moment a reader needs more depth.
Step 5 - Watch how the cluster behaves after launch. Search performance, on-site navigation patterns, and editorial gaps can reveal which supporting pages deserve refinement. Treat those observations as maintenance inputs, not as proof of a hidden ranking mechanism.
Key Points
- Map the surrounding reader journey before deciding which supporting pages belong in the cluster.
- Use supporting pages for depth that would make the pillar repetitive or unwieldy.
- Publish enough cluster content to make the hub useful when it goes live.
- Link in both directions only where the conceptual relationship is real and useful.
- Use post-launch observations to refine the cluster rather than treating a static content map as final.
💡 Pro Tip
A strong supporting page often answers a question that readers naturally ask after a pillar section. When you can write the internal link as a genuine next sentence in the reader's thought process, the page is probably well placed in the cluster.
⚠️ Common Mistake
Creating supporting pages only because a keyword tool grouped them together. Semantic similarity is a starting clue, not proof that the pages belong in the same reader journey.
Choose a Pillar Topic by Scope and Search Demand, Not Volume Alone
Keyword volume can help estimate demand, but it should not decide pillar scope by itself in 2026. A viable pillar topic needs enough breadth to support a useful hub, enough distinct subtopics to justify supporting pages, and a clear relationship to the site's broader expertise.
A practical planning lens is to look at how much the topic expands into distinct reader questions. Start by searching the broad topic and reviewing the visible questions and related results. If the topic creates about 20 genuinely different questions, you likely have enough depth to map a cluster. If it produces only 3 or 4 narrow variants, a dedicated article may be more appropriate than a pillar.
Next, inspect result-format diversity. A topic that produces articles, videos, comparison pages, image results, or Google AI features may contain multiple ways users seek information. Treat that as an observation about intent diversity, not as a guaranteed ranking opportunity.
Then look at adjacent demand. If related subtopics are active and distinct, the hub has room to expand over time. If every supporting idea collapses into the same answer, the topic is probably too narrow for a durable content architecture.
Finally, choose a small set of related terms that help you validate coverage. A useful planning set might include 4-8 secondary terms that describe important concepts or subtopics. Do not force them into the copy. Use them to check whether the outline naturally covers the subject a reader expects.
The goal is a topic with a defensible scope. A good pillar is broad enough to organize a meaningful cluster and narrow enough to deliver a coherent answer without becoming a general encyclopedia.
Key Points
- Use search demand to validate scope, not to dictate the outline.
- A healthy pillar topic expands into several genuinely different reader questions.
- Result-format diversity can reveal multiple intent modes, but it is not a ranking guarantee.
- Adjacent subtopics should deepen the same subject rather than create an unrelated content warehouse.
- Use secondary terms as a coverage check, not as mandatory insertions.
- A pillar topic should be broad enough to support growth but narrow enough to remain coherent.
💡 Pro Tip
Spend 20 minutes mapping the topic before committing. If you can identify at least 15 distinct questions within 20 minutes and still see clear gaps between them, the subject may support a hub. If you struggle to reach 10 without rephrasing the same idea, consider a narrower page type.
⚠️ Common Mistake
Choosing a pillar because a keyword tool shows an attractive difficulty score. A score of 20 does not make a flat topic strategically stronger than a score of 35 on a subject that clearly supports deeper coverage and reader progression.
Write Pillar Sections That Work for Readers and Google AI Features
Google AI Overviews and other Google AI features can summarize information from pages, but there is no special pillar-page markup that guarantees inclusion. In 2026, the practical response is to make each section easy to understand on its own while preserving the depth that gives readers a reason to continue.
Start with direct section openings. A useful H2 section can begin with a concise answer to the implied question, followed by 2 or 3 paragraphs that explain the reasoning, examples, limitations, or process. This helps scanning and makes the section easier to interpret without turning the page into a collection of isolated snippets.
Use consistent names for important concepts. If the same idea is called several different things without explanation, readers can lose track of what is changing and what is merely a synonym. Use natural variations in prose, but keep the core terminology stable.
Use structured data only when it accurately describes content already visible on the page and is supported for the intended use. Do not add markup merely because a page is a pillar, and do not assume markup creates eligibility for a special AI treatment.
Design deeper material beneath the direct answer. The concise opening handles orientation. The paragraphs that follow should contain the details a summary cannot replace: implementation choices, tradeoffs, examples, exceptions, and links to dedicated supporting pages.
Finally, make the next action obvious. A reader who understands the broad answer may still need a checklist, comparison, technical tutorial, or definition. Those are natural places for internal links when the supporting page genuinely extends the task.
Key Points
- A strong H2 opening can be concise, followed by 2 or 3 paragraphs of useful depth.
- Consistent terminology helps readers and machines follow the relationships among concepts.
- Structured data should match visible content and documented use cases, not be added as an AI shortcut.
- Use the material below the direct answer for the depth a search summary cannot replace.
- Give readers a clear next action when a specialized supporting page is the logical continuation.
💡 Pro Tip
Review each H2 and read the opening answer beneath it. If that opening does not answer the heading clearly, rewrite it before adding more depth. If the next 2 or 3 paragraphs merely repeat the opening, replace repetition with examples, limits, or implementation detail.
⚠️ Common Mistake
Writing dense sections with no clear answer near the top, then assuming length alone makes them authoritative. Good structure should help a reader understand the point before they commit to the details.
Use Internal Links to Explain the Topic Architecture
Internal links should help readers move from the hub to the right depth and back again. In 2026, the most useful linking pattern is editorial: link because the destination answers the next logical question, not because a template requires a fixed number of links.
The pillar should receive links from supporting pages when those pages rely on the broader topic context. This reinforces the reader's ability to move back to the overview and keeps the cluster understandable.
The pillar should also link outward in context. When a section introduces a subtopic that deserves dedicated treatment, link at the point of need. A footer block can still be helpful as a recap, but it should not be the only place cluster pages are discoverable.
Supporting pages can link laterally to each other when one topic is a real prerequisite or next step for another. Avoid building a complete mesh where every page links to every other page. That creates clutter without improving the information architecture.
Anchor text should describe the destination accurately and naturally. Exact repetition across the cluster is unnecessary. Readers benefit when the anchor tells them what they will find on the next page.
As the cluster grows, revisit the hub. Add new links only when the new content improves the reader journey, and remove links when the destination no longer matches the context. Treat internal linking as part of editorial maintenance rather than a one-time optimization pass.
Key Points
- Internal links should explain real conceptual relationships and reader next steps.
- Supporting pages can link back to the pillar when the broad context is useful.
- Place important hub-to-cluster links in the body where the deeper question first appears.
- Use lateral links selectively instead of connecting every cluster page to every other page.
- Review the hub's links as the cluster changes so the architecture stays accurate.
💡 Pro Tip
Draw the cluster as a simple map and inspect it from a reader's perspective. A useful map makes the central topic, the deeper subtopics, and the next-step paths obvious without requiring a fixed linking formula.
⚠️ Common Mistake
Using a rotation of 5-7 anchor variants only to manufacture diversity. Write descriptive anchors for the actual sentence instead. Natural variation should come from context, not from a quota.
Audit the Pillar Before Publication With a Practical Readiness Check
A pre-publication review is cheaper than diagnosing an underperforming hub after launch. Use a simple readiness check to identify gaps in scope, supporting content, structure, and maintenance before the page becomes a permanent part of the site architecture. Score each dimension from 1 to 5, where 1 is absent and 5 is fully addressed.
Dimension 1 - Intent coverage. Check whether the page clearly handles the broad informational need, the evaluation questions, and the action-oriented next steps. A score of 5 means the major reader states are intentionally represented.
Dimension 2 - Concept coverage. Compare the draft with the 8-12 core concepts you identified during planning. A score of 5 means the important concepts are explained in context rather than merely mentioned.
Dimension 3 - Section clarity. Review each H2. A score of 5 means the opening directly answers the heading and the rest of the section adds useful depth rather than repetition.
Dimension 4 - Cluster readiness. Check whether the supporting pages needed by the hub are live or ready. A score of 5 means at least 6 supporting pages are available and the hub can link to them naturally.
Dimension 5 - Distinctive usefulness. Ask whether the page adds a point of view, diagnostic insight, example, or operating guidance that readers would not get from a generic summary. A score of 5 means the page contains at least 2 clearly useful elements that are specific to the topic and the author's experience.
Dimension 6 - Internal link quality. A score of 5 means the page includes at least 8 contextual internal links where a supporting page genuinely extends the current section.
Dimension 7 - Structured data fit. A score of 5 means any structured data used is relevant, accurate, and validated against the visible page content. Do not add schema only to raise the score.
Dimension 8 - Maintenance readiness. A score of 5 means the team knows who owns updates, what changes should trigger a review, and how new supporting pages will be incorporated.
A total below 24 suggests the page still has important gaps. A total from 32-40 indicates stronger readiness across the review dimensions, but the score is an internal planning device, not a guarantee of search performance.
Key Points
- Review the page across all eight dimensions before publication so structural gaps are visible early.
- Intent coverage should include the broad need, evaluation questions, and practical next steps.
- If cluster readiness is below 3, consider strengthening the supporting content before treating the page as a mature hub.
- Distinctive usefulness can come from clear analysis, examples, diagnostics, or practical operating guidance.
- Structured data should be relevant and accurate; do not treat it as a scoring shortcut.
- A total below 24 is a reason to revisit the weakest dimensions, not a prediction of failure.
💡 Pro Tip
Run the same review against 3 strong competing resources to compare coverage and structure. Use the comparison to identify missing reader needs, not to copy their outline or assume a lower score proves an opportunity.
⚠️ Common Mistake
Treating the readiness check as permanent. Revisit the page every 6-9 months, or sooner when the topic changes materially, so outdated sections and missing supporting content do not accumulate.
Build, Launch, and Maintain the Pillar as an Ongoing Editorial Asset
Strategy only becomes useful when ownership and workflow are clear. A pillar page needs a build process, a launch sequence, and a maintenance routine that fits the team publishing it.
During the build, separate planning from drafting. First define the scope, reader journey, and supporting pages. Then write the sections that require genuine subject knowledge. Finally, run an editorial pass for headings, internal links, terminology, structured data where appropriate, and section clarity.
One person can handle all of these responsibilities, but treating them as separate passes reduces the chance that structural issues disappear inside line editing.
At launch, update supporting pages so their contextual links point to the live hub. Share the page through owned channels only where the audience is relevant. If you contact external publishers or creators, do so because the pillar contains something genuinely useful to their readers, not because publication itself creates an entitlement to a link.
Maintenance should focus on accuracy and usefulness. Review the page when the topic changes, when supporting content is added or consolidated, when internal links break, or when a section no longer reflects current practice.
A regular review can help operationalize this work, but there is no official posting cadence that guarantees ranking improvement.
Search performance may change over 4-6 months for many reasons, so do not treat that window as a promised maturation period. Use Search Console and analytics to see which queries, sections, and supporting pages are attracting attention, then combine that evidence with a qualitative content review. The goal is to make better editorial decisions, not to infer a hidden mechanism from timing alone.
Key Points
- Separate scope planning, subject-matter drafting, and editorial implementation into distinct passes.
- Launch by connecting the live hub to its supporting pages and relevant owned channels.
- Update the pillar when the topic or supporting cluster changes materially.
- Use performance data as one input to editorial decisions rather than as proof of a fixed ranking formula.
- A 4-6 month observation window can be useful for trend review, but it is not a guaranteed search timeline.
- The pillar should remain a living resource whose scope and links evolve with the surrounding content.
💡 Pro Tip
Keep a short maintenance brief for the hub. Record the owner, the last substantive review, the supporting pages that currently matter most, and the next known update trigger. A focused review can then take about 10 minutes when no major rewrite is needed.
⚠️ Common Mistake
Treating publication as the end of the project. A hub can become less useful as the cluster changes, even when the original copy remains accurate. Maintenance keeps the architecture coherent.
Your 30-Day Pillar Page Build Plan
Audit 3-5 candidate topics for scope, reader intent, and cluster potential. Choose a subject broad enough to support a hub but narrow enough to answer coherently.
Expected Outcome
A selected topic plus an initial map of 8-12 core concepts that belong in the hub or its supporting cluster.
Map 10-15 meaningful questions around the topic and sort them across 4-6 reader stages or use cases. Separate hub-level questions from subjects that need dedicated pages.
Expected Outcome
A content architecture that shows what the pillar owns and what supporting pages must handle in greater depth.
Draft and publish the first 3-4 supporting pieces that fill the most important depth gaps. Write each so it can stand alone and link back to the hub when the broader context is useful.
Expected Outcome
A live foundation of 3-4 supporting pages that the pillar can reference naturally at launch.
Draft the pillar around reader decisions, direct section openings, tradeoffs, process, diagnostics, and contextual handoffs. Use the pre-publication review and aim for a readiness score of 30 before launch.
Expected Outcome
A complete hub draft with clear scope, section responsibilities, and an internal link map.
Run technical and editorial QA. Confirm every H2 answers its implied question quickly, validate any structured data used, and review links in both directions between the hub and supporting content.
Expected Outcome
A publication-ready page with accurate links, clear section openers, and structured data only where it fits the visible content.
Update the existing supporting pages so their in-body links point to the live hub where the broader context is useful. Re-read the full cluster as a reader journey before scheduling publication.
Expected Outcome
A connected cluster in which the hub and supporting pages reinforce the same topic without unnecessary cross-linking.
Publish and distribute the pillar through relevant owned channels. Record the baseline, set a 90-day review point, and schedule a broader 6-month editorial check for scope, freshness, and internal links.
Expected Outcome
A live pillar with a documented maintenance owner, baseline observations, and clear triggers for future updates.
Frequently Asked Questions
How long should a pillar page be in 2026?
There is no required word count. Some useful hubs may fall around 2,500-4,500 words because that is enough space to answer a broad topic without swallowing every supporting subtopic. Others may be shorter or longer.
A focused 2,800-word page can be stronger than a repetitive 5,500-word page if its sections have clear jobs, its internal links lead to real depth, and the page itself satisfies the broad intent.
How much supporting content should exist before the pillar goes live?
The cluster should contain enough useful depth that the hub is not linking into an empty architecture. A practical starting point is 4 supporting pages, while a more developed cluster might contain 8-12 pages covering distinct subtopics. Treat those figures as planning examples, not thresholds that guarantee search performance.
Should I update or rebuild an underperforming pillar page?
Start with a structural audit. If the page scores below 20 on your internal readiness review, the scope and organization may need substantial work. If it falls around 20-28, targeted fixes to weak sections, supporting content, and internal links may preserve more useful material than a complete rewrite. Keep the URL stable when possible and protect any content that already serves a clear purpose.
What is the difference between a pillar page and a topic cluster landing page in 2026?
In 2026, a pillar page should provide substantive standalone value while also guiding readers into supporting content. A cluster landing page can be primarily navigational. If a navigational page is expected to satisfy broad search intent, expand it only when there is a genuine reader need for more explanation rather than assuming every index must become a long-form article.
How do I know whether the pillar is helping the cluster?
Look for a pattern across several inputs rather than one metric. Search Console may show impression changes before click changes, sometimes over 4-8 weeks, but timing varies and does not prove causation.
Also review which supporting pages readers use, whether internal links make sense, whether queries match the intended scope, and whether the hub is attracting natural citations or links from relevant sources.
Can a smaller site build a pillar that competes with established domains?
A smaller site can still publish the most useful resource for a narrowly defined topic, especially when the scope matches its real expertise and the supporting cluster is coherent. Instead of chasing broad terms by difficulty alone, look for subjects where current results leave clear reader needs unresolved.
A planning range such as KD 15-35 may help organize research in some tools, but third-party difficulty scores are not search-engine rules and should not be treated as guarantees.
You've read enough.Your own data says more.
Connect your site and see it yourself: your rankings, your gaps, your blockers, and what AI tells your buyers. The plan and the priced options follow within 36 hours.