Skip to content

feat(seo): Improve Internal Linking #426

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
0xIchigo wants to merge 2 commits into
base: main
Choose a base branch
from
Open

feat(seo): Improve Internal Linking #426

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f28309a
Improve Internal Linking
0xIchigo Feb 3, 2026
6f7d1b1
Fix Get Asset Link
0xIchigo Feb 3, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions dedicated-nodes.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,9 +34,9 @@ description: "Dedicated Solana nodes optimized for gRPC streaming applications.
<Note>
Copy link
Contributor

@brady-at-helius brady-at-helius Feb 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you remove the ? Better that this information is just normal paragraph text / bullets instead of being wrapped in the . We do this a lot with where we shove multiple bullets or long paragraphs in notes, but they should just be clearly written header/paragraph sections. If we abuse the markup it loses it's urgency/meaning imo

**Important**: Dedicated nodes have specific limitations and are not suitable as standalone solutions:

- **`sendTransaction` Poor Landing Rates**: While supported, not optimized - most transactions will not land
- **[`sendTransaction`](/api-reference/rpc/http/sendtransaction) Poor Landing Rates**: While supported, not optimized - most transactions will not land
- **No Archival Data**: Historical data access is not available
- **`getProgramAccounts` Performance Risk**: While supported, heavy usage can impact node performance or cause node failure
- **[`getProgramAccounts`](/api-reference/rpc/http/getprogramaccounts) Performance Risk**: While supported, heavy usage can impact node performance or cause node failure
- **No Platform Features**: APIs, webhooks, and staked connections require a shared plan

**Recommendation**: Use dedicated nodes for gRPC streaming in combination with a shared paid plan for comprehensive functionality.
Expand Down
10 changes: 5 additions & 5 deletions dedicated-nodes/best-practices.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,18 +18,18 @@ description: "Optimize your Solana dedicated node performance with best practice

While nodes don't have strict usage limits, they are bound by hardware constraints. A balanced workload helps maintain optimal performance and node liveliness.

* **Use `getProgramAccounts` carefully**: While supported, dedicated nodes are not optimized for these calls - heavy usage can impact performance or cause node failure
* Use your shared plan for `getProgramAccounts` queries as we have a [**custom indexer**](https://x.com/heliuslabs/status/1864750969755422797) that makes those calls much faster and more reliable
* **Poor transaction landing rates**: While `sendTransaction` is supported, it's not optimized - most transactions will not land; use your shared plan for reliable transaction submission
* **Use [`getProgramAccounts`](/api-reference/rpc/http/getprogramaccounts) carefully**: While supported, dedicated nodes are not optimized for these calls - heavy usage can impact performance or cause node failure
* Use your shared plan for [`getProgramAccounts`](/api-reference/rpc/http/getprogramaccounts) queries as we have a [**custom indexer**](https://x.com/heliuslabs/status/1864750969755422797) that makes those calls much faster and more reliable
Copy link
Contributor

@brady-at-helius brady-at-helius Feb 6, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typically it's best not to include the same link multiple times. better to include it once in the most relevant section. imo, better to remove this link to gPA and mention gPAV2 instead:

  • Use your shared plan for getProgramAccounts queries as we have a custom indexer that makes gPA calls much faster and more reliable.
  • Shared plans also support getProgramAccountsV2, which adds support for pagination and incremental updates.

* **Poor transaction landing rates**: While [`sendTransaction`](/api-reference/rpc/http/sendtransaction) is supported, it's not optimized - most transactions will not land; use your shared plan for reliable transaction submission
Copy link
Contributor

@brady-at-helius brady-at-helius Feb 6, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change to:

"...shared plan or Sender for landing Solana transactions more reliably"

* **No archival queries**: Historical data access should be done through your shared plan
Copy link
Contributor

@brady-at-helius brady-at-helius Feb 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

link "Historical data" to https://www.helius.dev/docs/rpc/historical-data

* Monitor your node's metrics to understand its performance based on response times, successful request %, and error counts
* Consider distributing intensive workloads across multiple nodes in a dedicated fleet

<Warning>
Copy link
Contributor

@brady-at-helius brady-at-helius Feb 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole warning section is pretty duplicative of the bullets in the managing load section. Recommend removing it to keep the page simpler.

If you want to keep the "No platform APIs, webhooks, or staked connections" stuff, it might be better served with a new "What's Not Supported" header where we include them in simple bullet list

Then you'd wanna move the historical data bullet from the load section here since it's unsupported, and not a load management thing

**Remember**: Dedicated nodes limitations:
- `sendTransaction` supported but not optimized - most transactions will not land
- [`sendTransaction`](/api-reference/rpc/http/sendtransaction) supported but not optimized with staked connections - most transactions will not land as effectively compared to [Sender](/sending-transactions/sender)
- No archival data access
- `getProgramAccounts` supported but not optimized - heavy usage can impact performance or cause node failure
- [`getProgramAccounts`](/api-reference/rpc/http/getprogramaccounts) supported but not optimized - heavy usage can impact performance or cause node failure
- No platform APIs, webhooks, or staked connections

Use your shared paid plan for these features.
Expand Down
8 changes: 4 additions & 4 deletions dedicated-nodes/getting-started.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ The type of node you choose depends on your requirements. Since we don't impose
**For gRPC streaming applications** (primary use case), any node type will perform well.

<Warning>
**Important**: While `getProgramAccounts` is supported, dedicated nodes are not optimized for these calls. Heavy usage can impact node performance or even cause node failure. Use your shared plan for `getProgramAccounts` queries as it has a custom indexer that makes these calls much faster and more reliable.
**Important**: While [`getProgramAccounts`](/api-reference/rpc/http/getprogramaccounts) is supported, dedicated nodes are not optimized for these calls. Heavy usage can impact node performance or even cause node failure. Use your shared plan for [`getProgramAccounts`](/api-reference/rpc/http/getprogramaccounts) queries as it has a custom indexer that makes these calls much faster and more reliable.
Copy link
Contributor

@brady-at-helius brady-at-helius Feb 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove the 2nd gpa link

</Warning>

<Frame caption="Choose your dedicated node's type and location">
Expand Down Expand Up @@ -134,9 +134,9 @@ ws.onmessage = (event) => {

<Warning>
**Remember**: The above RPC examples are for basic functionality only. Dedicated nodes limitations:
- `sendTransaction` supported but not optimized - most transactions will not land (use your shared plan for reliable transaction submission)
- No archival data queries (use your shared plan)
- `getProgramAccounts` supported but not optimized - heavy usage can impact performance or cause node failure (use your shared plan for reliability)
- [`sendTransaction`](/api-reference/rpc/http/sendtransaction) supported but not optimized - most transactions will not land (use your shared plan for reliable transaction submission)
- No archival data queries (use your shared plan)
- [`getProgramAccounts`](/api-reference/rpc/http/getprogramaccounts) supported but not optimized - heavy usage can impact performance or cause node failure (use your shared plan for reliability)

**Primary use case**: Use the gRPC streaming setup below for optimal performance.
</Warning>
Expand Down
4 changes: 2 additions & 2 deletions enhanced-websockets/transaction-subscribe.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -171,7 +171,7 @@ ws.on('close', function close() {
</Accordion>
</AccordionGroup>

### Monitoring new Jupiter DCAs using Transaction Subscribe + getAsset
### Monitoring new Jupiter DCAs using Transaction Subscribe + [getAsset](/api-reference/das/getasset)
Copy link
Contributor

@brady-at-helius brady-at-helius Feb 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

generally best to not link things in headers

instead it's better to include those links in the paragraph text underneath the header

my recommendation is to add a sentence or 2 to bridge between the header and the accordions like:

Jupiter DCA, or Dollar Cost Averaging, is a way to schedule recurring trades for tokens on Solana. Because these scheduled buy/sell orders are recorded on-chain, traders can use the transactionSubscribe method and the getAsset DAS API method to listen for new orders.


<AccordionGroup>
<Accordion title="Code Example">
Expand Down Expand Up @@ -199,7 +199,7 @@ function decodeOpenDcaV2(base58Data) {
const TOKEN_META = new Map(); // mint → { symbol, decimals }
/**
* Fetch symbol & decimals for a mint once then cache.
* Uses Helius getAsset DAS method.
* Uses Helius getAsset DAS method: https://docs.helius.dev/api-reference/das/getasset
*/
async function getMeta(mint) {
if (TOKEN_META.has(mint)) return TOKEN_META.get(mint);
Expand Down
2 changes: 1 addition & 1 deletion faqs/das-api.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@ Use the standard RPC method `getTokenLargestAccounts` with your token's mint add
</Accordion>

<Accordion title="How do I find all token holders of a specific mint?">
Use `getProgramAccounts` filtered by the token program and mint address, or `getTokenAccountsByOwner` for specific owners. For comprehensive token holder analysis, combine with `getTokenLargestAccounts`.
Use [`getProgramAccounts`](/api-reference/rpc/http/getprogramaccounts) filtered by the token program and mint address, or [`getTokenAccountsByOwner`](/api-reference/rpc/http/gettokenaccountsbyowner) for specific owners. For comprehensive token holder analysis, combine with [`getTokenLargestAccounts`](/api-reference/rpc/http/gettokenlargestaccounts).
Copy link
Contributor

@brady-at-helius brady-at-helius Feb 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a second paragraph:

Alternatively, you can use the getProgramAccountsV2 and getTokenAccountsByOwnerV2 method for improved pagination support and support for incremental updates with the changedSinceSlot parameter.

</Accordion>

<Accordion title="How do I get the market capitalization of a token?">
Expand Down
29 changes: 26 additions & 3 deletions rpc/how-to-index-solana-data.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -69,9 +69,9 @@ The first step to building a Solana index is getting all the historical data tha

There are three main ways to do this:
Copy link
Contributor

@brady-at-helius brady-at-helius Feb 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we already include these links in their dedicated sections below, we don't need to link them here. Duplicate links hurt instead of help, and it's always best to include links in their most contextually relevant section. So if the section details using the gTFA method, that's the best section to include a link to the gTFA reference.


1. **getTransactionsForAddress** (recommended)
2. **getSignaturesForAddress** and **getTransaction**
3. **getBlock**
1. [**getTransactionsForAddress**](/rpc/gettransactionsforaddress) (recommended)
2. [**getSignaturesForAddress**](/api-reference/rpc/http/getsignaturesforaddress) and [**getTransaction**](/api-reference/rpc/http/gettransaction)
3. [**getBlock**](/api-reference/rpc/http/getblock)

### Method 1: getTransactionsForAddress (recommended)

Expand Down Expand Up @@ -388,6 +388,29 @@ To update an index that stores all token transfers, you would subscribe to [`tra
}
```

## Related Methods
Copy link
Contributor

@brady-at-helius brady-at-helius Feb 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This section feels a bit unneccessary since we link to all of these methods in their sections above. would recommend removing it, or replacing the /api-reference/ links with their respective "guides" but even that feels like overkill for an already long/detailed guide like this


<CardGroup cols={2}>
<Card title="getTransactionsForAddress" href="/api-reference/rpc/http/gettransactionsforaddress">
Fetch full transaction history for an address with filtering (recommended)
</Card>
<Card title="getSignaturesForAddress" href="/api-reference/rpc/http/getsignaturesforaddress">
Get transaction signatures for an address
</Card>
<Card title="getTransaction" href="/api-reference/rpc/http/gettransaction">
Retrieve full transaction details by signature
</Card>
<Card title="getBlock" href="/api-reference/rpc/http/getblock">
Fetch all transactions in a specific block
</Card>
<Card title="getTokenAccountsByOwner" href="/api-reference/rpc/http/gettokenaccountsbyowner">
Get all token accounts owned by a wallet
</Card>
<Card title="getTokenAccountBalance" href="/api-reference/rpc/http/gettokenaccountbalance">
Get the token balance for a specific account
</Card>
</CardGroup>

## Get started

Building a robust Solana index and backfilling data requires solving three core challenges:
Expand Down
34 changes: 34 additions & 0 deletions rpc/optimization-techniques.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -549,6 +549,40 @@ async function robustRPCCall<T>(operation: () => Promise<T>): Promise<T> {
- Not closing subscriptions, leading to memory leaks
</Warning>

## Related Methods

The optimization techniques in this guide reference the following WebSocket and RPC methods:

<CardGroup cols={2}>
<Card title="getSignaturesForAddress" href="/api-reference/rpc/http/getsignaturesforaddress">
Get transaction signatures for an address
</Card>
<Card title="getTransaction" href="/api-reference/rpc/http/gettransaction">
Retrieve full transaction details by signature
</Card>
<Card title="getProgramAccounts" href="/api-reference/rpc/http/getprogramaccounts">
Fetch all accounts owned by a program
</Card>
<Card title="getTokenAccountsByOwner" href="/api-reference/rpc/http/gettokenaccountsbyowner">
Get token accounts for a wallet
</Card>
<Card title="getMultipleAccountsInfo" href="/api-reference/rpc/http/getmultipleaccounts">
Batch fetch multiple account details
</Card>
<Card title="getAccountInfo" href="/api-reference/rpc/http/getaccountinfo">
Get information about a single account
</Card>
<Card title="accountSubscribe" href="/api-reference/rpc/websocket/accountsubscribe">
Subscribe to account changes via WebSocket
</Card>
<Card title="programSubscribe" href="/api-reference/rpc/websocket/programsubscribe">
Subscribe to program account changes via WebSocket
</Card>
<Card title="logsSubscribe" href="/api-reference/rpc/websocket/logssubscribe">
Subscribe to transaction logs via WebSocket
</Card>
</CardGroup>

## Summary

By implementing these optimization techniques, you can achieve:
Expand Down
26 changes: 23 additions & 3 deletions sending-transactions/send-manually.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -77,7 +77,7 @@ transaction.sign([fromKeypair]);

### 2. Optimize Compute Unit (CU) Usage

To avoid wasting fees or having your transaction fail, you should set the compute unit (CU) limit as precisely as possible. You can do this by simulating the transaction using the `simulateTransaction` RPC method.
To avoid wasting fees or having your transaction fail, you should set the compute unit (CU) limit as precisely as possible. You can do this by simulating the transaction using the [`simulateTransaction`](/api-reference/rpc/http/simulatetransaction) RPC method.

It's a best practice to first simulate with a high CU limit to ensure the simulation itself succeeds, and then use the `unitsConsumed` from the response to set your actual limit.

Expand Down Expand Up @@ -162,7 +162,7 @@ const setPriorityFeeInstruction = ComputeBudgetProgram.setComputeUnitPrice({
Now, assemble the final transaction with the new compute budget instructions, send it, and implement a robust polling mechanism to confirm it has landed.

<Warning>
Do not rely on the RPC provider's default retry logic (`maxRetries` in `sendTransaction`). While Helius's staked connections forward your transaction directly to the leader, it can still be dropped. You must implement your own rebroadcasting logic for reliable confirmation.
Do not rely on the RPC provider's default retry logic (`maxRetries` in [`sendTransaction`](/api-reference/rpc/http/sendtransaction)). While Helius's staked connections forward your transaction directly to the leader, it can still be dropped. You must implement your own rebroadcasting logic for reliable confirmation.
</Warning>

A common pattern is to re-send the same transaction periodically until the blockhash expires. **Only re-sign the transaction if you are also fetching a new blockhash.** Re-signing with the same blockhash can lead to duplicate transactions being confirmed.
Expand Down Expand Up @@ -214,4 +214,24 @@ while (!confirmed) {
await new Promise(resolve => setTimeout(resolve, 2000));
}
```
This example provides a basic polling loop. A production-grade application would require more sophisticated logic, including handling different confirmation statuses and potential timeouts.
This example provides a basic polling loop. A production-grade application would require more sophisticated logic, including handling different confirmation statuses and potential timeouts.

## Related Methods

<CardGroup cols={2}>
<Card title="sendTransaction" href="/api-reference/rpc/http/sendtransaction">
Send a signed transaction to the network
</Card>
<Card title="simulateTransaction" href="/api-reference/rpc/http/simulatetransaction">
Simulate a transaction to estimate compute units
</Card>
<Card title="getSignatureStatuses" href="/api-reference/rpc/http/getsignaturestatuses">
Check confirmation status of transactions
</Card>
<Card title="getLatestBlockhash" href="/api-reference/rpc/http/getlatestblockhash">
Get a recent blockhash for transaction signing
</Card>
<Card title="getBlockHeight" href="/api-reference/rpc/http/getblockheight">
Get current block height for expiry checks
</Card>
</CardGroup>