Search intent and site architecture

Every keyword tool ships an intent column, and it is guessing from the words. It sees best and decides commercial. It sees how to and decides informational. The column is derived from the string, which means it knows nothing about your market, the device people search on, or what the result page actually shows when somebody types it.

Intent is not a funnel stage. It is the task a person is trying to finish, and the same words support different tasks depending on where and when they are typed. Lawyer near me means something different at two in the afternoon on a laptop than it does at midnight on a phone after a crash.

The evidence is available and it takes about four minutes per query to collect. The result page is the market's own answer to what a query means, and it beats a label derived from grammar every time.

Intent is a task, not a funnel label. The result page is the evidence and the modifier is only a hint.

Where the evidence actually comes from

Confidence belongs in the record beside the interpretation. A query whose results are eight guides and two service pages supports a confident reading. A query splitting five and five supports a written note that says the market has not decided either, and that note will save somebody a wasted page in three months.

Write the task without naming a page type

The discipline that makes this lesson work is refusing to write the format into the task statement. Say what the person is trying to accomplish, in their situation, using no words that describe a page.

Texas car accident settlement calculator is the clearest example. The primary task is estimate a range. The secondary task, arriving about ninety seconds later, is understand whether this is worth calling somebody about. Neither of those sentences contains the word calculator, guide, or service page, and that is deliberate.

Write it as a page type instead and the analysis is over before it starts. Build a calculator collapses two tasks into one format and skips the question of whether the second task is where the business actually earns anything. The format decision belongs in the next lesson, made against a task statement that did not presuppose it.

Record the secondary task explicitly when there is one. Most useful pages serve a primary task completely and hand the person cleanly to the next thing they need, and you cannot design that handoff if only one of the two tasks is written down.

Read one query properly

Four minutes per query, and it does not batch. The output is a sentence and a confidence level, not a label.

1. Write the likely task in one sentence, before you look.Writing it first makes your assumption visible, so the result page can contradict it. Looking first means quietly adopting whatever you see and calling it analysis.
2. Open the result in the target market and count page types.Count rather than skim. Eight guides and two service pages is a different market from five and five, and skimming reports both as mixed.
3. Note the result features present.A local pack, a calculator, a video carousel, or an answer block changes what winning looks like and sometimes removes the click entirely.
4. Record competing interpretations and your confidence.A split result set is a finding worth writing down, not an inconvenience to resolve by picking the reading you preferred before you opened the page.

A task statement does not tell you what to build. It tells you what has to be true when somebody finishes. The format is a separate decision, and it is the one that most often gets made by default: whatever the team is used to producing becomes what every task gets.

That default is expensive because formats are not interchangeable. A service page and a guide can address the same subject and serve completely different jobs, and putting the wrong one into a market decides the outcome before anybody writes a word.

The format is chosen from the task and the result page. A page earns its URL by serving a need no existing page serves.

The formats, and what each one is actually for

The list is shorter than most content taxonomies because format follows the job, and there are not many distinct jobs. Blog post, article, landing page, and pillar page are production labels rather than formats. They describe how a thing was made and by whom, and they tell a reader nothing about what the page will do for them.

What earns a URL

A page deserves its own address when it serves a distinct need, which means a need that no existing page on the site serves completely. That test is stricter than it sounds and it removes most proposed pages.

The test is not whether the keyword is different. It is whether the person's job is different. Choosing a lawyer and estimating a settlement are different jobs, so they earn different pages. Personal injury lawyer austin and austin personal injury attorney are the same job, so they earn one.

When a proposed page cannot name something it provides that no sibling provides, it is not a page. It is a section of a page that already exists, and treating it as a page splits the signals of both.

Doorway variants and the city-swap trap

The most common bad architecture in local search is a page per city where only the city name changes. Twelve pages, one template, no local content, and a plan to add forty more. It is cheap to produce, which is exactly why it keeps happening.

These pages fail on their own terms before anyone considers policy. A person in Round Rock reading a page whose only Round Rock content is the word Round Rock learns nothing and leaves. The page has no distinct utility, so it cannot serve a distinct need, so it does not earn its URL under the previous section's test.

A location page is legitimate when it is genuinely local. Real cases handled there, courts and processes specific to that jurisdiction, staff who work in that office, and the practical details somebody in that place actually needs. If you cannot write that for the fortieth city, the fortieth city does not get a page.

When one task needs two pages

Occasionally the honest answer to a task statement is two formats rather than one. The settlement calculator is the case study: the primary task wants a tool, and the secondary task, understanding whether the number means you should call somebody, wants explanation the tool cannot carry without becoming unusable.

Build both and link them where the reader's task changes. The tool does its job cleanly, the guide picks up the person who now has a number and a question, and neither page is compromised by trying to be the other one. This is a different decision from splitting a keyword, and the giveaway is that both pages appear in the same task statement rather than in two.

Choose the format

Four decisions, taken in this order. Reversing the first two is how the default format wins.

1. Name the primary task and the secondary task.From the previous lesson's statement, not from the keyword. Two tasks sometimes means two pages, and you cannot see that if only one was written down.
2. List what the page has to provide.The information, the interaction, the proof, and the next action. This list picks the format almost by itself, which is why it comes before the format.
3. Choose the format capable of providing all of it.Capable is the operative word. A guide cannot perform a calculation and a tool cannot carry an argument, and choosing either one anyway means shipping a page that half works.
4. Reject the format you picked for a bad reason.Competitors use it, the modifier sounded commercial, or it is what the team produces quickly. None of those is evidence, and all three are the usual reason a wrong format ships.

An architecture map is not a folder tree. A folder tree says where files live. A map says which pages exist, what job each one does, which page is its parent, how a person reaches it from somewhere they already are, and which URL is canonical when several could serve.

The reason to draw it before building anything is that the relationships are the expensive part to change later. Moving a page is cheap. Discovering after eighteen months that four pages have been quietly competing for one task, and that the internal links are split evenly across them, is not.

Group by stable audience task, not by keyword taxonomy. Every page needs a parent, a purpose, and a path somebody would actually walk.

Group by the business, not by the keyword list

The failure mode here is importing the shape of your keyword research into the site. Keyword tools cluster by string similarity, which produces groupings that look tidy and describe nothing a visitor recognizes. A section called injury lawyer terms is a research artifact wearing a URL.

Group by stable audience task or business area instead, and the test for stable is whether the grouping survives a change in search behavior. Horizon's services do not stop being services when a modifier falls out of fashion. Its sections are built around what the firm does and who it serves, and the keyword work maps into them rather than defining them.

This is also what makes navigation predictable. A person should be able to guess what is inside a section before clicking it. When they guess wrong twice, they stop using navigation and start using the back button, and the depth you carefully designed stops existing for them.

Horizon's map keeps the Austin service page under /personal-injury/ where its siblings are other services. The calculator goes under /tools/ because its job is a job the tools section does, not because it shares words with the injury pages. The guide links to both, at the point where the reader's task actually changes.

Four risks to check before the map is finished

Assign one canonical URL per intended page while the map is still a document. Deciding canonical intent later, once several similar pages exist and all of them have links, turns a five-minute decision into a migration.

Draw the map

One section at a time. A map of the whole site drawn in one sitting is a wish list; a map of one section is a plan somebody can build.

1. Group the approved tasks by business area.Use the language the business uses about itself. If a grouping needs a paragraph to justify, a visitor will not intuit it in the half second they give your navigation.
2. Give every intended page a parent.A page with no parent has no context and usually no path. The parent is also what tells you whether the page belongs in this section at all.
3. Assign one canonical URL per page.Decide it now, in the document, while changing it costs nothing. Canonical decisions made after launch are migrations wearing a smaller name.
4. Write the contextual link paths, not just the navigation.Navigation is the same on every page. The links that matter are the ones placed where a reader's task changes, and those have to be planned per page.
5. Check the four risks against the map.Orphans, duplicates, parameters, and pagination. Doing this on paper is minutes; doing it after a crawl finds them is a remediation queue.
6. Compare the intended map with the live site.Run Site Health and look at where reality and the plan disagree. Those disagreements are the work list for the next lesson.

A map that nobody sequences is a diagram. The decisions in it are real, and they still produce nothing until each URL has an action, an owner, and a place in an order that does not break the site on the way through.

Sequencing is where architecture work usually fails, and it fails quietly. Every individual change is correct. Shipped in the wrong order they take out a page that was working, or leave a redirect pointing at something that does not exist yet, and the recovery costs more than the original project.

Every URL gets one action, one owner, and a position in the order. The order is not a formality.

Six actions, one per URL

Remove deserves the most scrutiny of the six. A page with no traffic still holds inbound links, still appears in somebody's bookmarks, and still answers a question for the handful of people who find it. Deleting it converts a small ongoing benefit into a 404, and the reason it felt appealing is usually that removal is the fastest row to close rather than the right call.

Sequence, dependencies, and what breaks

Dependencies are the work that has to finish before another item can ship safely. A template before the pages that use it. Navigation before the section it exposes. Analytics events before the page whose success you intend to measure.

Horizon's calculator release runs in a specific order. Publish and QA the calculator. Add the hub and guide links so it is not born an orphan. Verify the analytics events fire. Only then redirect the obsolete calculator URL. Recrawl and review Search Console afterward.

Move the redirect earlier and the old URL points at a page that has not been checked. Move the links later and the new page sits with no internal path during the window when the engine is most interested in it. Skip the analytics verification and the page launches with no way to tell whether it worked, which means the next decision about it will be made on opinion.

Write the success check before launch, not after. It should be a specific observation on a named view with a date attached, and it should be something that could come back negative. A check that cannot fail is a formality, and formalities are how a queue fills with work nobody can evaluate.

Turn the map into a queue

The output is a sequenced list where every row could be picked up by somebody who was not in any of these lessons.

1. Mark every URL with one action.Including keep. An unmarked URL is an unmade decision, and it will be rediscovered as a surprise during the release.
2. Attach the keyword and intent evidence to each row.The task statement and what you saw on the result page. Without it the person doing the work rebuilds your reasoning from the keyword, badly.
3. Identify dependencies before ordering anything.Templates, navigation, analytics events, and redirect targets. A dependency discovered halfway through a release is the kind that takes a working page down while somebody works out what happened.
4. Sequence the release around them.Publish, then link, then verify measurement, then redirect. Redirects last, because a redirect to an unverified page is a bet.
5. Assign an owner and a reviewer per row.Two different people. The reviewer is what stops done meaning the author thinks it is done.
6. Write a success check that could fail.A named view, a date, and an observation that would tell you the change did not work. Checks that cannot fail teach nothing.
7. Bind the row to the shared URL record.Site Architecture holds the page identity. Keyword List and Content Plan should point at it rather than each storing their own version of the same decision, which is how three systems end up disagreeing about one page.