How to Run a Real SEO Project: Managing SEO Work

Last updated: November 1, 2026.

This chapter is a continuation of the audit in Chapter 32. In the audit we found the problems; in this chapter we’ll talk about how we manage those problems in a real project. In Chapter 32 we asked “Which problems did we find?” In this chapter we move on to the really hard part:

In what order, with whom, in how much time and with what expectations will we solve the problems we found?

In theory, an SEO project looks very orderly. An audit is done. Gaps are identified. Technical errors are fixed. Content is prepared. Backlink work is done. Then traffic goes up.

In reality, most projects don’t go like that.

One thing gets fixed, something else breaks. A competitor does something new. Google releases an update. The development team moves on to another priority. The client changes their mind. Content isn’t ready in time. A product goes out of stock. The site gets migrated.

That’s why I think an SEO project is much more than a to-do list.

An SEO project is the management of a system that keeps changing.

1. When the audit ends, the work doesn’t end; it actually begins

In the previous chapter we covered the audit. We found the problems. We prioritized them. But now there’s a harder question:

Who will do these, in what order and when?

Because an SEO specialist usually doesn’t work alone. A project can involve:

Developers
The content team
Designers
The performance marketing team
The client
Managers
The sales team

A good SEO project is partly about keeping these teams focused on the same goal.

2. Don’t try to do everything at once

An audit can produce 150 tasks. But they can’t all be done at the same time. I think the most important thing here is prioritization.

For example:

An important category has been set to noindex
400 meta descriptions are missing
A few images are very large
Breadcrumbs are missing
Checkout is broken on mobile

All of these can be problems. But they’re not equally important.

I usually work through these questions:

How big is the impact?
How many pages does it affect?
What is its commercial importance?
How hard is it to fix?
Is it blocking other work?
Does it directly affect users?

Sometimes fixing a single canonical error brings more results than fixing hundreds of small warnings.

3. The impact x effort approach to prioritization

We talked about this in the audit chapter too, but it’s very useful in project management as well. We can roughly split tasks like this:

High impact / low effort
High impact / high effort
Low impact / low effort
Low impact / high effort

The first group is usually the quick wins. For example, if there’s a wrong noindex on an important page and fixing it takes 5 minutes, there’s no point in letting it wait.

Changing the entire site architecture, on the other hand, can have a big impact but take months. Both tasks are important, but they sit in different places in the project plan.

4. Why does SEO take time?

Because in SEO we control some things. Others we don’t.

We can:

Fix a technical problem
Write content
Add internal links
Prepare a sitemap
Earn backlinks

But we can’t fully control when Google will crawl the page again, when it will evaluate the change, or how it will re-rank us against competitors.

That’s why in SEO there can be a time gap between the work and its result.

5. The same SEO work doesn’t produce results in the same time on every project

We talked about this earlier with examples in Chapter 31.

On a low-competition project, a small change can create a serious ranking increase within a few hours. On another project you see very little movement for months. Then one day a big jump comes.

That’s why I don’t think definite statements like “SEO delivers results in 3 months” or “in 6 months” are very accurate. The better question is:

On this project, at this level of competition, with these resources, how long do we expect it to take to see a meaningful signal?

6. Short-term and long-term work need to be separated

When preparing an SEO roadmap, it’s useful to split the work into two groups instead of keeping it in a single list.

Short-term work:

Critical technical errors
Wrong canonicals
Noindex
Internal links to 404s
Sitemap issues
Measurement errors
Updates to existing content

Long-term work:

Site architecture
New content clusters
Backlinks
Digital PR
Brand demand
New country targets
Category expansion

Short-term work can bring quick wins. Long-term work usually brings lasting growth.

7. The first thing to do when traffic drops is not to panic

One of the most stressful moments in SEO projects is a traffic drop. The client calls: “Traffic dropped, what happened?” The first reflex shouldn’t be “Google rolled out an update.”

First we need to understand:

What actually dropped?

Clicks?
Impressions?
Rankings?
CTR?
Specific pages?
A specific country?
Mobile?
Branded queries?
Non-branded queries?

It’s hard to get to the cause without narrowing the problem down first.

8. A traffic drop isn’t always an SEO problem

For example:

The season has ended.
Demand has decreased.
The product has gone out of stock.
Interest in a news story has faded.
An ad campaign has ended.
Brand searches have dropped.

Traffic can drop even when rankings stay the same. That’s why Search Console, Analytics and, if needed, Google Trends should be read together.

“The chart went down” is not a diagnosis.

9. What do I look at when rankings drop?

I roughly go in this order:

When did the drop start?
Is it site-wide?
Is it on specific URLs?
Is it on specific queries?
Was there a technical change?
Was there a deploy?
Did canonical, noindex or robots.txt change?
Was there a site migration?
Are there changes at competitors?
Did the SERP layout change?
Was there a Google update?
Has the content become outdated?

Some of these questions can narrow down the problem in a few minutes.

10. What do you do after a core update?

The biggest mistake after a core update is to panic and make big changes right away. First you need to wait for the update to finish rolling out and see the picture.

Then you should look at:

Which pages dropped?
Which pages went up?
Which queries were affected?
Which competitors gained?
What are the winning pages doing better?
Is the difference content, authority or user intent?

I think the approach of “There was a core update, let’s rewrite 200 pages right now” is risky. First you need to understand what changed.

11. An algorithmic drop and a manual penalty are not the same thing

This distinction matters.

If there’s a manual action, you can see it in Search Console. Google may explicitly warn you about a specific spam policy violation.

With an algorithmic drop, there may be no such notification. The site can lose visibility because of changes in the ranking systems.

That’s why you shouldn’t use the phrase “We got penalized” too easily. Not every drop is a penalty.

12. If there’s a manual action, you need to fix the cause first

With a manual action, the process is clearer. For example, if there’s an unnatural backlink problem, these are reviewed:

Which links were created?
Which ones can be removed?
What was done in the past?
Should a disavow be used if needed?

After the problem is fixed, a reconsideration request may be needed.

But with an algorithmic drop, there’s no “remove penalty” button. You need to improve the site’s overall quality and competitive strength.

13. Why might a technically good site not rank?

This is very important. The site may be:

Fast
Mobile-friendly
With a clean sitemap
With correct canonicals
With correct schema
Free of 404s

But it still may not rank. Because SEO is not just a technical health check. Maybe:

The content is weak
The search intent is wrong
The competitor is stronger
The brand is unknown
There are no backlinks
The product is weak
The price isn’t competitive
Users don’t like the page

Technical SEO gets us into the race. It doesn’t always win the race for us.

14. SEO for a new site should be managed differently

A common mistake with new sites is asking “Why hasn’t any traffic come?” after a few weeks.

A new site’s situation might look like this:

No content history
No backlink profile
No brand demand
Few user signals
Little data for Google about the site

That’s why on a new project, the first goal is not “Top 3 for every keyword.” First, these should be built:

Crawlability
Indexing
The right site architecture
Core content clusters
Initial visibility
First backlinks
Brand presence

15. The biggest mistake on a new site: producing everything at once

Sometimes a new project comes in. The first plan: “Let’s publish 1,000 pieces of content in 3 months.”

I usually find it makes more sense to build a small but strong core first. For example, these can be prepared properly first:

The most important categories
The most important products
Commercial queries
Main guides

Then you expand based on the data. Because Google discovering thousands of new URLs that create no value may not do us any good.

16. Site migration projects should be managed separately

A domain change or a major URL change is critical for SEO. The process here isn’t just “Set up the 301s.”

Beforehand, these should be prepared:

An inventory of old URLs
Pages getting traffic
Pages with backlinks
New URL mappings
Sitemap
Canonicals
Internal links
Analytics
Search Console

Afterward, these should be tracked:

Are the 301s working?
Where are the old URLs going?
Are there redirect chains?
Are the new URLs getting indexed?
How is traffic changing?

A site migration is not a development task. It’s a project.

17. Before a site migration, Excel is sometimes the most important tool

We talked about Excel and Google Sheets in Chapter 30. A site migration is a very good example of this.

There are 20,000 old URLs. There are 20,000 new URLs. They need to be mapped correctly.

A simple table sometimes becomes more critical than dozens of SEO tools:

Old URL
New URL
Old traffic
Backlinks
Redirect status
New status code

18. SEO for small businesses should be managed differently

Applying a large e-commerce site’s strategy to a small business is wrong.

For a 50-page local business, crawl budget, millions of parameter URLs and large-scale log analysis may not be the first priority. These may matter more:

Service pages
Local queries
Google Business Profile
Reviews
The right content
Local backlinks
Conversions

SEO strategy should be built around the business model, not the size of the site.

19. On large projects, the coordination work grows

On a large e-commerce site, these teams may work together on a single SEO change:

SEO team
Development
Product
UX
Design
Data
Marketing

For example, there’s a problem with filter URLs getting indexed. SEO says “Let’s control this.” But the product team sees the filters as necessary for the user experience. Development built the system that way.

Here the SEO decision can’t be made alone. The right solution is a joint decision across teams.

20. How should the SEO team and the development team work together?

I think one of the biggest problems is the language gap.

The SEO team says “The canonical is wrong.” The development team asks “On which URL, and what should it be?”

Tasks should be clear. For example:

Current:
/product?color=black
canonical: /product?color=black

Expected:
canonical: /product

This is much more actionable. SEO tasks should be written in a way that can be technically tested.

21. Saying “SEO is important” is not a task for a developer

Telling a developer “Make the site SEO-friendly” is meaningless. The task should look like this:

What will change?
Where will it change?
What is the expected output?
What is a sample URL?
What are the test criteria?

This both speeds up the work and reduces misunderstandings.

22. How should the content team be managed?

Just giving the content team a keyword isn’t enough. We talked about the content brief in Chapter 22.

The writer should know:

Who are they writing for?
What does the user want?
What is the search intent?
What are competitors covering?
What will we say differently?
Which product or service will we connect it to?

A bad brief can mean the same content gets redone 4–5 times. Good project management cuts down on this rework from the start.

23. The decision-maker on the client side should be clear

One problem agencies run into often: five people give feedback.

One says “Make it more corporate.” Another says “Make it more friendly.” Someone else says “Let’s write it technically.” Then the manager says “It’s too technical.”

This slows the project down. On the client side, these should be clear if possible:

The main decision-maker
The technical owner
The person who approves content

24. In SEO, communication sometimes becomes more important than technical knowledge

You can do a very good analysis. But if you can’t explain it to the development team, it won’t be implemented. If you can’t explain it to the client, it won’t be approved. If you can’t explain it to the content team, it’ll be written wrong. If you can’t explain it to management, there won’t be a budget.

That’s why an SEO specialist needs to understand not only Google but also people.

25. How do you manage client expectations?

I think this is one of the most important things to talk about before a project starts.

For example, the client may ask “When will we be number one?” It’s easy to say “3 months” here and make the sale. But the right answer is usually more complicated. It depends on:

Competition
The site’s current strength
Brand
Backlinks
Content
Technical infrastructure
Budget
Team speed

If you set the wrong expectation at the start, the client can be unhappy even if the project goes well.

26. Why is guaranteeing rankings a problem?

Google isn’t yours. Competitors aren’t yours. The algorithm isn’t yours.

So I think “Guaranteed number 1 for this keyword” is one of the promises a professional SEO service shouldn’t make.

We can guarantee the work to be done, the methodology, the priorities and the measurement method. But not the exact position on Google.

27. Keep a record of everything you do

I’ve been repeating this for a few chapters because it matters. An SEO change log is very useful. For example:

January 12: canonical changed
January 18: category content updated
February 2: internal link module launched
February 8: filter structure changed

When the chart changes three months later, you can look back. Otherwise you end up in a “We did something, but what was it?” situation.

28. Deploy dates should be recorded too

Not just SEO changes. Software deploys matter too.

For example, traffic dropped suddenly on March 15. The SEO team didn’t do anything. But the development team pushed a release on the night of March 14. Without this information, diagnosis gets harder.

If possible, these should be kept on the same timeline:

SEO changes
Major deploys
Site migrations
Design changes
Campaign launches

29. Using a project management tool helps

It can be Excel. It can be Trello. It can be Asana. It can be Jira. It can be Notion.

The tool itself doesn’t matter much. What matters is that every task has this information:

Owner
Priority
Due date
Status
Expected impact

“To be done” is not a status. Who will do it, and when?

30. How should an SEO roadmap be prepared?

I think a general direction for 6–12 months is useful. But it shouldn’t be so rigid that it can’t change for a whole year.

For example, the initial plan might look like this:

Period	Focus
Month 1	Technical issues
Months 2–3	Content
Months 4–6	Authority

But in month 2 a major core update arrived. The competitive picture changed. A new product launched. The plan can change.

A roadmap gives direction. It isn’t law.

31. An SEO project should move forward through hypotheses

I think this is a very important approach. For example:

Hypothesis: “If we add more internal links on category pages, the discovery and visibility of deep product pages will increase.”

We make the change. Then we measure. Did it really increase? If not:

The hypothesis may be wrong.
The implementation may be insufficient.
More time may be needed.
Another problem may be dominant.

This approach makes SEO more scientific.

32. When do you give up on something that isn’t working?

I think this is one of the hard questions.

It’s true that SEO results take time. But you shouldn’t use “SEO takes time” to defend a strategy that hasn’t produced any results for years.

For example, if this has been the picture for six months, you need to re-evaluate the strategy:

Visibility isn’t growing
Impressions aren’t growing
Traffic isn’t growing
No new queries
The content isn’t producing results

Being patient and being stubborn are not the same thing.

33. Failed experiments produce data too

We tried a content format. It didn’t work. That isn’t a total loss. We may have learned that:

Users don’t want it.
The SERP wants a different format.
The topic isn’t commercial.
The competitor’s advantage is too great.
The content’s positioning is wrong.

Not every experiment in SEO succeeds. But good project management gets data out of every experiment.

34. The mistake of never checking again because a problem was solved

We gave a real example of this in Chapter 32. We fixed a canonical problem. Later, the error came back with another software update. If we hadn’t been doing monthly audits, it would have gone unnoticed.

That’s why in project management some checks should have the status Ongoing check, not Done.

35. Uptime monitoring is part of project management too

We monitor our new clients with services like UptimeRobot. Because if the site is down for an hour, the SEO traffic, Google Ads, social media and direct traffic during that time are all wasted.

That’s how we saw that one of our clients’ sites had recently been down for about an hour.

The SEO audit can be monthly. But site availability should be monitored in real time.

First the site has to work. Then we grow the site.

36. The SEO and ad teams shouldn’t live in separate worlds

We talked about this in Chapter 31 too. Google Ads doesn’t directly raise organic rankings. But data from the ads side can be very useful for SEO. For example:

Which search terms convert?
Which product group brings high revenue?
Which landing page works better?
Which message gets a better CTR?

This information can strengthen the SEO strategy. In the same way, SEO data can give the Ads side ideas.

37. The sales team should be included in the SEO project too

Especially in B2B.

The SEO tool tells us “This keyword is searched 500 times a month.” The sales team might say “Customers who come from this keyword never buy.”

Or the opposite. A query with 20 searches a month may be bringing in very good customers.

Ignoring the sales team’s data in an SEO strategy is a big gap.

38. “Done and dusted” applies to very few things in SEO

The site keeps changing. Google keeps changing. Competitors keep changing. User behavior changes.

That’s why these move forward in a cycle:

Audit
Content
Technical checks
Backlinks
Reporting
Prioritization

I think the most accurate picture of an SEO project is not a checklist.

It’s a cycle.

39. What needs to be discussed every month?

In a monthly review, I’d roughly like to see these questions:

What did we do last month?
What worked?
What didn’t work?
Why did traffic change?
Why did conversions change?
Is there a new technical problem?
What changed at competitors?
What are the three most important tasks for next month?

I think these questions manage a project better than a 50-item task list.

40. It matters that everyone on the project knows the “why”

Instead of telling a developer “Set up this redirect,” when you say “We’re redirecting the old URL to its new equivalent because it has backlinks,” they can understand the work better.

Instead of telling a content writer “Write this heading,” when you say “Users ask this question before buying,” better content can come out of it.

The team should know not only the task but also the purpose.

41. Client management is part of SEO

The SEO specialist may be technically right. But if the client has no budget, the work can’t be done. If the development team’s three-month roadmap is full, the change can’t be made. If the content team can’t keep up, the plan slips.

That’s why an SEO strategy should be built around the resources that actually exist, not an ideal world.

A perfect strategy that isn’t implemented is worth less than a good strategy that is.

42. The success of an SEO project doesn’t depend only on the SEO team

I think this needs to be explained openly to the client too.

An SEO agency can do excellent work. But results can stay limited if:

The site keeps going down
Development tasks aren’t getting done
Content isn’t getting approved
The product is out of stock
The sales team isn’t calling the leads

SEO is a team effort. It’s not a system the agency controls on its own.

43. How do I define a well-managed SEO project?

A project where these are clear:

We know where we are.
We know where we want to go.
Our priorities are set.
Every task has an owner.
Changes are logged.
We measure the results.
We can change what isn’t working.
The technical, content and commercial teams move together.
The client’s expectations are realistic.
We can react quickly to new problems.

I think that’s what SEO project management is.

To sum up

An SEO project is not a straight-line process that goes “Do an audit. Pull out 50 tasks. Complete the tasks. Wait for traffic to go up.” It’s more like this cycle:

Analyze → Prioritize → Implement → Measure → Learn → Reprioritize

Sometimes traffic drops. Sometimes a Google update comes. Sometimes a problem you technically fixed comes back. Sometimes a competitor moves faster than you. Sometimes content you produce brings no results at all. And sometimes a small change brings far more results than you expected.

Good SEO project management means not losing sight of what you’re doing and why, despite all of this.

I think the main idea of this chapter is this:

An SEO project is not a to-do list, it’s a process that is continuously managed through decisions and feedback.

And maybe more important:

The best SEO strategy is the one that can be implemented and changed based on its results.

Previous: Chapter 32: How to Do an SEO Audit · Contents · Next: Chapter 34: How to Build an SEO Checklist

This chapter was first published in Turkish on X (October 9, 2026).

Chapter 33: How to Run a Real SEO Project