You have five pages, maybe eight. Every guide you open assumes you have five hundred. That gap is why internal linking feels like a problem for later, and later is exactly when it turns into a mess. Here is the good news: you get to build your site structure from scratch, which means you never have to untangle anything. This guide walks you through seven steps to set up an internal linking foundation on a small site, so structure grows with you instead of against you.
Most internal linking new site advice is written for people fixing an existing tangle. Yours is a different job. An established site discovers what it already has and prioritizes repairs. You get to decide the relationships before the pages exist. That is the easier job, honestly. It just needs a plan.
Step 1: Decide your top-level destinations before you publish anything
Start with places, not posts.
List the destinations your business actually needs people to reach. For most small sites that is a homepage, one main product or service page, a credibility page like an about page when it genuinely helps someone evaluate you, a contact or signup page, and one blog or resource area. That is it. Do not add a page because a template has a slot for it.
Building site structure from scratch starts with destinations, not keywords. A keyword list is not an architecture. It is a shopping list.
For each planned page, write down six things:
- The page name and what job it does.
- Who it is for and what they want.
- The one question it answers.
- Its likely parent or hub.
- The pages it should send people to next.
- One or two natural phrases that could become anchor text.
Then label it: hub, spoke, commercial destination, trust page, or utility page. Give your pages clear, short, unique titles and URLs with real words in them, not random strings. A readable URL helps a person judge whether a result is worth clicking. It does not replace a useful page.
You know this step is done when every planned page has one job, a spot in the hierarchy, and at least one likely way in. Try saying the whole map in one sentence. Something like: the homepage leads to the main solution, the solution leads to the topic hub, the hub leads to focused answers, and focused answers send people back to the solution when that helps.
If you cannot say it in one sentence, the map is not ready yet. That is normal on the first try.
Where people go wrong: they start from a keyword list and publish disconnected articles for six months. Then they try to bolt structure on afterward. That is the real internal linking new site problem, and you can skip it entirely by spending an hour on this step.
Step 2: Pick one starter topic and build a hub that stands on its own
One topic. Not three.
Choose the central topic closest to your audience and your offer. Then build one hub page that gives a complete orientation to it. A hub is a central page that covers the broad topic and points readers to narrower pages. Some people call it a pillar. The labels are used loosely across the industry, so do not spend energy on the argument. Decide what the page is meant to do and write that.
A hub that works does five things:
- Defines the topic in plain language.
- Explains the major subtopics.
- Helps a reader pick the level of detail they need next.
- Links to every live spoke with short, descriptive anchors.
- Links to your product or service page when that is genuinely the helpful next step.
Here is the trap: an empty index page full of links to articles you have not written yet. That is not a hub. It is a promise. Your hub has to answer the broad question by itself, even if only one spoke exists underneath it.
A quick distinction worth knowing. A topic cluster is about the linking network between pages. A silo is about grouping pages under a shared URL path. They are not the same thing, and you do not need a strict silo. Clean URL folders are helpful support. Rigid silos can stop useful context from moving between related sections, which hurts a small site more than it helps.
You know this step is done when the hub answers the broad question on its own and has a labeled destination for every spoke that is actually live. One hub plus one strong spoke beats one hub plus five thin ones. Every time.
Where people go wrong: calling a thin category page a pillar, then padding it to hit a word count. Comprehensive means it covers what a reader needs. It does not mean long.
Once you have a few pages live, it helps to see your coverage as a map rather than a memory. DeepSmith's Content Map crawls your site, classifies every page onto a topic and a buyer stage, and rechecks your sitemap every 24 hours so new pages fold in on their own. On a brand-new site there is not much to analyze yet, which is fine. The value is that your hub-and-spoke map stays current as you grow, instead of living in a spreadsheet you stop updating in week three.
Step 3: Write your first spokes around separate questions
A spoke is a page that answers one narrower question under your hub.
Break your hub into distinct, intent-driven questions. Each spoke gets its own job. If two spokes would answer the same question with different words, you have one spoke, not two. Pull the topics from what your audience actually asks, what is relevant to your product, and whatever keyword or competitor research you are doing anyway.
For your first cluster, this order works well:
- Publish the hub, the comprehensive foundation page.
- Publish the single most useful spoke, the one that answers the reader's obvious next question.
- Add a second spoke covering a different stage or a different subproblem.
- Add more spokes only when they deepen the topic, never when they split one answer into fragments.
This is an editorial recommendation for a new site, not a rule handed down by any search engine. There is no minimum cluster size.
You know this step is done when each page answers a different question, has a clear relationship to the hub, and has a planned link in and a planned link out. Read your cluster map as two directions: hub to spoke, spoke to hub. Cross-links between spokes only where a reader would genuinely want the neighboring answer.
Where people go wrong: linking every page to every other page. A complete graph is not a user journey. It is noise with good intentions. If you are planning a first cluster and want the topic selection side of it in more depth, that is a whole discipline of its own and worth learning properly.
Step 4: Build the first navigation layer
Your menu is a structural link, and it does a different job than a link inside a paragraph.
Put your genuinely important top-level destinations in the main navigation. Use a small number of clear labels that match what each page does. If your hub is a core resource, link to it from a prominent, relevant page too. Use the footer for secondary and legal destinations, not as the place you hide your best content.
Keep the hierarchy shallow. A common working target is to keep important pages within three clicks of the homepage. Treat that as a warning light, not a law. Nothing bad happens at click four automatically. It just usually means something is buried.
A five-page site does not need a four-level menu. It really does not.
You know this step is done when a visitor can reach every important page from the homepage through an obvious path, and that path makes topical sense. No essential page should be reachable only through a footer link, a search box, or a campaign banner that comes down next month.
Where people go wrong: confusing a flat menu with good structure. Putting every article in the main nav creates noise fast. Navigation is for major destinations. Contextual links carry the detailed relationships, and that is Step 5.
Step 5: Add contextual links while you write each page
This is where an internal linking foundation actually gets built.
A contextual link sits in your main content because the destination helps explain, prove, or extend the passage around it. Add these while you write, not in a batch at the end. Batch linking is how you end up with five bare URLs stacked in a row.
Start with the strongest relationships and stop there:
- Hub to every live spoke.
- Every spoke back to the hub.
- Spoke to related spoke, only when the second page is a natural next step.
- Informational page to your product or service page, when the reader is ready for that.
- Older page to a new page, when the older page already mentions the new page's subject.
- Homepage or another strong page to your most important new destination.
Now the anchor text, which is the visible clickable words. Make it descriptive, short, and natural. "How to build a content hub" tells a reader more than "click here." Skip empty anchors, generic read-more labels, whole sentences wrapped in a link, and forced exact-match keyword stuffing.
Here is a test that takes two seconds. Read the anchor by itself, with nothing around it. Does it suggest what is on the other side? If not, rewrite it.
The words around the link matter as much as the link. Put it inside a sentence that explains why it is worth clicking.
Pro tip: Do not chase a link count. One source suggests two or three incoming links for each new piece. Another suggests three to five contextual links in a typical article on top of normal navigation. Both are practical heuristics, not requirements, and Google explicitly says there is no magical ideal number of links on a page. Let relevance and page length decide.
You know this step is done when every important page has at least one incoming internal link, each new page is linked from the relevant existing pages, and every link has a reason a reader would appreciate. Hub and spokes connected in both directions.
This step is also the one that quietly eats your afternoon once you have more than a handful of pages. Manual cross-referencing does not scale, and it is usually the thing that gets skipped when you are behind on the next piece. DeepSmith's Writer handles internal linking as part of producing the article: it reads your sitemap and places internal links inside the draft, alongside external links to trusted sources. You still review them. Automated does not mean unchecked, and you are still the one who knows whether a link belongs in the cluster.

Whether you place new website internal links by hand or a tool places them for you, the judgment stays yours: right destination, natural anchor, real reason.
Step 6: Make linking a publishing gate for every new page
Nothing gets published with a note to link it later. Later never comes.
Turn this into an eight-item gate you run before every page goes live:
- Assign the page its role, topic, intent stage, and parent hub.
- Name the exact page or pages that should link to it.
- Add the link from the hub or parent page.
- Add the return link back to the hub from the new page.
- Add sibling links, but only the ones that clarify the topic.
- Update any older page that already discusses this subject.
- Check the title, the URL, the canonical destination, and every link target.
- Update the sitemap if your CMS does not do it automatically.
Then keep a small link ledger so you are not linking from memory. Columns: source page, destination page, relationship, anchor text, placement, status, date checked. A spreadsheet is plenty when you have a dozen pages. The point is to make the relationship explicit before the site is big enough to hide it.
Internal linking few pages is not a watered-down version of the big-site job. It is the same job, done while it is still cheap.
You know this step is done when no published page is waiting to get linked later, and every new page has a deliberate path from the homepage or another prominent page.
Where people go wrong: treating the sitemap as the whole step. A sitemap helps search engines discover URLs. It does not guarantee crawling or indexing, and it tells your visitors nothing about why two pages relate.
The other thing that breaks this gate is cadence. When publishing slips, the linking routine slips with it. DeepSmith's Planned Content lets you schedule an article at planning time, and Autowrite generates it on its date and drops it into Produced Content for you to review and publish. The routine keeps running during the weeks you cannot.
Step 7: Run a small-site link and crawlability check
Last step, and it is short. Look at your site twice: once as a visitor, once as a crawler.
Check the links themselves. Important links should be ordinary HTML anchor elements with an href pointing at a real address. JavaScript can insert links, as long as what renders is crawlable anchor markup. Do not lean on click handlers when a plain link would work. Confirm each link goes straight to the final HTTPS page instead of hopping through redirects. Test every destination for a live response and the correct canonical page. Check mobile navigation and keyboard access, not just how it looks on your laptop.
Check the structure. Every important page has an incoming internal link. Every hub reaches all its live spokes, and every spoke reaches its hub. Any page sitting more than three clicks from the homepage gets a second look. No page should be reachable only from a noindex or unlinked location. Remove links that exist only to inflate a count.
Check what search engines see. Keep your sitemap submitted and current, remembering that submission is not an indexing promise. Use Search Console's URL Inspection tool for crawl and index information on specific pages. If a Links report is available to you, use it to see which pages have incoming internal links, but do not read a count as a quality score.
Here are the failures you will actually find, and the fix for each:
| What you find | What to do |
|---|---|
| Orphan page, nothing links to it | Add a contextual link from a relevant existing page, plus a return link to the hub |
| Anchor reading "click here" or "read more" | Replace with concise wording specific to the destination |
| Too many links on one page | Remove the ones that do not help the reader |
| Five links chained together | Split them into readable sentences with context around each |
| The same destination linked repeatedly | Keep the useful placement, cut the repeats |
| Broken link | Point it at a live destination or remove it |
| Redirect chain or an old HTTP link | Update the source to the final canonical HTTPS URL |
| JavaScript-only link | Replace it with a crawlable anchor and an href |
| Page buried four or five clicks deep | Add a direct link from a shallower relevant page |
| Every page linked to every page | Cut back to relationships a reader would use |
| Keyword-stuffed anchor | Write it the way you would say it out loud |
You know this step is done when you can walk homepage to hub to spoke and back, crawlers can parse every link, nothing important is orphaned, and every link lands where you intended.
Most new website internal links break for boring reasons: a typo in a URL, a page renamed after launch, a draft link that never got updated. Boring is good news. Boring is fixable in ten minutes.
Do this pass manually after each publication while the site is small. That is more useful than pretending you need a monthly enterprise audit for eleven pages.
What this means for AI search
A quick word on this, because it is probably on your mind.
Google's guidance says ordinary SEO fundamentals still apply to AI Overviews and AI Mode, and that there are no extra requirements or special optimizations needed to show up there. AI features may also fan a question out into several related searches across subtopics. That makes clear topical organization, distinct subtopic coverage, descriptive headings, and useful cross-links sensible foundations to build on.
It does not mean an internal link causes an AI citation. Nobody can promise you that.
So the practical version for a new site is organizational, not magical. Make the hub the clearest broad explanation of your topic. Make each spoke the clearest answer to one narrow question. Put the actual answers, definitions, and steps in the page text, because a link cannot rescue a page that does not answer its own question. Keep titles, headings, anchors, and content aligned. And keep everything important crawlable and index-eligible, since a blocked page cannot become a source no matter who links to it.
If you do get AI visibility data, from Bing's AI Performance report or anywhere else, read it as a sample and a trend. It is not a full accounting of every answer, and it will not tell you why a specific page was referenced.
What to do next
Pick one thing this week. Just one.
If you have not mapped your destinations, do Step 1. It takes an hour and it is the step every other step depends on. If your pages are already live but scattered, do Step 5 on the two pages that matter most to your business, then work outward.
Then make the Step 6 checklist part of your content calendar. Every new page gets a parent, a return path, the contextual links that earn their place, and a quick crawlability check before it goes live. That habit is the whole internal linking foundation. Ten pages built that way beat two hundred built by accident.

You are not behind. You are early, which is the best place to be for this particular problem.
If you want the map and the production side connected instead of living in separate tabs, start a free DeepSmith trial and see your site structure, your topic coverage, and your linked drafts in one place.



